Leetcode interviews for introverts

Cynthia Bord
https://img.particlenews.com/image.php?url=0Wecyy_0cocOBCA00
Pankaj Patel on Unsplash

I can’t tell you how many times I have messed up a live coding interview. I don’t blame this on the conflicting advice out there for technical interviews. It points to a company’s lack of knowing what they want out of a software engineer. Do companies want a great communicator or a talented developer? Rarely can one find both in the same person. Software engineers aren’t exactly the best people-persons. We solve programming problems and are often deeply introverted, with a low need for having to talk to another living being for days on end. Who can blame us? We talk through a computer program all day, after all.

When I started interviewing for software development positions, I made the mistake of thinking the main point of one is to assess one’s ability to solve logic problems, riddles, or grind leetcode to perfection. Whilst these roles often do require and test this in one way or more to determine technical fit, I also realized that technical interviews determine one’s ability to communicate technical ideas clearly at the same time.

The one where I talked too little

One of the first technical interviews I ever took part in was for a burgeoning e-commerce company. I went in with so much knowledge of data structures, algorithms, and how to implement an efficient solution. Ultimately, I solved the problems that the interviewer presented. But I still failed the interview. Why, you ask?

I hate to say it because it requires self-awareness, but it was because I didn’t talk at all during my solution implementation. I was focused, and caught up, on singly solving the problem. This, unfortunately, neglected the negative body language that my interviewer was giving off. One is supposed to communicate their logic in solving a development problem. If only it was communicated at the beginning of the technical portion because there were about 40 minutes of dead silence while I solved the development prompt.

I did see my interviewer begin to fidget in uncomfortable silence after 5 minutes, but I didn’t know what to do about it.

“I’m grinding out this leetcode. The solution is working. What do you want from me?,” I thought.

In my robotic approach to solving the problem, I forgot that there are people behind this company that I am interviewing with. They want to add someone to their team with who they can connect and work easily. I realized a little too late that it doesn’t hurt to show that you’re easy to talk to while displaying your ability to communicate your thoughts clearly while solving a problem.

The one where I talked too much

in my next live pair programming exercise, I was determined to talk. I was successful, but unfortunately, didn’t temper how much I talked. At work, I don’t talk unless I know for sure that what I am saying is correct. For reference, I used to work in investment banking and technology, so it was important for things to be right. Let’s just say that methodology completely went out the window in the pursuit of not looking like a completely antisocial freak in a technical interview again. The interview quickly divulged into overtalking, which often projects anxiety, nervousness, and uncertainty. The three things one does not want to communicate during a job interview. Now, instead of the strange geek who doesn’t talk to anyone besides her father, I had become the nervous wreck who said just about anything just to fill the silence.

It was not ideal, to say the least.

In this interview, I had no problem with dead air time. At all.

I talked so much that I even described my manual copying and pasting out of a cell and how it would not work because I deleted the information in the cell and data does not copy from an empty cell.

The interviewer probably thought I was too nervous to stop talking. Later, I learned, that a few seconds of silence after a question in an interview can project self-confidence, awareness, and thoughtfulness.

I did not project those things in this interview.

Was I talking for no reason except to talk? Yes. In my attempt to avoid a silent disaster, I engineered a complete trainwreck.

At one point, I talked so much in an attempt to hold my interviewer’s hand through my logic that I confused myself, losing valuable time to find a solution. I completely lost my train of thought on how to solve the problem at hand and could not finish the last question within the allotted timeframe.

After the interviewer cut the technical portion of the interview short, she asked if I had any questions about the company. In my flustered state, I remained stuck on the leetcode problem that I couldn’t finish and managed only to ask one question. The rejection email for this one was rather swift.

The one where I finally found my footing

After that experience, I tried to balance communicating and solving the technical assessment as much as I could. For me, this looked like solving the development problem as fast as possible without talking so that I can both solve the problem without distracting myself by talking and limit the silence as much as possible.

I found that this was the best approach to be able to show your technical acumen without losing my train of thought with talking, but quickly enough that as the interview proceeds that the interviewer forgets that there were 5 minutes of dead silence. This can be reconciled by strong communication after the technical assessment is completed.

At-home assessments

I’ve noticed that I always pass the at-home assignment round, but it’s a hit or miss with live coding. At-home assignments for some reason are less anxiety-causing, the applicant has time to think through their process outside of the expectation to understand and solve the problem while simultaneously talking through the problem on a call.

The at-home exercise most closely replicates the actual process of a software engineer.

You will always have time to understand the problem, write out your process, consult stack overflow forums, collaborate with your team, and consult the documentation.

Is it reasonable to expect a job candidate to perform well under unrealistic time pressure with great accuracy and a high level of communication? And do these expectations accurately reflect how well a candidate will do once hired? While technical acumen and communication are important, different applicants will have different methods of communicating in the same way that there are different ways to approach a technical problem. Most software developers are talented at programming and logic, but require time to feel comfortable communicating eloquently with someone they have just met.

Additionally, technical interviews are in no way reflective of a real work environment in which implementing a correct solution is more important than a communicative solution that doesn’t implement the technical solution as needed.

Comments / 0

Published by

writer on love, tech, and politics, lover of coffee and petter of dogs

New York, NY
99 followers

More from Cynthia Bord

Comments / 0