How to approach the coding interview and leave with a fresh excitement to continue your job search.
I have never been great with dealing with pressure or being put on the spot, and taking a technical interview was precisely that. Doubting my abilities was second nature to me, and I preferred to familiarize myself with new technologies before using them for any hackathon. I would shy away from HackerRank preliminary stages while applying for jobs, too afraid to take them in fear that it would be a waste of the interviewer and my own time.
After being offered guaranteed interviews at Intuit from SLO Hacks, I followed a similar pattern, ending up so scared that I wanted to simply decline the opportunity. However, my peers convinced me otherwise, prompting a session of encouragement before sending me off to nervously beginning my interview process.
Photo by Janet Fang
The first stage was the very same challenge that I had been actively running away from for the past couple months — a static, unmonitored coding problem. The very prospect of being graded on my code had already sent me into shivers, causing me to spend excessive time trying to prettify my solution on elements that most people do normally.
- Renaming variables. This past habit stemmed as a result of attending hackathons and coding only for myself. When wanting to test out a variable, I would end up naming them quite arbitrarily, ending up with undescriptive nonsense like “asdf.” At the moment, I slumped back into my old practices, thus leading to a degree of confusion while completing the problem.
- Scoping variables correctly. Especially in a language like Javascript, where I used to just use var for everything without consequence (dark times), I usually take extra care to make sure that each variable is accessible where it needs to be.
- Prettifying my comments. As I write out solutions to problems, I tend to write out my thoughts in comments, generally using text-lingo, which ends up producing an incomprehensible note such as “loop through the loop and and slice the new thing out or sth.” Those comments are generally cleaned up or deleted after I know that my solution works, but I’ve never quite known if I should leave my comments in my code, or whether it tends to clutter up the codebase. I ended up leaving them in, corrected with proper grammar, hoping that it would make it easier to reference for the interviewer.
As I had not yet completed a formal computer science education, aspects such as the complexity of my code did not come to mind, but if I had known, my experience may have been different. I had mainly taught myself through pursuing a challenge where I coded every day for a year, which meant that most of my experience came from a project-based background. Despite my inadequacies, I passed the first round, which I was ecstatic about.
At this point, my nervousness really began to kick in. I had heard stories about blanking out on the spot in the middle of an interview, and also had memories of not being able to answer questions in the past. The word “technical interview” sent shivers down my spine, and I scrambled to get ready. As if my own nerves weren’t enough to deter me, I was looking to attend another hackathon in the coming weekend, which meant I had roughly a day to prepare.
Preparing for the Interview
My one day, self-moderated crash course involved learning and reviewing concepts that were frequently covered on other interviews.
Concepts
- Big-O notation
- Relearning data structures and their applications
- Practice problems on HackerRank and LeetCode
Resources
The second stage was a video interview over Karat, Intuit’s hiring partner. My interviewer was very friendly, first asking typical questions such as my education level and asking to describe some aspects of my first stage answer (complexity, logic choices). We then moved onto a relatively easy question, but as I was given the problem, my worst fears came true: I blanked out. As I began to throw out random possible solutions, the interviewer gently kept dropping hints, ultimately causing me to panic further and apologize profusely at every mistake that I made. I knew immediately after the interview that there was no way that I could make it to the next round, yet I felt a mixture of relief and sadness that it was over.
Took a L on the interview, but a W on the scenery.
The next day, on the bus to the hackathon, I received the notification that I was not selected to continue onto the next round.
Taking a Step Back
Promptly after receiving my decision, I went through a period of reflection, analyzing what I did wrong. While it is true that my technical skill may not have been up to par, I felt that there was simultaneously psychological weight that may have contributed negatively to both my performance and decision making.
- Relax. I had nerves of rubber both rounds while interviewing, even though there was nobody judging me during the initial coding challenge. Both problems ended up being a relatively easy, but due to my own nerves, I was unable to think properly and did not end up performing to the best of my abilities. Think at your own speed, and don’t feel pressured by the presence of another person next to you.
- Be confident. Imposter syndrome is frequently accredited as an extremely prevalent source of uncertainty, and in this case, it was true for me. As I was only a high school senior interviewing for a position that both graduate and undergraduate college students were vying for, it was constantly on my mind that I would not be able to match the knowledge of those several years my senior. Despite the knowledge gap, I still think that if I had confidence in my own abilities, I may have been able to more accurately showcase my abilities.
- Don’t worry about the outcome. Both you and the interviewer are there to evaluate each other. As an interviewee, I knew that I was competing with a direct peer as well as several other college students. If I had not spent my time worrying about the outcome, I might have been able to focus more and learn more in the short period of time I was given. The purpose of taking the interview is not to impress your friends, nor to act as a status symbol, but to find a company that you’ll be comfortable at.
- Treat your interviewer like a friend. At least, in the moment. By no means do I claim to know how interviewers think, but the way I want to think about it is that the interviewers aren’t there to fail you, but simply to figure out if you would be a good fit for their company in both skillset and culture. At the same time, you should be figuring out if you would enjoy working at their company, evaluating them like a friend. After all, it is an opportunity for you to interact with a current employee, and if you are not chosen, you need only to improve yourself and move on.
My experiences have lead me to turn a new perspective on the interviewing process, which I believe will improve my performance in the future.
Pay special attention to your perspective of the interview.
I took the interview while fully thinking that the objective was to pick out any flaws in my thinking, but I think it would have been a better approach to think about it as just a small puzzle or logic challenge. The psychological effect on my mind was enough to induce nervousness, and if I had approached the whole process in a different way, it may have contributed positively.
As a result of accepting this challenge, I went through a rollercoaster of emotions while going through this process. Taking on your fears head on is never easy, and although I didn’t make it, I’m glad that I took the chance to overcome my fears of interviewing. It had seemed nerve wracking before going into it, but as I reflect on how I could have done better, I’m enthusiastic about using what I’ve learned to go through the process again.
Maybe you’ll take some of my experiences to mind, but I am also at a point far behind many others. Whilst most of my rambling in this moment may be highly specific to my own experiences and mentality, I hope it may provide some insight and preparation for your next interview.