Edwin Lim is the product of being in the right places at the craziest times. He began coding at the Obama 2012 Campaign doing data analytics and has since been a software engineer in NYC while trying to write and read more often.
by Edwin Lim
Most tech interviews are a mix of mainly two objectives: sanity checks on your technical skills and an assessment about your “fit” in the company. The former is likely to be straightforward. The latter is a judgement call that can multiply your worth, even override technical shortcomings, or sink the opportunity altogether. How to present yourself as a good "fit" is a vague undertaking because interviews are inherently a people driven process that applies communication, intuition, and judgement as their primary tools.
I find the most avoidable yet very common mistake candidates make is giving disconcerting or lackluster answers about what they'd be like to work with. So, I have one essential recommendation for those interviewing:
Don’t let the interviewer guess, interpret, or speculate on your behalf.
Your priority is to provide an answer that is true to you and your ambitions which can be clearly communicated. An interviewer will eventually need to make a case, verbal or written, on your behalf to their co-workers and bosses. In other words, your interviewer will re-summarize and re-tell the responses you gave to other people.
The goal is to then make the interviewer understand the story of your strengths, experience, and potential well enough to tell it themselves. Only then can they convince others in the company that you are the right hire.
Interviews magnify the qualitative far more than the quantitative. A few confusing answers can undo a lot of good in ways you don't expect, mainly because, if the interviewer is confused about you then the company will be too. Like I said, it's a people driven process. And you want the people on your side, beginning with the person sitting across from you.
The story of three candidates
To give examples, here are three candidates I've interviewed before: “A”, “B”, and “C”. All were qualified in terms of technical skill, but each had moments that lessened the clarity of what kind of colleague they'd be and therefore my confidence to endorse them as a great "fit" for the job.
Stick to what you really love
“A” had told me they loved a legitimate backend solution to a problem I had given them. Since they were interviewing for a frontend job, I quickly asked "A" why.
“Because it’s the proper way to do it” was the paraphrased response. When I explained the frontend alternative, “A” responded, “You’re right. That’s the better way. I love that more.” I then asked why they suddenly loved my answer more. “A” repeated the same reasons I had just said.
I immediately became concerned that "A" was telling me anything I wanted to hear. If they had stuck to their initial backend solution, I would’ve moved on to the next question without unnecessary doubts about a simple disagreement of methods. Unfortunately their overuse of the word "love" made their change-of-heart even less believable. I was frankly confused, but more crucially I was wary about how to conduct the rest of the interview questions to avoid parroting. I wanted to know what "A" really thought about and how.
Most tech jobs require clear communication and thus clear disagreements to reach a solution amongst many engineers, backend and frontend. Just be ready to support your ideas with well thought out arguments. And amongst all the candidates I thought could have a constructive disagreement on the job, I wasn’t so sure about “A.” Stick to your strengths, let them be known, and don’t compromise them.
Make it just about you
I believe “B”'s skill is a product of both their passion for programming and the range of jobs "B" has had over the past four years. However, “B” went on a series of unprovoked long anecdotes about former bad bosses, their disagreements, and why “B” moved on to better things each and every time.
“B” brought up an anecdote about a bad boss, not ideal, but not uncommon. By the time they moved on to their 4th bad boss anecdote, I concluded that the only common denominator in these bad work situations was “B" themselves. Now that was an assumption I made, but one I made with the context and details given to me by their stories.
Ideally, you make everyone you work with better. In reality, some people don't work well together which can lessen productivity and morale. Engineering is almost never done in vacuum, it’s done in teams. So if you must mention others, remember this whole thing is designed to discover how you might act on the job.
You'll likely get a question such as “How did you overcome a disagreement with a co-worker?” Don’t describe the other person with any judgement. Only describe the basic premise and actions: “they wanted x solution and I wanted y solution” or “they witheld x information from me.” 95% of the anecdote should be about the actions you took and the ones you wish you’d taken, a story about your growth and willingness to learn.
Try not to scare interviewers with horror stories about horrible people. Imaginations can run wild. They should stay focused on you, the main character, as a teammate they can depend on even when things get difficult.
Those three small words
“C” frequently used "I don’t know" as a conversational dead-end instead of demonstrating their problem solving skills.
“I don’t know” are some of the most important words in the interview. If you don’t know something -- say so; otherwise, me finding out later can lead to some awkward exchanges. What you say next however is what I'll be paying very close attention to: how you communicate and problem solve when dealing with the unknown.
You don't need to know the answer to every question, but you do need to demonstrate the ability to find a potential answer if you don't. Be emboldened to talk about things other than the answer to help you clear the hurdle you’re stuck on. Walk me through what you can eliminate. Shrink the the circle of possibilities. Ask me questions because I would be a very real resource on the job.
Engineers must deal with what they don’t know to some capacity every single day of their careers. They transform a lot of that into clear communication and then into working code. Without an honest attempt to figure it out, the interviewer has no insight into how your skills will translate into a job with unsolved problems and new technologies. It may be a lot of pressure to perform, but candidates like "C" can be seen as gambles because of their reluctance to put themselves out there.
I preferred many candidates who explained their ideas or asked poignant questions when they didn’t know something over those who simpy knew the answer. Because of their vocalizing, I was more confident in their ability to communicate, be resourceful, and collaborate: I could see myself working with them already. Treat it like any other part of an interview. Prepare for it and get ready to talk after you say the words “I don’t know.”
A company that can genuinely understand you can enable you to do great things in your career. Do your best to give answers that are cogent and earnest to you -- no matter the question. That candidness and clarity will enable me to make a strong case to the company, to paint a good enough picture of you to make it obvious: we're a great "fit" for each other.