This content originally appeared on Level Up Coding - Medium and was authored by David De
I have taken over 150+ interviews, quite a few as a Bar Raiser at Amazon, and have given interviews well in the high double digits in total, at places ranging from small startups to Big Tech. After seeing myself and other candidates succeed or fail in many of these technical interviews, I wanted to share my thoughts on how I approach these technical interviews.
First off, I wanted to clarify what I mean by A Technical Interview. These are generally one-on-one interviews designed as peer programming sessions to solve a coding or system design challenge. The candidate drives the session by coming up with different solutions and discussing its tradeoffs.
I would broadly classify all factors into (a) Controllable (b) Uncontrollable factors. The Controllable factors are those that I can work on and get better at, like Knowledge of data structures and algorithms, distributed system design skills, general problem-solving abilities, etc. These are generally a function of effort, i.e., the more time I practice these better I get, but the moment I take a break, these skills start to fade. In a subsequent article, I will talk about how I approach the Controllable factors, but I will focus on the factors now.
On the other hand, Uncontrollable factors are more nuanced. These factors are a function of pure chance; for example, it could range from what my mood was while giving the interview, like when I had trouble finding the right building and got stressed out that I would be late. How much time the does interviewer take to chitchat before starting with the actual interview? I remember one time when the interviewer was late for the interview; he then took the time to introduce himself and asked me to do the same. It was already quite late by the time I got to work on the actual coding challenge. And as it was my first interview, it tanked the whole loop for me as I couldn't concentrate fully in the subsequent discussions.
Today, my approach to Interviewing for a Software Engineering position is less like an examination and more like competing in some competitive sport.
- Before an Interview Loop, I do not obsess over the outcome of the Interviews but on the Controllable factors. As the outcome is a function of both Controllable and Uncontrollable factors, the only thing I can do is keep getting better in the Controllable factors improving my odds. I also believe that Interviewing, just like any other competitive sport is a numbers game; the better prepared I am with the Controllable factors, the better chances I have, but it's never guaranteed.
- After an Interview Loop, I do not take the outcome personally. By that, I mean pass or fail, I don't consider it all my doing, or I am the only one to cheer or blame. What I do is retrospect on what went wrong; if it was one of the Controllable factors, I work on them, but when it is not, I move on.
An interesting observation I have made that backs up my approach is that many engineers who are or have been working in one of the FAANGs have either got in after several tries or have given interviews at several of the FAANGs got rejected in some while accepted in others. This can be due to a lack of preparation for one of the FAANG companies while not for the others, which would imply that one has more demanding standards than the other but looking at rejections and acceptance, it is relatively arbitrary. I have seen some failing Amazon and getting an offer from Google, while others just the opposite. I have also seen some who failed their Amazon interview the first time, then crack it in their second or third try in 6 months or a year. I am confident that a very similar result will pop up with most other companies if I or anyone else retries after failing the interview loop would get in the second or third attempt.
I will end this article with this lesson: keep trying. And stop focussing too much on the outcomes; instead, keep improving on the Controllable factors. Failure is part of the plan, just as Success is.
Failing Interviews as a Software Engineer was originally published in Level Up Coding on Medium, where people are continuing the conversation by highlighting and responding to this story.
This content originally appeared on Level Up Coding - Medium and was authored by David De
David De | Sciencx (2022-04-06T12:51:19+00:00) Failing Interviews as a Software Engineer. Retrieved from https://www.scien.cx/2022/04/06/failing-interviews-as-a-software-engineer/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.