On Interviewing

My thoughts on the interview process and whether technical coding tests are worth it.

I prefer a single-stage informal chat where possible, usually lasting around an hour long. I find it's the best way to get a good idea of the candidate's skillset, especially if they have a lot of experience. I don't see very much value in technical code tests. In my opinion the only thing worse than a mandated technical code test is an on-the-spot, while-we-watch mandated technical code test. Even if the candidate works well under pressure, you're still testing their ability to perform under unrealistic and impractical conditions. Who cares if they excel at something completely irrelevant to the role?

Sometimes, if torn and unable to decide one way or the other, maybe an offline coding exercise time-boxed to a week or so might give some pointers that can help. But I still find code tests more often than not are fraught with false-negatives which makes it difficult to take anything of value from them. In general, in my experience a coding exercise is just not worth it in the end. A big part of my reasoning on this is probably because I'm not really looking for low-level programming skills anyway. I'm far more interested in the following skills:

1. Strong communication skills - can tell when to be more/less technical, value knowledge sharing, good at listening to others before diving in with their own opinion. Ability to communicate well without becoming offensive or defensive. Ability to take and actively seek constructive criticism.
2. Enjoys learning - not stuck in their ways, always considering different approaches to problems, learning benefits of new languages/frameworks/technologies objectively without latching on blindly to the hype train.
3. Good collaborator - ability to defend position without being defensive, not afraid to run ideas by other team members, respects “heads down” time as well.
4. Can deal with failure - can identify problems/issues objectively. Learns from mistakes. Doesn't make the same mistakes over and over.
5. Humility - always being open to alternative solutions. Not afraid to admit mistakes. Ability to accept being wrong and consider alternative approaches. Doesn't have an attitude where they assume their solution is of higher standard than “lesser” colleagues. Acceptance that sometimes the best solution might not be technically the best, but it may be the best compromise.
6. Good at mentoring and being mentored - willingness to acknowledge areas where they want/need mentoring while also actively helping others when they can in an approachable way.
7. Good problem solving skills - value concepts over specifics, critical thinking, good at investigating root cause of problems and so on.
8. Strong work ethic based on trust - good working autonomously and being rated based on performance as opposed to heavy-handed, time-based micro-management (usually imposed by management due to a lack of trust).
9. Technically minded - strong on general high-level programming concepts, strong interest in technical problem solving, strong technical background in general.

Obviously, it's important to be able to actually code as well! But it's definitely not the most important skill and besides, it's much easier to figure out if someone can code (by having a discussion with them) than it is to score them on the above criteria. A good programmer excels at low-level programming skills. A good Software Engineer is a good programmer plus all of the above. Even the most technically focused role is still more about working in a team than being somone who is shit-hot at a particular language but hates talking to anyone or sharing knowledge. In general, code readability is far more important than using advanced coding techniques that reduce readability. The ability to clearly and patiently teach how a system works in an approachable and non-offensive manner is far more important than being the only dev in the building who understands it!

When I tell people I conduct interviews as an informal chat, sometimes they get the wrong impression and presume I'm just being lazy or that it's just an easy way out so I can get it over with, but it's quite the opposite! Conducting interviews fairly and with a view to getting as much value out of them as possible for both parties is one of the hardest parts of my job. I find candidates respond to the "informal chat" format extremely well, not because it's easy but because they are being seen as individuals and being treated fairly. It also helps to relax the candidate and make them feel at ease so we can really focus in on finding out if we are a good fit for them and vice-versa. It reframes the entire interview from being a one-sided meeting with an interviewer leading from a position of superiority and an air of suspicion to something far more authentic and effective - a back-and-forth chat where the candidate is just as likely to be asking the questions as the interviewer.

A lot of interviewers start by describing the role. This is a waste of time because most of the time the the candidate isn't even listening at this stage! They are too busy freaking out whether there will be an on-the-spot technical test! This is why I always start by explaining up-front there will be no tests or on-the-spot technical trivia - it will be an informal discussion structured around their CV. I find this instantly puts them at ease. Next, I ask the candidate to walk through their CV and give an overview of each role, their technical skills, programming languages experience, etc. I try very hard not to interrupt them during this part - the purpose of it is to provide the context for the rest of the discussion, so I'm hoping they cover a wide range of topics that I can revisit when asking questions later. One way I avoid interrupting is because I'm too busy writing notes but I have to be careful about doing so. I often make a joke "I have a terrible memory so I'm just writing down reminders so I can't come back to them later" or something like that. Again, this puts them at ease and helps prevent them from wondering "what is he writing about me? Did I just say something wrong?".

