For years, I've conducted hundreds of technical job interviews. I've spoken with countless candidates, sometimes listening to ten people in a single day. I observed that most candidates gave memorized technical answers, listing "best practices." However, in my career, only one candidate truly impressed me deeply and stuck in my mind. That day, I realized that a good candidate should not only explain what they know but also what they don't know and how they learn.
What made this candidate different from the others? They didn't just give correct answers; they approached my questions with a deep understanding, didn't hide their mistakes, and most importantly, they grasped that a system is not just about code. For me, the most important quality I look for in a candidate is not just solving a problem, but understanding its root cause and being able to explain what they did to prevent it from happening again.
Technical Knowledge or True Understanding?
When I ask a technical question, most candidates explain the topic exactly as they memorized it from books or documentation. For example, if I ask, "What are the types of indexes in PostgreSQL?", they list index types like B-tree, GIN, BRIN, and then state in general terms which one is better in which scenario. This is a good start, but it's not enough.
The candidate who impressed me, after listing the index types, started by saying, "I noticed a specific report running slowly in a production ERP." They continued, "I looked at the logs and saw seq scan, I examined the query with EXPLAIN ANALYZE and understood why the B-tree index was insufficient. Then, I set up a GIN index for filtering in the JSONB field and reduced the query time from 30 seconds to 200 milliseconds." This was a real experience, and it clearly showed what they did and why.
💡 Don't Just Share Information, Tell a Story
When explaining a technical topic, instead of just giving a definition, describe which real problem you associated it with, how you created a solution, and the result. This shows much more than rote memorization.
An Approach That Isn't Afraid to Make Mistakes
One of the topics candidates are most hesitant about in job interviews is admitting they made mistakes. However, for someone like me who has been in this business for 20 years, making mistakes is a natural part of the learning process. The important thing is not to hide the mistake, but to show what lesson you learned from it.
This particular candidate, in response to a question, said, "Last year, while writing a CI/CD pipeline, a step where I used sleep 360 kept getting OOM-killed." They explained, "At first, I didn't understand, because I wasn't doing an operation that would consume memory. Then I realized that this was a polling mechanism, and instead of constantly waiting idly, I should have used the wait command to await the completion of the previous step. Because of this mistake, I understood that I needed to research the reliability of systemd timers more deeply." This confession showed me their problem-solving ability, honesty, and eagerness to learn.
System Perspective: Not Just Code, But Workflow
For me, software architecture is often not just about code; it's about understanding organizational flows, business processes, and how different systems interact with each other. I expect a candidate to understand not only their area of expertise but also how that area serves the whole.
I talked to the candidate about an event-sourcing problem we encountered on an internal banking platform. I asked why the system became complex and about eventual consistency issues. They addressed the topic not just with technical terms, but by explaining "the financial risks that could arise if a customer's money transfer request was not simultaneous with its reflection in accounting records." This meant not just knowing event-sourcing, but also grasping its critical impact on the business. This level of understanding shows that a developer is not just a coder, but an engineer who understands the business.
Curiosity and Desire to Learn: The Real Engine of Growth
At the end of the interview, when I asked, "Do you have any questions for me?", most candidates focus on topics like salary, working hours, or the job description. This is natural, but the candidate who impressed me asked a very different question.
They asked, "In an ERP for a manufacturing company, what approach do you take regarding AI for production planning? Specifically, what challenges have you encountered in supply chain integration?" This question was directly related to my own experiences, particularly with iSCSI supply chain integration and AI production planning efforts in a manufacturing ERP. This showed genuine curiosity not just about the position, but about the future of the company and technology. I could have had another hour-long technical discussion with them.
Conclusion: What Am I Looking For in a Candidate?
In summary, the candidate who impressed me most in a job interview was not the one who had memorized technical information, but the one who could apply that knowledge to real-world problems, learn from their mistakes, see the big picture of the system, and was continuously open to learning. That day, I realized that the answers to the "how" and "why" questions behind a candidate's "achievements" on their CV are far more valuable.
What impressed you most in a job interview? Or what qualities did the candidate who impressed you most possess? Share in the comments, I'm curious.
