Disclaimer: anything you read in this blog post is my own opinion and doesn’t represent opinion of my current or past employers in any way.

For those of you who are looking for landing a Software Development Engineer job at a large tech company being able to crack the coding interview is essential.

You might be a reader from outside North America and are not really used to the kind of software interviews common here, but the harsh truth is that you have to grind college/university kind of coding problems before the interview.

Of course, the argument always goes that you should be a problem solver and that interviewer is accessing your approach to tackling a problem as well as your comprehension and communication skills. My counter argument is that preparation matters a big deal and even people with enormous experience and track record of deliveries would have difficulties if they haven’t brushed on algorithms in a long while.

Let’s do a thought experiment: let’s imagine there are two deep copies of you. By “deep copy” I mean that you both have absolutely identical personalities, knowledge, background, experience. Now you are both to be interviewed in one month at a big company. Copy One doesn’t have time to prepare and just looks up what are the main types of questions. Copy Two takes a month of vacation and sits at TopCoder / LeetCode / HackerRank / GeeksForGeeks solving, say 300-500 problems. Copy One is also capable of doing it as both of you did well in university XX years ago. Now when the interview comes, copy Two just shines and cracks all questions. Copy One struggles with solving problems but manages them somehow. Both do almost equally well on behavioral and design questions, though copy Two still has an edge as all of her/his stories are pre-prepared. So when the performance of these two copies is compared copy Two wins even it appeared both had similar cognitive and communication skills. What hiring company gets is almost identically same employee with a difference of 1 month of intensive practice, which has 0 effect on day-to-day job or quality of work.

Nevertheless there are some positive sides to these kind of interviews. One of them is that they are somewhat standardized and candidates are generally judged against the same bar. Another very obvious aspect is that these problems require writing code. If you go to an interview for a software engineer role and the main skill of your job isn’t accessed then there is something wrong with that interview. Here is the quote for this:

Talk is cheap. Show me the code.

Torvalds, Linus (2000-08-25)

My favorite types of questions for interviews are those (a) that could be solved in multiple different ways from least efficient to most efficient; even better are those (b) that start very simple but allow interviewer to make the problem ever more difficult, say by increasing the limits or converting input to a stream instead of an array, or by adding complication that requires alternative approach. Though an ideal problem, in my opinion, would be a problem that satisfies both conditions (a) and (b) and also is close to potential real-world task (c).

Problems at interview preparation websites, such as LeetCode, might satisfy the condition (a) from above, but rarely satisfy (b) or (c). I almost never see problems that would be (a), (b), and (c) – those would be fantastic.

Some example of a set of problems that satisfy (a) and (b) at LeetCode is classical easy problem “Best Time to Buy and Sell Stock” that can be solved with brute force O(N²) or more efficient O(N), but then there is a twist by adding transaction fee, when you would need to come up with a dynamic programming solution, there are many other twists. Here are variations: 1, 2, 3, 4, 5, 6. Some example of a problem that matches condition (c) would be implementation of an iterator interface, like “Flatten Nested List Iterator“.

Personally I’m not good at solving coding problems. I did participate in ACM competitions back in the university days, but I was always 3rd person on a team – kind of banging my head against the wall on a single problem while the other two guys were bashing the keyboard or coming up with magical math formulas.

I keep practicing on LeetCode mostly to keep myself in a good form. At the moment I have 407 out of 1285 problems solved. I bought myself premium subscription as it unlocks some problems and makes submission process faster. It also unlocks some of the mock interview functionality. Again I suck, but this kind of stats please my eyes (previously solved problems appear in mocks at times so I just know how to solve them).

Another fun activity you can do at LeetCode (without premium subscription) is to take part in Weekly Contests. Please let me know if you are competing as well and want to chat (my contacts are always easy to find andriybuday everywhere or leave a comment).

Recommendations?

This post wasn’t much about how to prepare to the interview nor an overview of coding practicing resources, though if you are interested, read about the interview process online, consider buying yourself the book “Cracking the Coding Interview” or other top resources. Remember that big companies often have the information on their process public, for example facebook on their interview process. Make sure you prepare for system design interview as well. But most importantly of all: practice, practice, practice!