The software engineering industry has gone mad. Strong developers feel discouraged to apply for positions with large companies, like Microsoft, Salesforce, or Amazon. Those who find the courage to apply go through weeks of stress. They burn midnight oil racking up points on LeetCode or HackerRank covering as much of an algorithmic landscape as possible. You just never know if a sneaky interviewer will throw a Fast Inverse Square Root problem at you to show who’s the boss. Even though the vast majority of developers will hardly use any of the algorithms they are expected to memorize for a day of the on-site torture, companies continue to beat the algorithmic drum. To add insult to injury, companies make developers write code on the whiteboard or a Google doc, which lacks basic syntax highlight or IntelliSense.
This is the sentiment a sizeable chunk of developers share, and some thought leaders spread. It feels like the industry moved on, but interviewers are stuck in 1980. If you are one of these developers, first of all, congratulations on making the right career choice, and second – let’s pop the hood of the madness and see if there’s a method to it.
Algorithm is a word used by programmers when they do not want to explain what they did
Reddit
A word on inclusivity…
I wrote this article and shelved it because I didn’t like the language. Then I took another editorial pass to make it more inclusive to readers and shelved it again. This process continued for weeks until it dawned on me. The topic of interviews is inherently elitist and at odds with inclusivity, despite the intentions of the author. Someone will pass an interview and someone will not. The article that attempts to justify the interview methodology that deprived someone of the dream job is tone-deaf. If you had an unpleasant experience with this methodology recently please consume this content with a grain of salt.
Every team wants smart developers
Define smart. The debate between smartness and knowledge has been settled some time ago and most of us intrinsically understand the difference. Smart people find ways to overcome obstacles, in some cases lacking complete knowledge. For example, just because someone is a Masters of Science doesn’t mean that he or she is capable of making good decisions. Definitely knowledgeable, though.
There is a more formal definition of intelligence – for example, Bloom’s taxonomy, if we focus on the cognitive domain only. FANG companies do not use it as a formal measuring stick (I hope). It is just one of the ways to skin the cat.
In the picture above, every next layer from the bottom to the top builds on the previous layer. For example, it is hard to demonstrate Comprehension when there’s a lack of Knowledge. At the same time, possession of Knowledge does not indicate understanding. As such, the dependency chain is downward.
In our industry, smartness correlates with the upper side of the spectrum on the picture – it implies the ability to solve complex problems. A lot of projects in our industry are complex. Those that set out to be simple, quickly evolve into monstrosities under changing requirements, in the best spirit of agile methodology. Teams want to hire developers that can take a critical look at the code and navigate complexity, ideally reducing it. Simply put – it is not enough to be a React.js guru.
Algorithms represent canonical problems disconnected from a particular application domain. Linked-list traversal could apply to the airline industry as much as manufacturing. Engineers who solve algorithmic problems will also be able to solve non-algorithmic ones. If someone doesn’t understand a piece of technology but deeply internalizes complex algorithms, he or she will be able to master technology over time. Knowledge is a lower layer in Bloom’s taxonomy stack.
Prominent technology companies customize the interview questions to people with high cognitive abilities. Every hire is an investment that yields dividends over time, so it is perfectly fine to give people time to close any knowledge gaps. On the flip side, no amount of technology questions would evaluate the candidate’s ability to solve problems.
“Give a candidate your bug and watch him/her fix it”
There’s a belief that the best way to find quality candidates is to pick a real bug from your product, hand it to the candidate and let him or her fix it. There is one glaring problem with this approach – the candidate must understand your product, it’s architecture, and development tooling well enough to be productive. To evaluate whether it is reasonable to expect a candidate to master all three during the interview it is worth looking at a typical ramp-up curve of a new hire.
Candidate takes about a year to reach productive output of an average employee in the company. It doesn’t mean candidate doesn’t do anything for a year. It only means that a human being with an average learning agility demonstrates competence in the product and technology after a year with the company. Some people learn faster and get there in 9 months.
For the first 6 months of employment, the company pays the employee to learn and isn’t getting much in return just yet. The employee does fix bugs, participate in design discussions, works on user stories, and does everything the rest of the employees do. However, the complexity of the tasks and execution velocity is lower than the average engineer. Most of the time employee spends asking questions or looking for answers. He or she heavily depends on the mentor and is not fully autonomous yet. During this period he or she is “consuming more value of the company than produces it”. The employee reaches equilibrium between consumption and production of value after 6 months.
Now let’s look at the idea of giving a candidate a bug to fix on the day of the interview. It is akin to asking an engineer to fix that bug immediately after the new employee orientation. This expectation is unreasonable. There is a mountain of questions a person needs to ask to understand what is even going on in the bug. He or she lacks the product knowledge, context on the repro steps, backend API or database schema, control and data flow, etc, etc, etc. So please, do not ask candidates to fix real product bugs during interviews.
“Candidate needs an IDE and can’t code without a syntax highlighter”
Every single developer uses Integrated Development Environments that highlight language constructs, suggest fixes, and contain macros to speed up code production. Developers are notified when they make syntactic, stylistic, performance, or even architectural mistakes. As such, when developers are invited to write code in a Google doc or a whiteboard they struggle with language itself. No developer codes in the Google doc, so why do these companies create artificial barriers for developers?
The answer to the question is twofold – attention to detail and language proficiency. No candidate comes to the interview with English grammar. Since they speak the language every day for many years they understand English language constructs and fluently express themselves. The same idea applies to the programming language. If you’ve written hundreds of C# classes in your career, you can write another one without IntelliSense or even using your brain. It is muscle memory at that point. Your fingers type the text on their own while your brain is solving the problem concurrently.
The key to achieving world-class expertise in any skill, is, to a large extent, a matter of practicing the correct way, for a total of around 10,000 hours.
Wikipedia summary of the Outliers book by Malcolm Gladwel
A good developer deeply scrutinizes every single character they type. Was it a class or a struct? Did I seal that class? Did I write a Component or a PureComponent? Those questions fly above the developer’s head if IDE just slaps pre-canned syntax into the editor. IDE can’t infer the developer’s intent. It is up to the dev to correct IDE. If he or she doesn’t – he or she is not attentive to details. There are performance differences between memory allocation on the heap and the stack. Would you hire a sloppy developer to work on a critical part of your high-frequency trading platform start-up?
“Candidate must know every algorithm under the sun”
Nothing can be further from the truth. No competent interviewer would ask a candidate to produce an exotic or complex algorithm completely off the top of their heads. Vast and expansive knowledge is not the point of algorithmic interviews, remember? If you do find yourself in this situation, thank the interviewer for their time and leave the building. This company is not worth your energy. Leave the feedback with the recruiter and keep looking.
There is a tremendous value for professional developers to be aware of a variety of algorithms and data structures. Knowledge can be handy for current or future projects with any employer. I’d encourage developers to spend time on the LeetCode solving problems occasionally, but not stress about it. Do it on your own terms when time permits. Algorithm-solving death march a week before the interview is not healthy and will not improve the chances of landing the job offer.
If you code every day you do not need to prepare. If you have to prepare, you will not pass.
Oleg Ignat
A word on interviewer superiority and candidate intimidation
The interview process should not be stressful. I wish there was a magic button to put candidates at ease and convince them that they are talking to future friends and colleagues, rather than people who judge them. The reality of our industry is such that companies need good software developers more than software developers need those companies. We are in the candidate’s market, and I see no signs of the tide changing. If you are going through the interview process, know that nothing would make your interviewers happier than extending you an offer of employment.
Occasionally you may come across interviewers who ask niche questions – those that require deeply specialized knowledge or solve problems seemly unrelated to job responsibilities. Amazon’s hanging wire problem, anyone? Before judging the person asking the question, it is best to clarify how exactly the question at hand would help predict your success in the role. Very likely the interviewer is fishing for something and may have chosen a poor question, without evil intent behind it.
Highly specialized algorithms, like a Linear Regression, are not suitable for generalist interviews. They are perfectly adequate for an ML engineering position though. If your entire life flashes before your eyes after the interviewer finishes explaining the algorithmic problem, remember, he or she is not there to win “who’s the smartest” match. The best course of action is to work with the interviewer to find a better question that enables him or her to evaluate your fitness for the role while giving you a problem within your area of expertise.
Happy coding and may your path to the dream job be O(1).