Non-Technical Advice in Nailing Tech Interview
June 20, 2022
In recent months I have talked to and helped quite a few colleagues of mine about their tech interviews. What I found interesting is how starkly different the result could be for people with similar skill sets, one could get an offer with major benefits while others might just get a bare one, or even none at all.
After gathering information from their interview process, reading some blogs, and introspecting my own experience. I've discovered that non-technical aspects in interview have significant impact to the outcome. Some are clear enough, while others are very subtle that many of us often don't realize.
Why is this seems so important? While it's not easy to pass the technical test and prove we are qualified, it has become a basic standard nowadays, There are so many tech interview books and web courses that it has become an industry on its own.
So how do recruiters pick their choice given hundreds of qualified candidates, and how can we improve the odds? I believe this post might provide some answers.
Overlooked Interview Skill
Interview skill is often overlooked, but not without any reason, it's a one-off skill. We get the job, we drop it, until we have the need to look for another opportunity in the future.
I also observed that we software engineers tend to focus primarily on the technical side of the interview, grinding leetcode, binge-reading system design theories, and rehearsing programming theories. Communication, behavioral, and other skill that are considered non-technical also plays a big role in getting an offer, skill that we often neglect.
What would we do when we're stuck in a coding problem? Or don't know the answers to the question interviewer asked. Do we just submit defeat and go home? How would we propose a solution that's not perfect but compromising enough that both sides could agree on? What if we want to highlight skills or experiences that could be beneficial and put us at the top of other candidates?
Proficiency in technical skills will tick all the requirement checkboxes, having a good sense of non-technical ones could help us turn the tide in all these scenarios.
Handling Scenarios in Interview
An interview is not the same as an exam, where we could just provide answers to every question and get a score at the end of it, hoping it passes the minimum threshold. There are other things recruiters also looking for, qualitative characteristics that might be subtly shown during the process, such as compatibility -whether we would fit well with their team-, our ability to communicate and deliver ideas, and how we handle varying events at work.
By default, every recruiter hopes us to succeed. After all, they have a need to fill in their team. The fact that we're invited to the interview means they see prospects in us. However, circumstances always happen during interviews, how we handled them decides whether we go through or not. These are a few tips that I found useful and quite effective.
Elaborate and Collaborate
In tech interview, there would be usually rounds of coding tests, system design, and pair programming (this one's rare though). In my early days, I would just go straight to solve given problems, no question asked, what happens when I could not solve them? I panicked and froze, failed on the spot. Down the road, I learned that I should always try to communicate our idea through during these rounds.
During coding test, try to re-state given problem your way, and ask what the resulting program should return, is there any input limitation? any 'hacks' that are permissible? These will make sure you fully understand the problem and gives the impression that you know what you should do next. When implementing the solution, keep communicating what you're trying to do and why it's (hopefully) gonna work. Even when it doesn't work, try to communicate it, why it failed and what are you missing. More so, don't hesitate to ask for opinions, oftentimes they will be happy to guide you through.
This also applies to system design round, try to clarify the requirements, and what features they expect? How's the load expectation, i.e in RPS (request per second) terms? Can you set some limitation, and provides a reason for them? After implementing the solution, you might be going back and forth discussing some concerns or issues that might arise. Listen to it and don't hesitate to mention if you miss some things, or provide reasoning if you intentionally do it that way.
Once a time, I got stuck with a considerably trivial coding test problem when interviewing at Tokopedia, I talked to the interviewer about where I got stuck, what I've been trying to do, and asked what do they think, to my surprise, they were willing to guide me and provided some hints, which helped me pass. Were I chose to freeze and submitted defeat, I would not be making it to the next round, let alone getting an offer to work there. Day and night difference.
Be Honest and Open to Mistakes
It's granted that we will not be able to know and cover everything to be 100% ready. Consuming the entirety of coding test book just for an hour of interview doesn't make sense to me either. What we could do instead is to be open to the unexpected things that may happen.
When the interviewer asked for things you don't really know, or have no experience with what they needed, be honest about it.
To make things better, open a discussion with them. Example of mine, I didn't know and never use Redis when asked in an interview.
Rather than ending it at No, I don't know, I asked them what it is and what's the usage of it,
it turns out to be similar to hashmap or dictionary in a way, things I learned in college. So I bring out what I know about hashmap and proposed my guess about Redis.
What could be a major loss turned into a fruitful discussion.
The same applies when it comes to mistakes, be open about them, explain why you could miss them, and ask for feedback. With the right intention, these will show that you have curiosity to learn, openness to new perspectives, and transparency to mistake. Traits which I have seen in great engineers I have worked with.
On other note, this could also help you to dodge a bullet if they treat you negatively for showing these traits, you wouldn't want to work in a team where you could not be open and honest, would you?
(Try to) Take it Easy
As much as we prepare for it, nervousness and anxiety always kick their way in, and it's normal, there's an infinite way things could go, and sometimes we can't fathom it.
So try to take it easy. I know it's far easier said than done, but it's psychological things where we need to pretend first, fake it till you make it is what they say.
What I would usually do is by thinking inversely. I know chances are I'm going to fail, so I will make it worthwhile instead and try out a few things. Now, instead of focusing on not messing things up and failing, I try to gather as much experience as I could, trying new things (some tips stated here are actually from me YOLO-ing at interview, some fails, but some works wonder). As a side effect, I also feel more confident, leading to fewer mistakes and a more convincing impression, which paradoxically improves my chances.
In the end, we only need one offer to succeed.
Be The Supply to Recruiter Demands
It's a simple economic term, Supply and Demand. The recruiter has a demand to hire, we have a chance to supply it. What's not simple though is how to know what their demand truly is, and how we can show that we could supply it.
Requirements in job description oftentimes only cover general ones (what I call explicit demands).
Fulfilling these will answer the Is this person good enough? part. But how would we answer the Do I want this person in my team? part?
As it turns out, there are things recruiters and interviewers subtly looking for, I call these implicit demands,
these are not easily stated as they are not easily quantifiable either. So we have to actively engage to find it out.
Interrogate your Prospective Team
Is there any question you would like to ask us? is one, if not the most underutilized part of the interview, especially by junior and alike.
This section of the interview (usually at the end of each round) allows us to gather information and get to know the prospective team.
It's even suggested to have a reverse-interview session after an offer is at hand.
Getting to know your future prospective team will give you insightful information that might be used as leverage. How do they work, What kind of engineers they're looking for, are they building something that requires some expertise, or are they currently struggling on something. Knowing these kinds of information could tell you 1) Whether you will have a good time working there 2) You have some skill or experience that might be useful to them.
So how should you approach it? I have a few opener questions that I usually use:
- If I am to join your team, what are your expectations of me?
- What service your team is currently handling/building? What are the tech stacks?
- What's the day-to-day activities working there look like?
These questions would usually lead to a flow of discussion, try to follow up on each answer given. Perhaps they are building a microservice for disbursement, you can ask what the flow of transaction look like, or tell your relevant experience if you have one. Maybe they expect some level of ownership for you as a junior/senior, you can follow up by asking about their team structure, and how the ladder of responsibility works. This is an effective way to know what their implicit demands are.
Incite Demands and Propose Solutions
From what we do above, it's very likely to discover a thing or two about our prospective team that matches our skills or experiences. From there, we could tell our experiences or propose a solution to them. Chances are it will be well-received, they might even ask for further elaboration. What's beneficial is that now we're seen as more than just qualified, but also wanted in a specific way. This is a good thing, and it could make a significant difference.
A good friend of mine who is a front-end engineer recently went through an interview. During a late stage with a hiring manager, he asked what it would be like to work there, and what are they planning to do. Then he got information that his prospective team is currently experimenting with a few things on React. He found many relatable things to what he had done, so he moved forward and told his experiences, from revamping React web designs to building custom components. The hiring manager was intrigued to hear it, and they brought the discussion further. The end result? A top-of-the-line offer and both party is looking forward to working together. Had he not tried to explore deeper about his prospective team, he's maybe just seen as a regular frontend engineer.
From that experience, I learned that a good candidate is also a good salesman, who's able to effectively sell their service. After all, we are trading our s̶o̶u̶l̶ ̶a̶n̶d̶ ̶s̶a̶n̶i̶t̶y̶ skills and experiences for wages.
Ask for Feedback
So, you are at the end of the line. Everything's nearly wrapped, but you're feeling unsure about how things went by. Are they satisfied? It is very recommended to ask for feedback at the end of every interview.
For one, it could be useful to help you improve your interview skill, maybe you are not clear enough when delivering ideas, or you should be more considerate in identifying corner cases, or maybe you are just too stiff during the interview (all happened to me). These feedbacks are likely to be missed if you don't actively seek it. It's always a good thing to ask for this, sometimes they don't even hesitate to go back again and explain which part you missed and could be improved.
Asking for feedback is also a good way to clear things up. Maybe they are doubtful about your way of thinking,
or they feel your knowledge in algorithm is a bit off and thought that maybe you're bluffing your way in (and it might be true, Impostor Syndrome™ kicking in full gear).
It may seem unimportant, but it could make them feel unsure and hesitant to extend you an offer,
There's no better way to solve this than asking it directly,simply ask Do you have any concerns or issues about me during the interview that I could help clear out? and clear everything out before you exit the door.
Healthy Cautionary
Quick reality check here. Will this all work? Not exactly, no guarantee in every case. Not all companies behave the same, some have a very strict hiring process where if you miss or fail at something, it's game over. Also, some things stated here are also situational, sometimes they are happy for you to engage that way, and sometimes they just want you to answer and get it over with. Be mindful of how things are going on.
Getting better is more important than nailing it in one shot. And the only way to do it is more interview experience. You will sense your own mistake and what area need improvement, confidence will also rise up as you get used to it. Muscle memory will be built.
Another thing worth mentioning is that there are a lot of things that are just out of your control. You can simply get rejected for things you cannot work out. For example, maybe they are not looking for seniors -usually for budget reasons-, or they are currently hiring seniors only. I have witnessed both situations. These kinds of things are simply out of your reach, so if it happens, try to not take it personally, and move on.
And that should conclude this article. If you have any feedback or want to connect, feel free to reach me at LinkedIn. Thanks for reading.