The Interviewing Map
How to survive and thrive at software interviews and landing your dream job
Big Tech interviewing
Getting an offer from Big Tech is an extremely challenging undertaking.
These are the largest tech companies, where the smartest engineers work, and their hiring is very conservative for a good reason. They only extend offers if they are confident the candidate is an absolute fit.
Interviewing for Big Tech is a lengthy process, involving several different interviews, that usually takes one or two months.
The reason behind those many interviews is simple:
To minimize false positives: Hiring the wrong candidate.
Even if that causes false negatives: Not hiring someone who would be a fit.
Hiring the wrong person is a waste of time and resources. Smaller companies are more willing to take bets on people due to supply and demand, as everybody wants to join BigTech.
Getting your foot in the door
Submitting your resume through a company’s application portal has little chance of success.
Don’t be disappointed if you never even receive an acknowledgment of your application. I strongly suggest you leverage your network at this point.
Ask people for referrals.
It will guarantee you the first interview. People will also be happy to refer you as they most surely get a big check for every person referred by them who gets hired.
Your brain will insist that if you don’t pass the interviews your referral will think you are stupid. Don’t listen to this message because it comes from the part of your brain that loves the status quo.
Preparing for coding interviews
By coding interview I mean typically a one-hour session with one or two interviewers where you will be given one or two coding challenges to solve.
Your mission is to design an efficient algorithm to showcase your problem-solving skills aside from your technical abilities. Not only do you have to think about the solution, but you also have to explain out loud what your thinking process is as you go.
What happens during that one-hour session is far away from what we do at our current jobs. It’s still programming, but everything else aside from that is just different.
It was hard to explain to my parents why I needed to prepare for months before interviewing for a job. Regardless of your experience, you still have to prepare if you want to have a decent chance.
Interviewing process is not broken
I get it. Interviewing is a completely different skill. Is it fair? Does it make sense? It’s the game we have to play. Sometimes I wonder if companies do these crazy interviewing processes just to see who has a will strong enough to endure all the preparation required.
That might be the real test, a test of character.
StackOverflow’s co-founder Joel Spolsky mentions the following idea about hiring programmers:
You’re looking for people who are smart and get things done.
– Joel Spolsky
The coding interview checks those boxes. That’s why your interviewer will most likely clarify at the beginning of the session that they want to see running code. No pseudo-code but actual code.
I also think that it’s an extremely efficient process and to illustrate that I will now compare it against the other most used or suggested alternative on the market.
Take-home assignments
Which other tools do companies have for evaluating a candidate’s skills? A take-home assignment sounds like a reasonable thing to do. You remove the stress and pressure for the candidate to think, code, and explain all at the same time.
Candidates fresh out of university do better in coding interviews compared to more mature senior engineers.
If you took your CS courses a few months ago, then it’s more likely for you to remember how to write an in-order transversal on a binary tree compared to someone who has been shipping production-quality software and providing operational support for the last five years.
Knowledge assessment is only one aspect of interviewing someone. Companies realize that asking a candidate to invest 8 to 10 hours of their time in solving a problem at home is a lot. Most people can’t afford to do that as they have other commitments: Their current job or a family.
Even if the company states that “it should only take around 3 hours” we all know that everybody is going to spend much more time than that. We all want to show what we are capable of, so putting some extra effort into it doesn’t sound like a crazy idea.
Production-quality code is documented code with full (or at least a decent) test coverage. No one wants to submit a crappy assignment as that would be the same as putting on your LinkedIn job title “Subpar engineer”.
This is also not the end of the story because then if the company was lucky enough to receive an assignment instead of being ghosted by the candidate, then and only then the company needs to find two reviewers (you don’t want to rely on the biases of only one person, do you?).
Reviewers also have to put a fair amount of work into this. They must review the code, reason about the logic (you would be surprised about what candidates might submit) and write comments about the things they don’t like as they have to provide feedback for the candidate.
Even if they are 100% sure it’s a no-go after reading the first five lines of code, they still have to provide feedback. It looks terrible if a candidate spent several hours working on your assignment and then you just email them a message saying only: REJECTED.
You want your candidates to think positively about your company even if they cannot meet the quality bar yet. They might apply again in the future or talk about their experience at your company with their colleagues. You want them to love your company.
Overall the process is much slower due to its async nature. The candidate needs to find a moment of their time where they can afford to spend some consecutive hours focusing on the task which will probably happen during the weekend. Then reviewers need to find a moment in their week to stop doing any other task and review the code (which might happen at different times for the different reviewers). Then they need to come together to agree on a yay/nay decision. And only then the recruiter can decide to move forward or not attaching the given feedback.
Compare this approach against a one-hour synchronous session between candidates and interviewers. Sessions were not only the candidate’s skills can be assessed (maybe suboptimally) but also their communication style and interpersonal skills.
Pros:
Better assessment of candidate skills on a scenario closer to the real work environment
Requires less preparation for the candidate
Suitable for good engineers who fail to perform in an unrealistic high-pressure situation
Cons:
Takes more time for the candidate to complete (without considering prep time)
Takes more time for the interviewers to review
Interviewers can only review real code properly in the technologies they are proficient at
Overall slower due to synchronization overhead
It’s impossible to assess soft-skills
It’s easier to cheat
Companies are not evil, they just care for efficiency. This is not a silver bullet and I’m not against assignments, but after doing this extensive comparison I find coding interviews as a reasonable trade-off to make.
Never let perfect be the enemy of good
I had promised myself multiple times that I would start preparing for the interviews right away but that never happened. The semaphores of life never get green all at the same time.
To begin with I started on the path of least resistance using the tools I was already comfortable with. I created a project inside my own IDE and used some random problems from the famous book Cracking the coding interview.
The downside of using my IDE is that modern IDEs are amazing pieces of software. Your IDE is so freaking good (which is great for your overall efficiency at normal circumstances) that makes practicing quite hard as it helps you a lot more than you know. You want to get back to basics.
After that, I had to start considering the time factor. I initially allocated for each problem as much time as I had or needed for figuring out an answer. This approach quickly confirmed Parkinson’s law:
Work expands so as to fill the time available for its completion.
– Parkinson’s law
Then I started using a stopwatch. However, you can always pause it to take breaks and resume afterward. Sometimes I even forgot that the thing was running at all. I was measuring how long it took me to solve a single problem where what you are actually after is how much progress you can achieve in a fixed amount of time. You want to set a time limit (like what happens during interviews) and then do as much as you can as fast you can inside that time frame.
The next difficulty were the problems I had chosen to practice against. Cracking the coding interview contains 189 programming questions which are not the easiest ones to start with. Frustration arose very quickly as I was trying to solve Hard problems from day one.
I was not enjoying the process and most importantly, I was not making progress at a good speed. It got me started which is crucial for accomplishing any goal. Now after one month it was time for taking it to the next level. Something had to change.