Acing the Software Engineering Interview - Part I

Attention: This blog moved to my new Substack. Follow me there for updated content!

This is the first in a series of blog posts where I describe my interviewing experience and thoughts in detail.

My journey begins

For the last three months I’ve been preparing myself for software interviews while also interviewing (ain’t better preparation than real-world practice) hoping to find my dream job. Took me lots of hard work but I can gladly announce that I finally found it. It was an amazing experience that taught me a lot. I not only learned about programming but about enduring tough challenges and achieving what I considered almost impossible when I started. I picked up how to prepare myself for performing under pressure as athletes do. Become comfortable being uncomfortable.

I wanted to extensively describe my experience while my memories are still fresh and trustworthy. If this series of posts help at least one single person I will be more than satisfied with the outcome. If I was able to accomplish my goal of landing my dream job then anybody can, I have absolutely no doubts about that.

It takes courage to break the status quo and start an endeavor to advance your career. Especially if you are pretty comfortable at your current job as I was. It’s a hard decision that you can delay forever but not without consequences. You know that failing is not only a possibility but it’s likely to happen. The good thing is that you only have to succeed once during your job search to be successful. You can (and you should) fail as many times as you want until you find that one company that likes you and you like them.

I had a very clear view of what I wanted as a next step (or at least that’s what I thought at that time) for my career. I wanted to join Big Tech. I knew I had to prepare myself well If I wanted to have a real chance of getting a job at those companies. But how?

Every battle is won before it’s ever fought.

– Sun Tzu

Big Tech interviewing

The first step was to discover how my skills were going to be judged so I could best prepare for those tests. Getting an offer from Big Tech is an extremely challenging undertaking. These are the largest tech companies where the smartest engineers work. Best of the best. The problem for me is that Big Tech is quite conservative and for a good reason. Those gigantic companies only extend offers if they are pretty confident the candidate is an absolute fit.

Interviewing for Big Tech is a lengthy process that can easily take from one to two months. You must pass a large number of different interviews if you want to find the pot of gold at the end of the rainbow. The reason behind those many interviews is that companies strive for minimizing false positives (hiring the wrong person) at the expense of false negatives (not hiring the right person). It’s a waste of time and resources for them to hire the wrong person for the job. You can argue that this is the case for every single company but smaller companies are more willing to take bets on people.

Getting your foot in the door is much harder than you think. Submitting your resume through a company’s application portal has very little chance of success. Don’t be disappointed if you never even receive an acknowledgment on your application. I strongly suggest you leverage your network at this point. Getting a referral 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 remark that if you don’t pass the interviews your referral will think you are stupid. Don’t listen to this message. It’s the part of your brain that loves the status quo. Go to that friend and ask for that referral, it’s a win-win situation.

In this post, I will focus on how to prepare yourself for the 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 come up with an efficient algorithm to showcase your problem-solving skills aside from your technical abilities. Not only you have to think about the solution, but you also have to explain out loud what your thinking process is as you go.

For the ones who have never experienced such an interview, it’s worth mentioning that what happens during that one-hour session is unquestionably very far away from what we do at our current jobs. It’s still programming of course, but everything else aside from that is just different. I had a hard time explaining to my parents why I needed to prepare for months before interviewing for a job. Regardless of how much experience you have as a software engineer, you still have to go through a very thorough preparation process if you want to have a decent chance.

You can find more about Big Tech interviewing here 👇

Does this make any sense?

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.

Especially when asking him to solve a kind of problem which is miles away from anything they have done during their entire career. That’s one of the reasons why people 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 even afford to do that as they have other commitments such as their current job or even more important than that: Their own 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.

Now 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

See? 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. If you wait until you find the perfect setup then you are going to be waiting for a long time. The way I started preparing for my coding interview was suboptimal but I needed to stop procrastinating and start somehow.

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.

The story continues in the second part of this series of blog posts.