Yet Another Opinion

I've recently started conducting technical part of the software developer interviews again (I did quite a bit of it before as IPONWEB and Booking.com), and thought I'd summarize some thoughts and ideas on how it works best for me, from the interviewer's side - but also from the candidate's side, too - as I've been on that side a lot last year, I have a fairly solid opinion on that too.

Being real

What I think works best for both sides is being real in the choice of assignment and questions about the results - meaning, solving problems and using techniques that would apply to a real day-to-day job. It's best when it could relate to what company does - e.g. if company builds an online email platform, a question about how to structure and store and search through email tags/categories is very relevant. But it doesn't have to be that specific - any sort of realistic hands-on task is good, as long as:

• it doesn't hinge on specific language quirks, like e.g. using this in function vs arrow function;
• it doesn't imply just one correct solution (there might be a limited set of ways to do it optimally, but there shouldn't be only one way to do it);
• it's not an algorithmic puzzle of "you either know it or you don't" kind;
• it doesn't heavily relies on candidate following any by-the-book principles such as SOLID or any other.

I think there's many real-world scenarios that could lead to a discussion of efficient algorithms, data structures, coding practices, design principles, collaboration and so on and so forth - but it needs ho be realistic, it needs to be relevant.

The way I like it

The interview flow I enjoyed as a candidate - and I try to employ as an interviewer - looks (roughly) like this:

• Starting with a simple hands-on task, like parsing a CSV data or reading structured data from a source or aggregating provided data - for the interviewer, it provides a way to estimate the communication detail level required for the interview, the pace, maybe some areas where candidate might require hints; for the candidate, it's a simple and focused start without a need to understand the large scope and a chance to shake an anxiety and get into the flow.
• Once initial scaffolding is done, expand the requirements to process the data or introduce additional variables to the system - e.g. for the data parsing task, it could be calculating total amounts per column and ordering it, or extracting unique values. This stage could be iterated several times over, adding extra columns to the data processing (ordering by several columns is a good exercise), or adding several steps to data processing/filtering/transformation. It provides an understanding on how well candidate build on the foundation, how they expand the problem perception and if they can keep up with changing complexity - and also if their solution is flexible enough to accommodate new requirements, their coding style is readable, they can modularise the code to make it reusable and understandable and so on. For the candidate, it's often the part with the most fun because it requires to really think how to adjust and adapt and make it work, which closely resembles how things evolve in real-life projects.
• When enough iterations have passed and the solution provides sufficient insight in the candidate's skills, or the interview time is running out, I find it useful to leave enough time to discuss the solution and potential improvement points, and also ask the candidate why they used specific data structures or approach - it's nice to have a conversation, and it gives the candidate an opportunity to express themselves and maybe explain things they've struggled with or provide extra insight into how things should work.
• In the end, leaving some time for a free-form Q&A for teh candidate to ask any questions is also a useful part: they might want to learn more about teh company and teh people they will potentially work with, and what questions they ask might also be a useful information.

The unexpected

Sometimes, things don't go smooth, for various reasons. What's important is to provide the candidate enough space to think and try things, but also to be there for them to answer any questions they have (and encourage to ask those questions), and to tot let them hanging - if they're struggling, providing some hints or asking them to elaborate on whet they want to achieve is really helpful. And just being polite and professional and compassionate - interviews are hard and stressful and exhausting, it's a MUCH harder work for the candidate than for an interviewer.