I’ve been to many interviews in my career. I’ve also interviewed many software engineers while building various engineering teams. Throughout all my interviewing experience, I’ve learned few lessons about interviewing software engineers.

How I conduct interviews

• No whiteboard questions* – they are a waste of time and their performance with whiteboard questions tells me nothing about how well they can code.
• Bring & use your own laptop – no excuses to underperform because of “unfamiliar computer” or “I usually use … code editor”.
• Open book – I want to see how/if they can leverage the existing content available in the Internet and any resources accessible to them to help them solve problems.
• Shorter interview durations – I usually only ask for 3 hours of their time for the first visit and 2 hours for the second visit. This way, if the first visit didn’t go well, we haven’t just wasted 5 hours.
• Project-based assignments – instead of asking many small questions, I ask the candidates to build one reasonable-sized project with the skills they already have.
• Make sure to allocate enough time for them to ask you questions.

* Unless the candidate is applying for a role that requires extensive work with algorithms.

I typically ask them to perform 2 things:

Start a project from scratch, based on my description

The objective is to learn how they naturally do things when they’re not given much instructions.

Make changes/additions to an existing project

The objective is to see how well they can adapt to other engineers’ conventions and way of doing things.

What you really need to know about your candidates

1. How they work, naturally

Observe their process. Watch carefully the steps they take to complete the tasks.

• Are they taking a systematic approach?
• What do they do when they’re stuck?
• Do they take enough initiatives?
• Do they ask enough clarifying questions?
• Are they asking the right questions?

2. Code Quality

• Do they use variable/function naming conventions?
• Proper indentations?
• Sufficient commenting?
• Efficient algorithms?
• Do they put proper assertions/validations/tests?

3. How fast can they produce?

Senior engineers tend to be able to produce much faster than junior engineers. This is a really good measure to gauge the seniority level of the candidates.

Also, watch how they prioritize their work.

4. Are they familiar with your teams’ technologies and tools?

Depending on how willing you are to train the candidates after they’re hired, you may want to observe and find out if they’re already familiar with the tools and technologies that your team currently uses.

5. How do they handle interruptions and changes?

While they are coding, I like to talk to them and see how well they manage their focus with my interruptions. I also like to change the project requirements mid-way and see how well they handle that – this is especially important because changes happens all the time in the real world.

“The only change is constant”

– Heraclitus

6. How well can they acquire new skills and knowledge?

I always ask the candidates to learn something new during the interview. I’d like to see what their process is like when coming across something they’re not too familiar with. This is a very important skill for any engineer to have. In engineering teams, we have to learn new concepts and acquire new skills all the time.

7. How well do they communicate?

Throughout the interview, I ask them to describe the project and the progress they’ve made so far. Observe how the way they explain things: clarity of their explanation, the words they use, and most importantly how well we can understand each other.

Remember, communication is a 2-way street 🙂 You need to be able to understand each other.

Keep this in mind:

Interviewing should be a mutual learning process for both the interviewer and the candidate. Make sure you learn enough about the candidate and make sure you also allow enough time for the candidate to learn about you, your team, and the company.

Hiring is not an easy thing, especially in places where engineers are in high-demand, such as the San Francisco Bay Area. If you are currently hiring or interviewing, contact me to discuss how I can help improve your hiring process.