What I learnt from bombing a technical interview
Today I absolutely bombed a technical interview. We are talking about levels of stuttering and brain-fog that I didn't know I was capable of. But determined to make this a learning experience and not something that happens ever again I thought I would write down the experience and what I've learnt.
About the interview
The interview was for a summer internship (software dev) at a pretty large trading firm. This interview was the first interview after the online assessments. It was described as purely behavioural but ended up being half-behavioral half-technical (amazing bait).
What went wrong
The interview started off alright. The behavioral section was pretty standard. "why do you want to work here", "tell me about x" , "tell me about a time when..." etc. I don't think it went amazing but I also don't think it went terribly. I glossed over some things, that in retrospect I should have said but had fairly-decent answers for everything. But then we got to the technical stage of the interview, and this is where I fumbled hard.
After finishing off her behavioral questions the interviewer asked me for my favorite programming language (I said python please don't judge me) and told me we would do a quick exercise.
The task was seemed pretty simple. The interviewer shared her screen told me to summarize what the code was doing. For context we are probably talking about 30 or so lines consisting of two classes with around 6 functions in total and a constructor. My brain stopped working immediately.
Seeing a bunch of unfamiliar syntax like @abc.abstractproperty decorators, and words to do with network protocols that I only had a vague understanding of immediately put me in a "I don't know what this is mindset". I freaked out over not understanding every aspect of the code when in retrospect I probably knew enough to give a decent answer.
What I should have done and what I think would have been perfectly fine would be to answer the question as best as I could whilst telling my interviewer that I didn't understand some parts of the syntax and code but make an educated guess as to what it was probably doing. This would have been far better than what I actually did (feel free to laugh or tease me), which was ummmm, ahhh and say "sorry I don't know".
Eventually after bombing the first 3 questions I found my stride, still answering in an unsure tone but giving more coherent answers that were probably correct. But by then it was too late, the interviewer gave curt replies and it was clear that the rest of the interview was nothing but a formality.
What I learnt
If you don't know you don't know. But try to answer anyways. Asking questions and giving an educated guess is far better than giving up
Be confident the entire time, don't let things phase you or lose your stride
Your entire "story" for behavioral interviews should be written out to make sure that you communicate yourself, your achievements and your background to the interviewer in the most clear, efficient way possible.
What I'm doing for next time
In the past I've practiced my replies for common behavioural questions (list here) but never for questions like "tell me about your background" , "tell me about x club at university" etc. assuming that if asked these questions I would just be able to answer them. But writing out model answers really helps improve the clarity of your response. So I'm going to be more thorough with this next time.
More mock-interviews with friends that isn't just DSA. Big one, been going hard on the DSA for a while, time to branch out a bit more.
Practice communicating technical ideas, I'm giving some lectures on algorithms at my university in the next few weeks. I'm going to use this as an opportunity to get more competent with formal technical discussion. Shooting the shit about my favorite web-framework with the lads = easy peasy, doing it formally != easy peasy. I talk rubbish and give strong opinions about things I saw once on Reddit with my friends all the time but communicating formally is something I do far less often. To improve this I'm going to look for more opportunities to be forced to talk formally about technology.
Published on 2024-04-09