The Dreaded Technical Interview; Observations from A First-Timer
Ahhh, so here you are. Chances are you’ve decided to pursue a career in tech. Welcome! You’ve put in the work: coded for countless hours, debugged your life away, stared at error messages until your eyes glazed over (plot twist! All you needed to do was wrap your code in a fragment), annnnd the time has come! You’re ready(ish) for that technical interview! They say “The oldest and strongest emotion of mankind is fear, and the oldest and strongest kind of fear is fear of the unknown” — okay, okay, it was H.P. Lovecraft, but the dude knows what he’s talking about when it comes to fear (and scaring people).
I had my first technical interview last week, the very thought of which filled me with trepidation. I had no idea what to expect, really, so naturally I did what any reasonable person would do and avoided thinking about it until 5am the morning of. Things turned out okay in my case, but do not be like me. Do not do this!
Do: pair with friends regularly. This helps keep you on track if you get anxious and avoid things like me. I knew my interview would be in vanilla JavaScript and suspected this meant algorithms, so I worked through an algorithm course on Udemy and pair programmed with a friend throughout the week. This came in clutch since coding with my friend enabled me to practice talking through my problem-solving process in a low-pressure, low-stakes environment. We were practicing on LeetCode but I’ve since discovered binarysearch, which allows you to create a room so you and your friends can work on the same problem individually. There’s also a nifty timer based on the difficulty of the problem, but I digress.
But alas! Turns out there’s a separate hurdle in the technical interview no one ever tells you about: technical terminology. My interview started off nice and easy; my interviewer asked me to explain this statement: 2 == ‘2’. I was elated! The loose equality operator? Cake. Of course I could talk him through it! And so I did…except it wasn’t what he was looking for. Yes, I’d correctly identified and explained what would happen but failed to mention the technical term for it, type coercion, the key term he was looking for.
Needless to say, that term will be seared into my memory for the rest of my days. All that to say: be sure to brush up on your technical terminology! Do: read up on the language or topic you will be interviewed on. You will be tested on and expected to be able to articulate these processes clearly and succinctly! I used the Front End Interview Handbook to study (5am, holla!), but overlooked simpler concepts. So I reiterate, do not be like me! I’m making these mistakes so you don’t have to!
My interviewer proceeded to ask me a few more questions relating to technical terms, increasing the difficulty with each question. After he finished quizzing me on terminology, we began to code. I happened to get a question I’d seen before: Palindrome. The good thing is it wasn’t completely foreign to me, which gave me a boost of confidence, the bad news is I hadn’t seen it since January, almost a year ago, soooo yeah.
Before I began to problem solve, I repeated the question back to my interviewer to ensure I clearly understood what was being asked of me. Once he confirmed, I began to think aloud as I worked through how I thought I’d solve it. I pseudocoded out loud before beginning to type my code, and proceeded to solve the problem. While I did get stuck at certain points, I made sure to continually run my code and console.log( ) superfluously to ensure my code was running the way I wanted it to. My interviewer was very helpful when I got stuck and offered tips that helped veer me back onto the correct path, but I understand this is not always the case. Ultimately, I worked through the problem and was able to move onto a second one.
After working through the first problem, my interviewer gave me the choice of working through a problem of equal difficulty or a more challenging one. I suspected it was a trick question so naturally I asked to up the difficulty. I wanted to demonstrate I am ambitious and willing to try things even if they are beyond my current understanding. I’m grateful I did! We wound up running out of time but I was able to clearly talk him through my thought process before he showed me the answer. To my utter surprise, I was about 80% there with my pseudocode! Would I have solved it correctly had we not been cut off? No. But I would have been damn close!
Do: challenge yourself, you know more than you give yourself credit for!
Anywho, the dread I’d felt leading up to my technical turned out to be all for naught. I had severely underestimated myself, my technical skills, and my ability to remain calm and focused under pressure. So don’t be like me. Do: prepare to the best of your ability, trust yourself and your skill. Keep in mind that while this may be your first technical, it won’t be the last and even if you bomb, it’s a great starting point to pinpoint what needs to be improved upon! I constantly remind myself that being at the bottom is great! You have nowhere to go but up, nothing to do but learn! And if you’re reading this before your first technical — do some deep breathing and remember you’ll make it out alive!
