How to Prevent Crying During Your Technical Interview
Join the DZone community and get the full member experience.Join For Free
A recent blog post Technical Interviews Make Me Cry by Pamela Fox tells the personal tale of a technologist and conference speaker who gets a Skype/Stypi interview for her dream job, becomes stumped on a technical question, breaks down in tears, almost abandons the interview, fights through it, and eventually gets the job. Everyone loves a happy ending, and it was courageous for the author to tell her story so publicly as a service to others. However, I think some of her takeaways and the advice she provides can be improved upon.
So, how can we prevent crying or freezing up during a technical interview?
Let’s start with the author’s advice. She offers that interviewees should prepare for the format and not just the material, and writes
“If I had made myself go through the uncommon and uncomfortable situation of being put in [sic] the spot and asked to answer a random technical question, maybe I would not have cracked so easily when it came to the real deal.”
Haven’t we been preparing for a question and answer format, in one way or another, for almost our entire lives? I can understand being a bit uncomfortable with Skype and an online collaboration tool, or some level of adjustment to having someone watch you code during a live exercise, but being asked random technical questions is not all that different from taking exams in school (other than the potential for real-time feedback). You have a math test, you study math, and you are asked math questions on that test – some you may have anticipated, some you may not. (More about how school messed us all up later.) Going into an interview, one should expect to be asked some technical questions, some random and some that you see coming.
Pamela’s second takeaway
“If you’re an interviewer: seriously consider the format of the on-the-spot technical interview and whether that’s the best way to judge all candidates.”
This is a good point and certainly fodder for the continuing saga and ongoing debate regarding the best ways to evaluate technical talent, but this isn’t actionable advice for anyone that has an interview scheduled for this afternoon. Take-home assignments and collaborative exercises are becoming more common as part of the process, but we are not all there yet.
In the middle of the article, she gives us this additional lesson.
“It was then that I realized the most important part of prepping for the phone screens: confidence.”
Confidence is important, but I don’t see how confidence would have necessarily helped her situation. If she were more confident, would she have immediately come up with an answer and not frozen up? Perhaps? This might be more a function of the impostor syndrome that she mentions, and not applicable to most of the world.
Here Are My Takeaways
First, if you want to get good at something, you have to practice. Pamela wrote
“… technical interviews. I’ve been lucky to have very few in my life …”
Herein lies the first problem. One should not be surprised when failing at something they’ve only done a few times before. Interviews are high-stakes situations, and being a skilled interviewee requires practice. We can debate whether taking an interview when you are not on an active job search is a noble pursuit, but if you have gone several years without interviewing I assure you that today’s technical interview may be unrecognizable. If you don’t care to interview when you have no intent of taking a job, perhaps sit in on an interview at your company. The observation gives you risk-free access to the process, and you can see how others handle situations that are potentially stressful.
** First takeaway: Interview, whether giving or receiving, more often than you job search.
The author wrote about her preparation process.
“I wasn’t sure how to prepare for it, what sort of questions I’d be asked. I figured I’m known for more front-end work these days and folks may be under the misguided illusion that I’m a JS expert, so I read through parts of the ECMAscript spec, reviewed the craziness of prototypical inheritance in JS, and read through all the front-end posts on that engineer’s blog. Part of me thought I should study more, study enough that I’d feel confident that I could handle *anything* they threw of me, but that would have taken me months, if that. More likely, I’d never feel 100 percent confident.”
This is how most tech pros prepare for interviews, which is why books that list answers to commonly asked questions sell bundles. She read through tons of technical information that she anticipated would be covered during her screen, and even felt she should keep studying so she’d be more confident. But what didn’t she prepare for?
It seems as though the author didn’t prepare for the high probability that she would be asked a question that she couldn’t answer right away. She never prepared to fail, and because of that oversight she froze, panicked, and began to cry. Had she anticipated that being stumped was a likely scenario, and had she known that there are many technical interviewers who will continue to ask questions until you get one wrong, she would have been much more comfortable when it happened.
This is why schools have fire drills.
**Second takeaway: Realize that you will not be able to answer every question, and prepare an answer for when you get stumped.
Shortly after the phone interview debacle, the author had some pretty low points.
“And then the sobbing REALLY began. I had just finished the first step of the interview process with the company I desperately wanted to work for, and I’d bombed it. I’d frozen, I’d cried, I’d stumbled through my somewhat shoddy solution. Did I really deserve to even be an engineer, if I couldn’t even make it through a phone screen? What gives me the rights to give talks at conferences, if I can’t make it through standard interview processes? I was pretty damn frustrated with myself.”
All of these thoughts and feelings that led to questions about even being fit for the industry, which were the result of what would subsequently be deemed a successful phone interview. How did she get there?
Remember earlier when I mentioned school? Suppose I were to give you a test, and I provide the results in real-time with a "right" or "wrong" signal after every response. Ten questions into the test, you manage to get half correct. How are you feeling right now about your test performance?
We’ve been programmed since an early age to think of success based on certain scales, and most of us use common academic grading standards to judge test performance. This false expectation leaks into interviews, where an interviewee may feel that 5/10 is failure without having any concept of how others have fared. Answers to technical interview questions are often not judged as simply right or wrong, and some credit is usually applied to approach and process. Sometimes interviewers don’t expect you to know most answers.
**Third takeaway: Manage your expectations properly, and accept that an interviewer’s definition of success may be vastly different than traditional academic standards.
The defining moment for our author was a fateful decision to abandon ship or press on.
“The only thing going through my mind was "I can’t do this." I stared at the "hang up" button on Skype. I could just press it, and he would go away, and then I’d give up on my obsession, and I would convince myself it was a stupid idea in the first place.”
Of course, we all know that she kept going with the encouragement of the interviewer and eventually got the job. It’s reasonable to think that the interviewer didn’t expect candidates to cry, but it’s not unreasonable to think that the interviewer felt the exercise would be difficult for Pamela and most similarly qualified professionals. How a candidate reacts to stress, surprise, and failure are all potential markers for success in the job. If I were hiring a pilot, I’d ideally like to put him or her in a flight simulator and observe a crash landing or engine failure scenario.
Luckily, the interviewer was understanding and the author worked through the discomfort to come up with a satisfactory solution. Pressing "hang up" would have served no positive for either side in this case.
**Fourth takeaway: Don’t give up just because you think you are failing. There is nothing to gain by quitting, and you may learn some things about the process and about yourself by sticking it out.
Change your mindset on interviews and keep the tissues in your pocket.
Published at DZone with permission of Dave Fecak, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.
Integration Architecture Guiding Principles, A Reference
Security Challenges for Microservice Applications in Multi-Cloud Environments
Building and Deploying Microservices With Spring Boot and Docker
Hibernate Get vs. Load