Becoming a dungeon master for an interview

I've just went through a round of interviews from various companies after being made redundant from work 4 months ago. Admittedly the job market was really quiet but it was eye opening the differences in interview techniques and processes.

I had one interview from a FinTech company which I actually thought went quite well, the next day I got a rejection stating "I need to improve my STAR technique". I just rolled my eyes thinking FFS

Another company the CTO wasn't on the call but had asked to record the last 15 minutes of the interview with questions he'd prepared, I was close to terminating the interview. If he couldn't be assed sitting in on the interview why should I answer questions the interviewer himself didn't understand. One of the questions was "What is triple D". I'm an experienced dev, fully aware there are too many acronyms in the industry but had never heard of triple D before, when I googled it after I was thinking FFS, that's just what any competent dev does by default. I guesses data driven development but admitted I wasn't sure.

Another interview the principal engineer yawned 3 times when I was talking before I even got to the half way stage, not one apology. I know it's just human nature but to not even acknowledge he was making me uncomfortable reminded me afterwards that it's probably a toxic work culture, which I've been told since is the case from people who worked there.

Thankfully at the start of the new year I was offered 3 roles, 2 of them I thought I'd screwed up the interview. The one I accepted, apart from taking on a task to review some code and raise issues with it, I was asked to describe an architecture of some system I'd worked on and enjoyed. I spoke too long, going past the interview time but didn't feel I explained the whole system.

I understand interviewing candidates is difficult, I've had to do it a few times in the past but the competency of interviewers and the process to score candidates varies wildly from organisation to organisation. A realisation for me although I was already aware of it, is the personality of the people interviewing you varies wildly, more often than not it's a good indication of the organisation itself.

When I get a system design question I always tell the interviewer "I'd just run it on a single server with an SQLite backend, that will be plenty for the median software service and you haven't told me any numbers that suggests this needs more" and then it turns out they wanted it to run at the scale of WhatsApp.

Usually it is expected that you ask yourself what is the expected traffic, but I usually answer with a number that technically one box could handle.

I also think that might be true. Adding friction filters out candidates who have more choices, which are likely to be the top performers. Hardly anybody wants to work specifically for one particular company, so the people willing to continue despite friction may be more likely to be middle performers.

I think the "fake product" interview is a great format, but it can be done poorly if the setup is unrealistic. I've been on the receiving end of a couple of very bad attempts.

In one, which I have described here before, an interviewer asked me to design a system for selling concert tickets. After half an hour of confused back and forth, it emerged that they wanted a network service that replied to requests with unpredictable random integers, which did not repeat, unless the service rebooted and then it was okay if there was an accidental repeat. Needless to say, I started with a lot of assumptions based on the idea of selling concert tickets, and I don't think it reflected poorly on me that it took so long to figure out that the real problem they were judging me by was so radically different from the one they asked me to solve.

I had another interview recently which had a similar wrinkle. The interviewer asked for a system to solve a very particular problem, which because of the particulars of the problem would involve receiving very small amounts of data from systems in the field. The interviewer asked multiple times about the cost of data ingress and data storage, and each time I deflected them, saying that it wasn't significant compared to other costs in the system. I was so focused on solving the problem as stated that it didn't dawn on me until later that the interviewer likely had a different problem in mind in which the data was much bigger, and they were evaluating whether I could be sensitive to those costs and design an economical system.

Interviews like these are very frustrating, and I don't think they will lead to great hires. You will end up hiring people who solve the problem you have in mind even though you told them to solve a different problem. These programmers will have the same biases and preoccupations as you, which might make them easy to incorporate into your team, but they will probably have the same blind spots as well, which means your team will be less prepared to solve new problems in the future.