After the candidate has finished summarising their CV, I begin asking questions such as “what are you most proud of?” and “can you discuss a project you hated and why?” and “discuss a time when you made a mistake and had to recover”. However, it’s better to avoid asking those questions generically without any context as that puts the candidate on the spot and they might rush and choose a suboptimal example. So I try to focus the questions on the candidate’s experience as that makes it easier for them to choose ideal examples from stories they have already mentioned in their CV summary.

Here are some more guidelines I try to follow for getting the best out of the discussion:

1. I always have some questions prepared beforehand just in case as a back-up but I try to avoid generic questions - they should be always be based on the candidate’s CV if possible.
2. I try to steer candidates towards talking about high level concepts in a back-and-forth chat format rather than short, specific answers to low-level programming trivia. For example, if the subject of immutability comes up, rather than a generic question such as “What is immutability?”, I try to frame it as a discussion by asking something like “You mentioned immutability when talking about Project X a minute ago. Can you tell us more about that?”. Hopefully the candidate will discuss why they did it, maybe even go into some functional aspects of it and talk about their other experiences with it (maybe in different programming languages where it is enforced for example).
3. Throughout, I'm always trying to get a feel for if they are a good fit. I'm looking out for all the qualities listed in the section above and looking for opportunities to dig a little deeper on any one of these qualities based on what they are saying.
4. I always try to take notice of how the candidate acts when discussing their experience. Are they enthusiastic? Are they pragmatic? Are they passionate?
5. If they bring up certain technologies/frameworks, I ask them to dive into it a bit more if they haven’t already and try to focus their answer on a specific real-world example. Questions such as “What did you think of it?”, "What company did you use it at?", “Advantages/disadvantages” and “would you use it in the future (if not, why not)?”

6. Some general topics I like to consider depending on the type of role:

   1. High level thoughts on databases - not necessarily AWS but in general. Experience in relational databases? Thoughts on NoSQL, maybe they discuss a specific technology like Mongo. That's fine but try to steer them towards the high level aspects of it rather than getting bogged down in technical detail.
   2. Thoughts on testing. Looking for a pragmatic approach to things like TDD. I'm looking for them to discuss their experience with unit testing honestly. It's far better if they discuss openly how they struggled with coverage based on a real example rather than some textbook "always test everything" generic answer.
   3. Thoughts on pair programming. Prefer honest "It has its uses but … " answers over systematic answers like "I would enforce it and expect it to be implemented perfectly via the following 42 steps" or overly extreme and blunt answers like "I hate it and I refuse to take part".
   4. What do they think about UI/UX? Look out for bad attitudes like "UI is simple" or "UI doesn't matter". Do they care about UX? Do they talk about an experience they've had before where they dealt with colleagues who didn't care about it?
   5. Thoughts on different types of programming paradigms such as functional programming, OOP, etc. Again, looking for high-level opinions, not specific programming details around syntax.
   6. Thoughts on software delivery process based on specific examples form past experience. Things like Continuous Integration, Continuous Delivery. Benefits, drawbacks, etc.

It’s easy as an interviewer to forget how one-sided the interview process can be. To the interviewer, it’s just another meeting in a familiar environment where they know exactly what’s going to happen and what they are looking for. To the candidate, it could be life-changing, everything is unknown, it’s an unfamiliar environment and they have no idea what to expect or how they are going to be treated. This puts the candidate at an immediate disadvantage. Unless this inequality is defused right at the start, there is an extremely high chance of false-negatives and a danger the entire interview will end up being a waste of time for both parties. Or worse, the interviewer may make a decision to hire or reject the candidate based on these false-negative which sadly, is often the case.

To summarise, the informal-chat approach is based on the interviewer and the candidate starting from a position of equality forming a balanced discussion with questions coming from both parties where the goal is clear - to find out if the company is a good fit for the candidate and vice-versa.