🎙️ Interview

Updated at 2018-07-31 15:35

Being the Candidate

Don't go into an interview with a mindset just to answer questions. Plan to have meaningful conversations to appear more human and show that you can work in a team. Research a bit about the company and industry beforehand so you have a more meaningful conversation.

Listen carefully and follow their lead. Try to make each question and conversation.

"How would you handle a difficult client?" Tell your strategy then follow up with "What is this firm's strategy around client management overall?"

Being the Interviewer

Make candidates feel welcome. If they need to wait more than one minute, give them something to read, place to sit down, a cup of coffee etc. Avoid the interview escalating to a competition of who is smarter, the interviewer or the applicant. Your assumption should be that the applicant is smarter and you are there to proof it.

Don't sit on the opposite sides of a table. Sit orthogonally, it's not a police interrogation.

You need people who can write clean and working code. You don't need geniuses, leave them to academia.

Suggest having interviews on weekends. You seem like more fun and laid back company and usually this works better for the candidates as they might still be working in another company.

There should be only one interviewer in the room with the applicant. Use positive and trusting people, they tend to be the best evaluators. You should have absolutely tops 6 people interviewing a person and one interviewer at a time.

Make it feel more like a conversation than an interview. Allow the candidate to ask questions. Ask follow-up questions.

People usually show their best side in an interview. Trust your instincts. When you think someone is not good, that is usually true. The applicant probably will not fit in if:

  • Applicant has past performance issues.
  • Applicant tells you that their last boss was a jerk.
  • Applicant only wants to talk about how fast he might get promoted.
  • The interviewer feels that he wouldn't stand to grab a drink with him.
  • The interviewer feels that he wouldn't go up to the applicant to say hi if recruiter saw him in a bar so that the applicant would not see him.
  • The applicant were only one in office on Sunday and recruiter would not feel urge to go to the office.

You should have four ratings for applicants. Nope (-4), don't know (-2), yes (+1) and superstar (+2). You need to learn to tell the difference between a maybe and a superstar. Note that the person might not be right for the role, but so good guy that he should be hired. You can also have two rating; one "human" and one for "skill" for that particular role.

You should only hire people that score way above zero. Average candidates can be either good developers or bad developers. It is better to reject a good candidate than to accept a bad candidate. Bad employees make bugs and demoralize good employees.

Ask a few open-ended questions. Helps rooting out pathological liars as their stories get incoherent. Unanticipated questions are also harder to answer. If you find a contradiction, resist the urge to correct them right away, let them make more mistakes.

Consider a little bit of whiteboard coding. Writing to whiteboard is not about testing candidates ability to write code. It's to test how well you do under pressure and still brainstorm ideas. If the candidate is not thinking-out-loud, ask him a lot of questions.

Good developer questions:

  • What was the last project you worked at your former employee?
  • What do you feel being the greatest accomplishment in software development?
  • What projects are you working on in your spare time? Which one is your favorite?
  • Do you participate in any online tech communities?
  • Tell me about some tech related issues you feel passionate about. What is the last tech related blog or article you've read?
  • Do you follow emerging technologies e.g. frameworks, tools or languages? What languages have you learned recently? What did you think of it, compared to Y?
  • When you were learning to program, what was most difficult to understand?
  • If you could enforce single coding rule to entire world, what would it be? Why is that?
  • What IDE or code editor do you use? What do you think of it?
  • (ask about the assignment if they have made one and you've read it)
  • (ask a few technical questions per technology in resume)
  • (ask a few questions how they feel about the current technologies you are using internally)

Don't stall. Give the candidate an answer as soon as you know it, but not right after the interview. It should not take 2 weeks.