Member-only story
The Only Programming Interview Question You Need to Prepare For
Despite sitting in 500 interviews, it all boiled down to one thing
I have appeared for about 500+ programming interviews in my entire software career.
Barring my first job, in almost every interview at the beginning of my career, I was extremely stressed. I used to read a lot about:
- Programming concepts (what is a thread, lock, and semaphore)
- APIs that I put in my CV
- Complex algorithms that solve problems such as sorting, searching, and ranking
That took almost a week’s time. And worse, it made the entire game infinitely high-stakes, even when the prospects weren’t great from the beginning.
Soon after the interview was over, I realized there was no need for me to waste all that energy and time. Most of the things I read weren’t asked anyway. Even if they were, I knew them by heart already.
The mere presence of a looming interview event forced me to disrupt my otherwise calm mindset.
The Interview Challenge:
The interview process isn’t really a challenge. It rather reflects the constraints of the interviewers’ minds.
In the early days, face-to-face interviews mostly included writing some kind of code.
At that time, most of my problems had to do with the challenge interviewers faced: they did not have enough to measure a candidate’s building capacity, so they beat around the bush.
Asking about a lot of concepts and analytical problems gave them a peek inside the candidate’s mind — which was often incoherent.
From the candidate’s communication, they inferred things to finally outline the entire judgment with one sentence:
He is good enough to figure it out some way/not good.
This inevitably put a lot of pressure on the candidate. Instead of solving a problem in N possible ways, they had to think about what would really convince the interviewer. If they got distracted on the first try, the interviewer will take…
