Question: how is a regular day at your work?
Answer: 80% coding, 20% design, discussion. code reviews. Design reviews.

Question: Tell me about a time when you notice there was an opportunity to do more than was expected
Answer: Users found a bug. Low level, quick fix. I chose another way. I did the hotfix, but I also came up with a better and more generic solution.

SQL real-time processing. There was a case when a length of a variable went over ^4K. I wanted to split a method. I set up a new project so that they don’t have to worry about the code generator.

The project was to translate SQL to Java code.
I went through the whole JDK.

Length of the method was limited by short
I wrote some e-mails to the OpenJDK community.

The short fix was to split the method. The long term fix was to fix (couldn’t explain).

I am the only one who maintains that.

I left the design document.

Question: Tell me about a time when you saw an opportunity to provide more than expected for the user
Answer: can’t recall.

Question: Was there a situation that nobody owned a feature, and you stepped up?
Answer: Apache Flink. It is an open-source stream-processing framework. I almost look through all code reviews.
The user cannot know where they create a bug.

It makes me understand the other team’s codebase. We have extended.

There was a feature the user found the APIs very hard to use. We design the APIs for developers, not users. I thought the API has to be as soon as possible.

I helped design those API design (there was another guy who helped). We discussed for 1.5 months, and we went through 6 iterations
we ported their logic into our API.

End-users didn’t like our API. We didn’t design the API as easy as possible
it wasn’t suitable for the user – it was hard to study. We redesigned, but the implementation was unchanged. We ported or the machine learning algorithms to our API.


Competency asserted: Ownership
Job title: Software Development Engineer, SDE II
Interviewer role: Software Development Manager, SDM

Vote: 👍

I am inclined to hire the candidate, but I observed issues with his communication style (both verbally and through code). I was able to get to most of the data I wanted to get to, but it took multiple follow up questions. If this is reported to be a hindrance by other interviewers, I’ll reconsider my vote.

The candidate makes sure the quality of the software owned by a sister team is good. He does code reviews for them. He owned the delivery of a complex feature and decided to go with a more straightforward solution to deliver. He owned the delivery of the right solution in the long term (also Deliver Results)


While there isn’t much time for small talk during interviews, some interviews do like starting with an ice breaker. Don’t elaborate too much when answering those as you will get less time for other questions. It already happened to ask a straightforward ice breaker question only to have a candidate rambling for 5 minutes without being able to stop him!

An interesting point to notice is how the interviewer probed the candidate to get the data points he needed to cast a decision. Preparation is vital, prepare factual stories you can talk about in detail.

Be ready to justify and argument each decision you made.

Leave a Reply