Navigating technical interviews and tests
Technical tests are becoming part of the norm during the interview process, so Roy Bailey has outlined what you should be focusing on when it comes to navigating technical interviews and tests. It’s time to look at the value, rather than the cost of things.
Since I started my career over 20 years ago I’ve seen a steady increase in the use of technical tests during the interview process. While these exercises have some value there are a lot of testing techniques that do nothing but stroke the ego of the interviewer. These tests can produce judgements based on unrealistic or irrelevant scenarios.
I’m careful to watch for ego driven test exercises and ensure my team remember to leave their egos outside the room! These technical tests brings to mind the erroneous practice of focusing on the ‘cost’ instead of the ‘value’ of something.
‘Cost’ focusing part of a technical test looks only at the binary knowledge and speed benefits a candidate brings, their ability to:
- Recall technical detail and remember all related knowledge without any reference notes, past coding exercises, google, or the ability to ask colleagues
- Code on paper (what the…?) under extreme time and oversight conditions
‘Value’ focusing part of an interview seeks to understand the broader less tangible benefits a candidate brings, their ability to:
- Understand concepts, patterns, best practices
- Question, collaborate, compromise on design
- Consider the full life-cycle of a change, not just the fun coding part
- Make pragmatic technical decisions on delivery time and complexity
- Manage technical debt as part of business delivery
- Think about ‘total cost of ownership’ issues like production support
- Develop balanced engineering solutions (not under or over engineer)
- Analyse requirements, analyse existing code and diagnose issues
- Bring ideas and energy to a project
- Learn, adapt and improve
Thus it can be said an ability to recall technical detail and spit code reduces the ‘cost’ in time and effort (at least for those questions in the test). Meanwhile, I would argue the ‘value’ someone brings from their understanding, integrity, attitude, and decisions making skills are far more important in the final decision to hire. The best people I’ve worked with are those with curiosity, enthusiasm, desire to learn, and an ability to share ideas. Regardless of their knowledge or skill at the time of hiring.
Like the resume screening process, the technical interview is little more than a shallow screening exercise detached from the value and potential someone can bring to an organisation.
Software has grown to such a scale you can only know a tiny fraction of what’s out there. More than half of the technical detail you learn today will be obsolete in another two years anyway. Furthermore, most developers will only remember the details on the last few months of whatever they’ve been working on.
Time and again the best people are those that question, learn, collaborate, improve and share knowledge. Regardless of whether onshore, offshore, young, old, or whatever experience level they are in the technologies they’re assigned to work with.
A technical test does not protect you against the technical test passer who:
- Leaves you with unmaintainable overly complex ‘look how clever I am‘ code
- Delivers fast but then spends more time bouncing back from QA and puts production at risk
- Is unapproachable, has a really poor attitude on knowledge sharing
- Is good at passing technical tests or has read about your technical interview exercise online first, but actually can’t deliver in the real world
- Goes their own way against the organisations strategy, technologies or standards
My golden rule for interviewers and interviewees when dealing with technical tests is simple: The interviewer should always share the complete and correct answers ‘in their mind’ regardless of how incomplete the interviewee was able to answer them.
This has two major benefits. Firstly, by sharing the answers the interviewer does not hold onto the position of power (their ego of knowledge) and this releases some of the judgement already stored up (the interviewer is now vulnerable). Secondly, the interviewee gets to ask questions and share reasoning (like why they didn’t suggest that answer).
From this you both gain a better understanding of how you would collaborate in a team situation, and this yields insight into how to better ‘assess’ someone instead of judging them with ‘ego driven testing’.
This article originally featured on Roy Bailey’s blog about Software Research and Management.