The Technical Interview: Learning How To Be Uncomfortable
This summer, I returned to the Trinity Alps of Northern California to enjoy the sweet and simple life of backpacking. I enjoy backpacking for the cool mountain lakes, sleeping under the stars, and the sense of independence, but it was not always an activity I was so fond of. I started at a young age, and like most kids, I used to complain about my feet, squirm under the uncomfortable weight on my shoulders, and repeatedly ask ‘how much farther’. In truth, the discomfort never really goes away.
In fact, I was once told, backpacking is less about becoming a skilled long-distance hiker and more about learning how to be uncomfortable. I recalled this thought on the first day of the trip, and again, when recently applying to my first software development job.
Not knowing what to expect exactly, the application process seemed much like those first backpacking adventures. It was longer than I wanted it to be, had its ups and downs, and at times, it weighed on me. Over one and a half months, I met with a variety of team members, completed homework assignments, solved problems in front of informal panels of engineers, and learned my second programming language. Each stage presented new challenges, which I overcame with determination and preparation. The uncomfortable part? Learning to externally process my thoughts.
I am definitely more of an introvert than an extrovert. In the most basic sense, I regain my energy from taking personal time (as opposed to being social). More specifically, I prefer to think through my thoughts, weigh them carefully, and share them once I have come to a conclusion that feels accurate. In short, external processing is not part of my nature.
There are many articles describing how extroverted and introverted people process information differently. I am in no position to say which differences are more or less true, but I can tell you what I have personally experienced. For any one situation, my brain quickly bounces between and evaluates a variety of relevant factors: environmental, social, future, past, task-oriented, etc. It is disquieting to think about verbalizing each one, nor would that be productive. Furthermore, it is one thing to explain how to do something when you know exactly what to do every step of the way, but what do you do when that is not the case?
Talking through a problem presented a challenge for me in the interview setting, but I recognized it as an essential part of the process. While you code, the interviewer is looking to learn how you think and see that you are flexible, relatable, and if you are early in your career, that you are coachable. Additionally, as much as the interviewer hoped to find a good fit with me as a candidate, I hoped to find a good fit with the position. In order to truly explore this possibility, I needed to expose the essential qualities a developer must possess from the very beginning. For these reasons, it was important to be transparent and master the skill of external processing. So what did I do? I took a step back, reevaluated my assumptions, and worked with my discomfort.
There are many ways of saying you are unsure how to proceed with solving a technical interview problem without giving in to total defeat.
Assumption #1: I assumed I needed to have all the answers. A candidate is capable not because she knows the answer, but because she is capable of solving the problem. Fundamentally, problem solving includes not knowing the answer, maintaining a cool state of mind, exploring options, using knowledge, and asking good questions until you find the solution.
Assumption #2: I expected to have a polished solution. The code you come up with in an interview is not going to be production level code or even written with perfect syntax. I did not finish the problems in the time given, at least, not to the standards I would have been happy with. For me, the interview was successful if I could find traction in the problem space, take a suggestion and act on it, and communicate if I was stuck. I discovered there are many ways of saying you are unsure how to proceed with solving a technical interview problem without giving in to total defeat. For example, you could do any one of the following:
- Review what you know about the problem.
- State what you think you have learned from trying one solution.
- Talk about the options you are considering and the pros and cons of each.
- Hardcode part of the solution and explain what other part of the problem this allows you to focus on.
For most people, the interview process is uncomfortable in general. I cannot emphasize enough the benefit of taking time to adjust your mindset, diversify your preparations, and reach out for support. Like any problem a developer faces, it helped to break the larger task into smaller ones. I thought of each stage of the application process as a doorway and aimed to only walk through whichever one was next. Additionally, I was intentional about what I would learn and review before going into each interview.
I balanced my time between watching tutorials, practicing challenge problems, and quizzing myself on concepts, but also writing out answers to potential soft skills questions, researching the company, brainstorming my own questions, selecting personal accomplishments to highlight, and re-reading my application and cover letter. Lastly, I asked for and received invaluable support from my partner, mentor, and family. These preparations allowed me to take care of my needs throughout the application process and ultimately enter each interview with confidence.
External processing may never come naturally nor be a part of my comfort zone, but just like backpacking, I learned to expect the pain points and find ways to lessen their impact. Only in this way was I able to fully benefit from the technical interview experience and explore the job opportunity.
I hope you get the job you are applying for, but even if you do not, I hope you grow and learn something for the next one. Good luck!
