The Three Types Of Tech Interviews: Is There A Right Approach?
- Zsolt
- Apr 15
- 5 min read
Looking for lacking, Looking for Stan, and the best way.
Frankly, there are infinite ways to conduct (tech) interviews. BUT! If some psychologists are allowed to box all of humanity in just 4 categories (DISC), then I can do the same with interviews. It is also to help you prepare for the interviews, as most of the time, you can tell by the LinkedIn (or other) job posting what type of interview it will be.
Looking for lacking
This is the worst one, and the one you can prepare for the least, but in my experience this is a rarest as well. Many times ‘Looking for Stan’, and a presumable right kind of interview can turn into ‘Looking for lacking’, really depends on the interviewer(s), and the dynamic of the interview.
Do you even deep copy, bro?
Famously, one of my friends was interviewing for a developer role, which required JavaScript knowledge among other things, so naturally, the interview included a few JS questions, like listing a few ways he usually deep copies objects. Nothing problematic so far.
Being the senior he is, he listed the usual suspects JSON, lodash, doesn’t really matter, what matters is that the interviewer asked the followup:
What about Object.assign?
Confused, he then asked what they meant, since that function only creates a shallow copy. The interviewer disagreed, and they left it at that. (to be clear, Object.assign does not deep copy. It makes me wonder about the bugs that codebase must have 🤔)
“Looking for lacking” interviews focus on finding what the candidates don’t know, or don’t know well enough, which is plain mental! It is inherently a flawed premise, there are infinite things we don’t know and a very small finite set of things we do. Especially in a stressful situation, especially by heart. They usually ask:
some ultra-detailed question about some library’s one specific function
some more generic questions, but one expected right answers
always one more detail
You may start from how a website is loading through HTTP and end up discussing packet switching.
By the way, these interviews suck at assessing skills and levels for the same reason automatic assessments such as LinkedIn’s or PluralSight’s do: the questions are either super basic, and so everyone is a rockstar-emperor-evangelist-expert, or they probe around in very detailed parts of the framework or language, so if you haven’t specifically researched/learned that part of it, you won’t know the answer. In most cases, they ask increasingly harder questions in different areas but then back off a bit if you seem not to know that part well enough. Despite their best efforts, these tests don’t measure a thing. After viewing a 2-hour long video on React I could get an expert score. Same with a Swift course. Surprisingly, I am hardly an expert in either.
Looking for Stan
We have Stan on our team. Stan knows React very well, he’s not lost with k8s, uses WebRTC like a pro and REDUX is his soul animal. Stan is great. We want one more Stans, maybe Stan has given in his notice. What do we do?
We want you to be familiar with the exact stack we use so that you can hit the ground running. There is no time to waste on potentially better-fitting candidates who might need a month to learn the mysteries of REDUX and web sockets.
We’ll probably call you Stan for simplicity.
It’s not wrong to list the stack you use, but it’s not the best to fish only for people already working with it.
Here’s a counterexample:
In a separate section, they list all the relevant libraries and tools they are using, BUT the requirements only say: “okay, we need a frontend person who has worked with modern and widely used technologies and methodologies”. Like 90% of web/frontend engineers. Of course it’s not the right economy to be picky, but really, it’s the companies Looking for Stan who miss out big time. I have just started working with a few engineers who mostly used Java previously, and guess what, this project does not have Java. It works, and they are great.
Job posting to interview
This is easy to spot, as exemplified above, and the interview is just the way you’d imagine in most cases.
On the extreme end (and this is a true story): they were looking for an Angular developer. I have worked with Angular, and the position other than Looking for Stan seemed okay, so I applied. On the technical interview, they opened up the Angular documentation on a laptop and started to ask questions from that topic-by-topic. I passed, but I don’t consider it a good interview.
In general, these interviews can go both the good way, or turn into Looking for lacking. They probably will ask only (mostly) questions about the stack they listed as a must in the posting. The difference is in what they are looking for: mistakes you make, gaps in your knowledge in the deepest parts of, say, Angular, or maybe they want to understand your previous experiences with said framework, the kinds of features you have already used, the issues you might’ve faced and how you solved them.
On the bright side
Looking for Stan is the easiest to prepare for. There’s no guarantee the interview will go down as I have described, but there’s a higher chance than with regular job postings where they are more vague about what they want. They are Looking for Stan, if you’re interested in the position, prepare to show your stanest side. Are they looking for React+Redux? Watch a few courses before the interview! I didn’t pass said Angular interview because I use form generators and template outlets every single day.
Looking for experience
I recognise that this is the hardest for interviewers. How to conduct an interview without a predefined, set-in-stone agenda?
learn about the candidate: read the CV and make notes
learn about the candidate: ask questions relevant to both the project and their experience
learn about the candidate: reflect on their answers and ask follow-ups
learn about the candidate: is he a junior? Does he have a GitHub page? Open it together and talk about the code there if you can’t talk about his past work.
Feel free to stone me in the comments for this, but it’s also fine to give small exercises, the usual ‘what does this print out’ or even a simple coding exercise as long as it’s to see their train of thought, not to see if they know the ‘trick’ you hid there.
An example of a coding exercise and the discussion it might start:
On the upside, an open discussion, mostly about the candidates’ previous projects and challenges, is probably a good recruitment experience and gives a clearer picture of the candidate’s personality and knowledge (as clear as possible within the time limits of such interviews).
There are downsides as well, naturally; for example, it’s harder to compare candidates when you don’t just run down on a list of questions and rate the answer 1–3. It takes more social skills from the interviewer, which narrows down the potential interviewer pool.
Many people are not comfortable in a position, where they are interviewing someone and yet they don’t know more about the topic than the candidate.
I don’t think I have to introduce impostor syndrome to anyone in software engineering. This kind of insecurity can lead to Looking for lacking sorts of situations, and in my experience, it is more common than how much it’s being discussed. To be completely honest, trying my best I’m no exception either. I remember once asking my revered colleague who was joining as spectator:
‘how am I supposed to interview this guy with 20 years under his belt, while I have barely 7?’
‘The same way’, he said.
What to read next
If you enjoyed this read, you might also like this one:
Comentários