I’ve Failed Most Coding Interviews, and Still Agree with How They’re Set Up
Have you ever heard versions of the following statements?
- “Software Engineering interviews are broken”,
- “Why does it matter if I know how to implement a Binary Search Tree, everyone looks at StackOverflow on the job”,
- “Who cares about Big O notation, I can create a React.js app in my sleep”
- “Google: 90% of our engineers use the software you wrote (Homebrew), but you can’t invert a binary tree on a whiteboard so f*ck *ff.” (original tweet here).
If you haven’t heard these^, here’s how a lot of people feel about coding interviews:
Let’s get two things straight:
(1) I’m neither an expert, nor have I spent years researching the topic, or found peer-reviewed academic work on the matter, and
(2) I don’t necessarily disagree with most people, and in fact have myself quite-miserably by-and-large failed most coding interviews.
Having said that, I did want to share an opinion: the process has some legitimate reasons for being the way it is.
In writing this, I hope to help others avoid two traps I fell for:
(i) believing that the system is rigged, random and hopeless so you should give up, and,
(ii) that the only way to get into a tech company is to pay for an interview preparation service that will have you memorize stuff just like its founder did before making it into not one but TWO big tech companies. . .
Clearly, this will exclude many specific cases, all I’m saying is that looking at interview processes from your potential employer’s point of view may have a positive impact on your career as it’s had on mine.
After all, firms aren’t in the business of giving you a job, they’re trying to optimally solve problems for a willing-to-pay customer.
Below you’ll find a framework I came up with to help me understand why hiring is set up the way it is (it’s a work in progress; for now let’s call it “PPP” or “the three P’s” or something like that).
In computing, “big O notation is used to classify algorithms according to how their run time or space requirements grow as the input size grows.”
And yes, that sounds both boring in theory, as well as horrifying to talk about during white-boarding. However, if we translate that into practical English, it becomes extremely real:
When you code, are you thinking about how long your program is going to take? Time is money, and the team that may hire you has a P&L to look after.
Is your code using a lot of RAM? That could affect reliability, or require specialized infrastructure, or generate a way-too-high Cloud bill!
Is what you’re coding going to render server-side or client-side?
How does your solution affect latency/UX?
What if users only have access to 3G?
Check out this basic example of why solving algo-problems is so useful to a hiring manager.
On the left, you’ll see an effective solution to an easy problem implemented in Python3 where the dev is asked to find the integer that appears only once in a non-empty array of integers that appear twice. On the right, also using Python3, you see a solution 82 milliseconds quicker.
Have you ever met someone who uses an app and says “I wish this service was ~35% slower!” ?
At scale, those seemingly math-nerdy nuances have real-world, bottom-line impact: https://heap.io/blog/how-we-saved-millions-in-ssd-costs-by-upgrading-our-filesystem
At one point or another, depending on ramp-up speed expectations for your organization, you’ll likely be responsible for code that will make its way to production. Is it unreasonable for an employer to stress test you?
Without advocating for unprofessional, unhealthy or demeaning behavior, your lead, teammates and even stakeholders that you’ll be interacting with can benefit from the experience.
As imperfect, “speed-dating-like” and/or biased as it can be. A little pressure can help your employer ensure that you’ve done the work to get to the interview. Could someone easily get help solving a take-home exercise? Or in a far-fetched scenario, hire a freelancer?
Technologies rise and fall, come and go:
What remains constant, when boiled down to its very essence is:
Alas, don’t take my word for it. What do I know?!
Do, whenever you have some time though, read Joel Goldberg’s advice on how to have a successful career as a programmer after 45-years in the industry:
started my career with punch cards and I am ending in the era of cloud computing. Despite all this change, many principles that have helped me throughout my career haven’t changed and continue to be relevant.
Zero out of his 6 recommendations have to do with a specific technology.
Breaking into engineering has become a competitive proposition. With or without a traditional background.
Approaching it with empathy for what your employer needs can be challenging, and also helpful. There is, at times, method to the madness. And if nothing else, it’s probably better to get a job you’re a good fit for, and you’ll thrive in, than to easily get a position that isn’t right for you.