Skip to main content

Tech Interview

Technical interviews are broken, and everyone has known this for a long time.

  • The quality of conducting technical interviews by interviewers is very low.
  • Consequently, 90% of developers spend all their available time for growth memorizing useless questions from these interviews, and as a result, they do not focus on truly important things.
    • 100% of developers who have come to me for technical interviews (throughout my entire career) do not understand what Continuous Integration is, or cannot fully explain it.
    • 90% of developers have never written tests, or have a very poor understanding of their purpose.
    • 85% of developers do not understand whether they use any patterns in development.
  • As a result, we have very low interview quality, interviewers, and companies in terms of software engineering development, and consequently, a very low level of professionalism in specialists.
  • 70% of candidates thank me for my interview with the following words, 30% say nothing. This shows that at least 70% of companies/teams/interviewers are breaking the interview process in our industry:
    • "I've never had such an interesting interview in all my experience."
    • "Usually, the feedback from interviews only includes memorizing JS, React documentation, and writing a palindrome. Here, I learned so much new stuff."

Remember: A technical interview is:

  • The face of the interviewer as a leader or engineer, the team, and the company.
  • An opportunity to present yourself to the candidate.

Candidate's Goals in the Interview​

  1. Demonstrate their knowledge and skills.
  2. Learn about the role and responsibilities.
  3. Determine if the company and project are a good fit.
  4. Form an overall impression of the company.
  5. Assess whether their level matches the specific requirements.

Interviewer's Goals​

  1. Learn the current level of knowledge and skills of the candidate.
  2. Evaluate the candidate's ability to learn and adapt.
  3. Determine whether this combination of factors matches the demands and challenges of the project and role.
  4. Understand whether the candidate can become part of the team.

General Flaws​

  1. Strict and rigid processes, matrices, questionnaires, and so on.
  2. Criteria based on "answered or not answered" standards.
  3. Interviews for a "position" rather than a "role."
  4. Assigning interviews to those who are "not well hidden" rather than those who have the competence and desire.
  5. Feedback can only be obtained by threatening physical retaliation.
  6. Both sides fail to understand that an experienced interviewer can uncover lies about a candidate's work experience with one or two questions.

Interviewer's Mistakes​

  1. Strictly following a procedure and a list of questions.
  2. Testing the candidate's ability to memorize rather than draw conclusions.
  3. Failing to interest the candidate in working on your project or team.
  4. Failing to ask about practical experience even if the candidate is a beginner.
  5. Trying to stump the candidate.
  6. Failing to ask clarifying questions.
  7. Failing to assist the candidate.
  8. Failing to take notes during the interview.
  9. Failing to provide feedback as quickly and as thoroughly as possible.

How an Interview with Me Goes, as an Interviewer​

  1. (2 minutes) Introduction, explaining the structure of the interview.
  2. (5 minutes) Talking about the company, our product (including a demonstration of the landing page), the team, tech stack, processes, and something interesting for engineers (such as the presence of an Engineering Playbook). I try my best to sell this position to the engineer.
  3. (5 minutes) Answering the candidate's questions.
  4. (5 minutes) Asking the candidate about their greatest challenges and achievements in their software development experience: this question helps you understand what is important to the candidate, and what their values are.
  5. (60 minutes) Technical interview:
  • The interview is conducted as a dialogue—each answer leads to the next related question.
  • I do not ask questions about specific technology specifications.
  • However, there are questions about technologies, but they are structured as you will see in the following point.
  • Almost all questions take the form of: "Explain why you would use technology/approach X, but more interestingly, what drawbacks of such an approach/technology do you know, and what alternatives do you know?"
  • Questions in this form allow me to understand the person's experience, critical thinking, attitudes, and analysis of what they use or do. To discuss the drawbacks of any approach, technology, or architecture, you yourself must be quite experienced. Because each answer to such a question allows you to fully assess the candidate and ask further questions based on their response.
  • I also occasionally tell the candidate cases related to the specifics of our project and ask them to describe their reaction, thoughts, and sequence of actions.
  • Of course, I have a list of topics and questions (2-3) that are important to me when selecting a future team member. Overall, this is a collection of best practices in software development. Therefore, the entire interview revolves around them.
  1. (5 minutes) Answering the candidate's questions, and informing them of the final feedback deadline.
  2. (After the interview) Writing detailed feedback on the candidate and sending it to the recruiter.