I didn’t hire you for your spelling: Skills that don’t matter in tech hiring

I didn't get hired as an Engineering Manager because I could spell well. I use spell check for that.

Interviewing needs to be aligned with the actual responsibilities of a role. That seems obvious but so often questions in technical interviews feel like a series of hoops to jump through.

If you’re asking about binary trees, does your team use a lot of binary trees?

If you’re asking about designing a system, is that something this role might have to do?

  • SEIs and SEIIs aren’t usually left to design a new system from scratch.

If you’re quizzing them on algorithms, does your team need to memorize facts to regurgitate at a moment’s notice?

Instead, I like to organize technical interviews around the 3 main things software engineers are going to do in their role.

  1. Fix a bug - Can you read code to identify and fix a problem?

  2. Add a feature to an existing system - Can you read code and extend its functionality?

  3. Create or scale a system - Can you gather system requirements and discuss tradeoffs when building something new? (For Senior+ roles)

And there you have it. 3 technical interviews. Now you can customize the language, algorithms, and data structures that your teams actually use.

These interviews should tell you how well a candidate is going to approach the problems your teams actually tackle. It should also inform the candidate about the role and the team. Designing an interview this way benefits you as the hiring manager and makes a better candidate experience!

Previous
Previous

First 90 Days

Next
Next

An Elegant Puzzle