The tech interview prep industry
alexanderell.is
alexanderell.is
Yes, there is an entire industry around interview prep. Yet it’s also possible to do all of your interview prep without ever giving a dollar to anyone. LeetCode basic is free. There are numerous free websites that will walk you through the solutions to LeetCode problems. There are countless YouTube videos helping build interview skills.
Tech interviews aren’t necessarily fun, but I actually think it’s great that they’ve allowed us to move past the situations where people were trying to coast in on the reputation of their university or by getting an “internship” from their dad’s friend’s company. Letting people compete on a level playing field of technical interviews, albeit imperfect, is one of the things I’ve come to appreciate about the tech industry.
Where I work (and even other co's my friends work at) even if you wanna hire a friend as a candidate, your friend still has to go through a full interview process.
What's the alternative look like?
But it’s very “unfair.”
That person gets hired and fits in with the team. The team puts more effort into mentoring because they are friends and you end up with a strong teammate.
Team made of friends tend to level each other up or cover for weak areas.
Teams of strangers need to fit in socially.
Relationships level teams up quicker so if you are hiring every 6 months gets friends if you are hiring every 10 years it matters less.
At my current org, they don't. They go through the hiring process like everyone else, and the person that recommended them is not involved until they are hired or not.
They will very likely be hired because they are good, but the process makes sure of it.
A middle ground that I follow is to go back to the person referring and ask are we stupid for not hiring this person? Then we try and reconcile the interview performance with the recommendations.
Another thing that I generally do is never recommend to anyone great that I know to come work where I work. Nothing good comes out of that. They already have good jobs. There is some probability they won't be as successful in the new place. I would deviate from that under certain scenarios but as a rule I would not initiate that sort of change. If they come to me I'd happily recommend them (rarely happens, as I was saying, they have good jobs).
Referrals are tricky especially when there's incentives like referral bonuses and everyone starts referring their cousin's friend's uncle's neighbor (some other problems in that sort of culture but we digress).
And code puzzle style interviews prevent that how exactly?
If the boss's boss want's his golf buddys friends nephew hired, goes to HR and says "hire that person", then that person will go through the same interview process as everyone else, presented with the same puzzle questions as everyone else, and do as good or bad as his preparation allows him to do, just like everyone else...
...and then get hired no matter what, because, just like everyone else, HR people want to keep their jobs as well.
The rush of people trying to enter the software industry only happened in the past couple years I think. The demand due to the tech boom drove up both the pay and the numbers of workers employed. Sure, it's probably even harder to enter the top tier companies, but I believe there are much more opportunities than 20 years ago.
Until you hit the Senior/Staff level, no one really gives a crap if you were editing yaml files, toiling on a legacy app, or building the highest scale app on the planet. It just matters that you can pass the standard tech interview.
Now that people understand this, they are starting to optimize their careers at a company to simply do the minimum until they move externally for higher pay. You can bounce between reasonable tech companies doing literally nothing for higher and higher pay by simply switching once per year.
I suspect that we'll see a steady increase in attention paid for deliverables and a dialing down of the leetcode arms race over the next 5 years. The signal to noise ratio of this interview type is falling.
But big tech all have quarterly OKRs, performance plans and terminations for low performers, and managers/leads are interested to have strong contributors in team to deliver results, and let low performers to go..
If half the team is simply doing interview prep it’s unlikely management fires half the team.
...none of which information is shared with future employers. To do so is even considered a legally actionable violation of privacy in most cases.
I think what would work better is to get away from leetcode and do more internally developed design and coding exercises that are representations of the kind of things you’d see at that company. Yeah for FAANG type companies who are hiring thousands of engineers per year, maybe you need the leetcode style standardization in order to scale. But for everyone else that cargo culted these processes and doesn’t need to hire 5 engineers per day, it’d be great to step back and actually consider what you want to evaluate for.
> Unless you've made it to your "endgame" company that you're happy to stay at for a while, I feel investing anything more than the bare minimum to get your assigned work done is worth less than just grinding leetcode and otherwise studying for interviews. Doing an actual good job, above and beyond, is not going to be worth much when you're looking for your next job. Thus we're now seeing the rise of Professional Interviewers or Professional Leetcoders.
Very much this. With interviewing having become a second career in an unrelated field, people will choose whether to spend most of their energy in working the job or preparing for the next interview rounds in a year.
I always interview people based on the actual job they've been doing (based on what they claim on the resume). I don't care how good you are at leetcode because that's not what the job will be about. I care how and what you've been doing in your current and past jobs. So we talk about that instead.
Critics of the tech interview are certainly not against the merit-based selection --- it's more like the 1.5x engineers fear that the standardised interviews are being abused to allow 1x engineers who are "just-in-for-the-money" to appear as 2x, making their lives harder.
Meanwhile, 10x engineers probably are not bothered by this at all since 2x isn't enough of a threat.
I wouldn't call the coding interview "merit-based" selection either. At least not until we show any sort of relationship between success at that style of interview and the stuff we think matters more. I don't think we're seeing any sort of boom of quality software that has followed the changes in the way we interview, if anything, the opposite.
But you're exactly right in some sense. Back in the dot.com hay days we used to joke that if you had a pulse and could type you could land a tech job. It's sort of back to that. The industry needs a lot more good developers than what we have.
Tech jobs are well known for paying well (compared to the other jobs you can get if you’re not born into money) but have never been prestigious. Unless you’re considering the VP/CTO jobs that don’t involve algorithm solving and do involve being from the right Harvard fraternity.
The job title of “computer programmer” is extraordinarily prestigious compared to, say... barista, waiter, nurse, bus driver, police officer…
Getting into “tech” is a very big deal compared to almost literally any other field that is not law/medicine.
The underdog could get computer jobs before the current gatekeeping -- on enthusiasm, hard work, merit, and will.
The gatekeeping started by favoring the affluent (suddenly, going into dotcoms made more sense than that Wall Street job), and now other people have to invest in playing catchup on bro rituals.
I would almost argue the opposite, that this process opens doors for people who are not good software developers to get good software jobs. Since you can relatively easily prep for a software interview but no amount of prepping makes you a really good developer. Whatever the coding interview process measures, it's not how good of a software engineer/developer you are.
it also does not take into account any previous work done or any personal projects.
A person using a premium resource most likely have higher quality material and sometimes access to a seasoned professional that can give personalized feedback.
Who has more time to do leetcode? Who has a good network of peers to motivate them when they are not “feeling it”? Who is more likely to enjoy abstract puzzles/quizzes? A single mom in Philly or a wealthy Stanford grad?
Would you also say take home projects are also a level playing field?
Just like how I would argue take-home/side/past projects are an amazing signal compared to credentials. I won’t dare to say it’s a level playing field.
And when will the single mom in Philly find the time to memorize as many (or more, after all, its a competitive market) default-interview-questions, as someone born into wealth whith lots of free time on their hands and the financial resources to pay someone specializing in prepping them for exactly these interviews?
So, what did really change?
What resource is required to do that? Time.
What resource is in short supply to the Philly single mom?
> Who is more likely to enjoy abstract puzzles/quizzes?
Assuming someone doesn't, is programming a good fit? (genuinely asking)
Sure we can, and the assumption you give reveals the problem.
>you will be assessed based on your interview performance.
There's an implicit assumption here that as long as you prepare well, somehow you will get the job in tech. As if all you need to do is study up on algorithms, show your best self and it will be okay. At the end of it, you will get a great job which takes away your worries.
Perhaps that is the case in the FAANG/SF bubble, but that is not what is happening to a large section of the junior dev market outside tech bubbles. Requirements are rising and becoming increasingly more specific. Rewards are not keeping up. But to me, the absolute worst part is the ability to ace every measurable metric, to then be ditched for "not fitting the culture" or something related. The problem here is the utter lack of feedback which helps individuals stir themselves in the right direction. The current situation is more akin to walking through your local grocery store at winter to enter the lottery: not the worst situation, but definitely an off-putting situation.
The above is further exasperated by the way most companies filter individuals on personality traits which have no empirical evidence as to impacting the environment or their job performance. Additionally, many companies will not give you feedback on your technical assessment either, which is the bare minimum they could do.
If the tech interview alone was the problem, this discussion wouldn't be as hot as it is. The tech interview itself is just the tip of the iceberg.
Same question, only replace "programming" with literally any other engineering discipline:
Assuming someone doesn't, is marine engineering a good fit? (genuinely asking)
Do we expect someone who designs, plans, builds, tests and maintains seafaring vessels and their components to be great at abstract puzzles and quizzes?
Or do we expect them to know a lot about steel alloys and how they interact with seawater, about the effect waves have on different hull-shapes, and how to figure out how to best install a 7m drive-shaft in an engine room (or whatever)?
The self taught programmers were always the thing. If anything, current interview style is giving advantage to those from elite universities - it tests exactly those skills.
if people go to university and actually study and work hard to get a degree, it should be normal they don’t have to go through this bullshit.
i don't see how any of the above indirectly causes prevention of organization of a union.
If it required you to get a degree to get a tech job, far fewer people would be available. Far fewer people would be able to transition from low paid jobs to a higher paid job such as tech.
Making a specialized, technical field into a commodity is actually a global gain - even if those who used to enjoy a highly paid position gets their advantage lost because of such commoditization. Either they specialize into something that is even more valuable, or be lost amongst the commodity. Imagine if, during the iron age, the blacksmiths prevented the commoditization of industrial production.
the reason that tech prep and tech programs and STEM are promoted, and kids are sold on “learn to code”, is to LOWER THE COST OF DEVELOPMENT.
you say it like it's a bad thing.
Lowering the cost of _anything_ is good for society overall. It makes this resource more affordable for all entities requiring such resources, and it increases total output.
Doctors today costs too much, because there's a lobby group called the AMA that restricts entrants (rightly or wrongly). i would argue that it's better to have lower cost, because this service is valuable to people, and if the cost matches the value (or exceed the value), then some people will miss out on being able to utilize this resource.
>if people go to university and actually study and work hard to get a degree, it should be normal they don’t have to go through this bullshit.
There’s a significant number of candidates, who despite their CS degrees and fancy GPAs, can’t solve basic programming problems. And then there are the senior or principal engineer candidates who can talk a big game but can’t write fizz buzz.
Frankly, you can call it bullshit, but hiring unqualified people, coaching them, and eventually letting them them go is expensive. It’s not just expensive for the company, but it has a personal toll on the candidate, their manager (if they’re sincere), and the team.
Tech interview loops aren’t a perfect solution. We still let go of people who get through these loops. People try to study specific questions and anticipate the same or similar question in their own interview. Or other times, people get hired because the hiring manager is just bringing in “talent” from their previous company to expand their empire and get their promotion. Yeah… there’s corruption in every system.
> it has indirectly prevented knowledge workers from organizing.
I have literally no idea how unions are relevant or how tech interviews encourage or discourage unions.
The problem is, I am not trying to hire people to write FizzBuzz.
If I am looking for someone to compose a concerto for violin and lyra from scratch, but the question I ask them to determine their qualifications is: "Here is a whiteboard and a pen but you don't get a ruler, draw me a pentatonic scale freehanded in 30 seconds or less, and I will evaluate how similar it is to the picture here in this book on musical theory.", how nice will the resulting concerto sound?
There are many flaws in this argument: - what about people without degrees but skills, do they deserve such a job? - Is university free? If not, do poor people deserve such a job?
Finally, we are not talking about the average SE job. We are talking about the top 10% of the jobs where competition is fierce. People at this level, as in any domain, are willing to compete fiercely. Should the marathon been shortened to 10k so that people who can't train can compete?
What about people with actual problem solving and engineering skills, who worked hard to teach themselves, but are bad in test situations?
Some people cope well with tests. Others don't. Neither tells me ANYTHING about how well they will do as engineers.
> People at this level, as in any domain, are willing to compete fiercely.
But the competition is about "who's the best engineer", not "who was best at memorizing leetcode questions".
Personally, I wish there was a guaranteed pathway from a degree into an apprenticeship with the same pay and benefits as any other employee. If America wanted to grow and maintain its global economic power, it would guarantee a highly compensated job for every college graduate.
Just because people are willing to compete fiercely doesn't mean they have to. You sound like a crab in a bucket[0], when the reality is that the bucket doesn't need to exist.
I really take issue with this line of reasoning. The same thing was recently argued in relation to MIT going back to using SAT scores. The argument basically seems to be "Since no alternative to this is conceivable that isn't some form of racist/classist cronyism, this is actually the lesser evil".
At some point in history, people probably said something like "Since no alternative to monarchy is conceivable that isn't some form of despotic warlordism, monarchy is actually pretty good". ...they just hadn't conceived of those alternatives yet.
It sounds to me like simply a reflection of the political climate in the U.S. where there's a weird inversion of burden-of-proof whereby any decision making process is presumed a form of racist/classist cronyism unless proven otherwise.
The more mechanized a decision making process is, the more amenable it is to this sort of proof. But I certainly don't want to live in the resulting dehumanized dystopia.
Also, I'd question whether social reproduction is quantitatively a significant factor in selecting who tech jobs go to. The idea seems to be that engineer daddy gets son interested in engineering by doing science fair projects with him, sends him off to space camp, then pulls strings to get him into MIT and so forth. But, statistically, I'm expecting to have as many daughters as sons, and a daughter is statistically not going to be interested in tech. Even if it's a son, it's not clear whether he would have the personality traits and inclination. I wouldn't want to interfere with them either, as I'm not even sure that going into tech would be something I would want to do again if I could live my own life over.
The latter is not true of wealth in general. I would always want my children to be wealthy, and they would always want to be wealthy, and handing over wealth is as easy as signing a piece of paper. These latter statements are oversimplifications, but they highlight how the analogy breaks down between social reproduction in relation to wealth in general and social reproduction in relation to having a prestigious tech job. -- Also, the question of whether tech jobs can be prestigious seems subjective to me, as there are a lot of negative stereotypes attached to tech.
I believe Leetcode makes tech more exclusive, not less.
It’s a form of gatekeeping and hazing. It’s what you get when stem is hyped at every level of education. There are too many people gunning for tech. It attracts all the smart and ambitious students now. There is no programmer shortage.
And also closed the door for lots of smart, motivated people who are excellent engineers, but do badly in stressed up situations where they need to do something (coming up with an answer on the spot, usually w.o. being able to do any research) that the job they are being interviewed for rarely if ever actually demands of them.
> to move past the situations where people were trying to coast in on the reputation of their university or by getting an “internship” from their dad’s friend’s company.
https://en.wikipedia.org/wiki/Out_of_the_frying_pan_into_the...
The whole point of tech interviews are to prevent you from making a bad hire who embellishes their skills.
Indeed. And exactly how do code puzzle interviews accomplish that? Because here is the gist of what happens, as described in the article:
The similarities to the test prep industry are very interesting. Is an algorithm
interview reflective of how an engineer works in their day-to-day job? Along those
lines, what is the SAT really measuring?
But these sure look like employer problems:
a) Risking to miss out on good engineers that happen to be bad at skills that don't have a lot to do with the job.
b) Risking to hire people that are really good at prepping for standardized tests, but not at the skills the job actually requires.
c) Risking to have qualified people whith a choice simply walking out because they don't like companies using this hiring practice.
Also, I'm not sure how easy Leetcode is to practically game. I may be way off here (truly), but most people who can get good enough at solving Leetcode-style problems (and are willing to put in that time) are probably better than those who can't. This certainly misses some people, but as I said, finding a filter that only lets through above-average candidates, even if it misses some others, is what a lot of companies are looking for.
"A lot do XYZ" is not a sign that anything has "some value".
> that is better than your random personnel at your company can come up with
I'm sorry, what are companies hiring for: To solve the problems they are trying to solve? Or to solve the puzzles in a standardized test? And who knows these problems and the skills involved in them better, a standardized test, or the people already working on them?
> are probably better than those who can't
Better at what?
It is a signal that maybe there's something you're missing. "I think everyone else is doing this thing wrong" is sometimes true, but often wrong, or at least incomplete (because goals might be different).
> I'm sorry, what are companies hiring for: To solve the problems they are trying to solve? Or to solve the puzzles in a standardized test? And who knows these problems and the skills involved in them better, a standardized test, or the people already working on them?
The problem is that being good at hiring and at evaluating people is itself a skill. A skill that some people have, and some people don't. It isn't necessarily correlated with how good a developer someone is.
The other problem is that if you come up with a different "test" every time, it will make it much harder to compare different interviewees. I still ask interview questions that have to do with a system I built 10 years ago. I of course could update the question to something I'm working on now, and I certainly change the emphasis on what exactly I'm asking. But sticking to a question that I know works well, and that I've used many times, makes it much easier for me to evaluate people.
But let's just be clear - what would you suggest as a hiring criteria? Do you think the team that is hiring (which in large corporations might also not be the team that gets the hire, but that's another story.) You think the team that is hiring should come up with specific questions based on their current work? How often? How often should they change them? Who should be doing it, every team member?
I'm trying to get a sense of where we actually disagree.
That isn't the point. The point is, just because a lot of X do Y doesn't indicate that Y is the best solution, or even a good one.
> The problem is that being good at hiring and at evaluating people is itself a skill.
Yes, that's why we have HR departments, and why these can take input from the technical departments to do part of the evaluation.
> The other problem is that if you come up with a different "test" every time
Why would I do that? I am not advocating designing completely new interviews for every candidate, I am advocating not using the same interviewing process for every candidate in the entire industry.
HR departments can't do technical interviews. You need technical people for that. But being technical isn't sufficient, you also need to be good at interviewing.
> I am advocating not using the same interviewing process for every candidate in the entire industry.
Is it the same process for every candidate in the industry? I'm not in SV, so maybe it's different here, but I've seen many different processes at many different places, and they were definitely not all identical.
At least leetcode puts the power to look good in the candidate’s hands. Just like the SATs, it’s not exactly fair to the people who can’t afford prep, but it’s more fair than the alternative.
What alternative? Talking to people, presenting them with company problems, and listening to their opinion about them, aka. "how would you do X if you had Y?" kinda questions? Getting to know them in the interview process, to see if they are a good fit to the people already in the department? Taking the time and risk involved to hire people if they seems okay and then evaluating them during a probation period?
Because, to me that looks a lot fairer than "HERE SOLVE THIS PUZZLE REAL QUICK ON WHITEBOARD NO LOOKUP ANYTHING YOU GOT X MINUTES GOGOGOOGOGOOGOGOOGOOGO!"
I've mentioned this before but it seems to me like the current cargo-culted interview process was designed to not find applicable candidates in the US to get around the H1B visa requirements.
The reason many companies moved closer to Leetcode style problems is that the alternative, which is to not ask people to actually program during interviews, made companies end up hiring people who don't know how to code at all.
And just saying "we'll hire for a probationary period and then fire them if they can't code" isn't a very good idea, for anyone involved. Companies are usually reluctant to fire, so they might end up with a bad employee. And even if they don't, most people don't want to make a major change like starting a new job, if there's a significant chance they'll be fired fairly soon.
And how exactly do puzzle style interviews prevent that, when it's simply possible to learn for the test, instead of learning what the test tries to evaluate?
> the alternative, which is to not ask people to actually program during interviews
The alternative to "puzzle interview" is not "no programming questions". Interviews should always give examples, including architecture questions, questions that test the general understanding of the candidate and at least ine small example problem that has to do with the real codebase.
That's an adequate test to filter out people who can't code, and a far cry from completely arbitrary and unrelated puzzles that can be memorized in advance.
I was specifically responding to this from the parent comment:
> What alternative? Talking to people, presenting them with company problems, and listening to their opinion about them, aka. "how would you do X if you had Y?" kinda questions?
Which I understood to mean that no actual coding would be done, it would be more of an open-ended interview about work history / etc. Which I would argue is far worse than Leetcode style questions.
And I'm also arguing for the idea that the fairest interview is the one that gives the most accurate answer to "will this person be a good developer for the company".
But of course if there's something that's even better than Leetcode, obviously companies should want to adopt that instead.
At our company, we do something very close to what you propose:
- an initial phone screen with a very simple "Fizzbuzz" style programming filter.
- After that, an open-ended architecture problem (how would you build such-and-such system), which can go in many different directions, and can include a few specific coding examples.
- Finally, a real programming task for ~1-2 hours. Sit down in front of a computer with access to internet etc, and do these tasks.
We find that these in combination give a great answer to all our questions (well, the "ability" portion at least, which has the most weight.)
If you want to work for us you better be able to complete this leetcode question! You’re not a real engineer if you can’t!
Then the real work is an awfully designed mostly front end disaster. Nobody knows how anything works. But they passed the interview somehow.
I don’t get the people who do leetcode for fun or who get hyped up about it as an interview process. I guess they made it in life by cramming for tests just to forget it all immediately after.
Wasting time memorizing tedious things that have no value is especially awful and draining for me. It’s not fair some people can just do that if they spend a small amount of effort and try. It’s a monumental impossible task for me when I’m otherwise exceptional with software engineering. I’d rather climb a mountain, to put it in perspective.
I’d rather actually learn the concepts used on tests and be able to adapt them into my learning, rather than have a history test where I fill in an endless amount of blanks with the exact day, month, and year is somehow relevant or useful for anything.
Does anyone actually process those types of questions as actual comprehensible dates instead of memorized strings that are better suited to memorize with a jingle?
What I'm finding is that the leetcode isn't a memorization game, it reminds me more of my homework in grad school algorithms. Each of the problems is meant to tease out your practical understanding of an abstract concept.
It certainly doesn't guarantee you'll be a good dev if you can pass leetcode type questions, and you're not necessarily a bad dev if you can't, but I can definitely see where performing well at leetcode is a strong signal about SWE fundamentals.
This absolutely still happens though. Those people will just get "fast tracked" through the process and allowed to skip steps. If there is even an interview at all. Nepotism is still alive and well even in software.
Edit: Oh, or they will get hired as consultants / contractors at a high rate and get to add your company's name to their list of happy clients
When you consider the work you do to earn money/whatever else you value at a job the step increase by passing tech interviews at a big company is almost always worth way more time and/or money than many people put towards it. I think students in particular need to realize the importance of these kinds of interviews relative to their schoolwork if they're forced to make the tradeoff.
I am a small participant in the Interview Prep industry since I purchased Cracking the Coding Interview - but it's no surprise people are willing to pay for interview prep (assuming it's both quality material and the individual needs that particular kind of help) when the ROI is so high
The thing that opened my eyes to the fact that 4x and 5x salaries are possible was people posting honest descriptions of their salaries and places like levels.fyi.
I am incredibly thankful for the people who went before me in terms of being open and honest about how much they can make as a software engineer if you just choose the right company.
I don't think "humblebrag" is an appropriate response to this person's message since it might have a chilling effect on their decision to publicly say stuff like this in the future.
... and at least from my perspective people saying this stuff is quite literally life-changing.
I live in a western European country, and my cheap neighborhood is full of unskilled migrants, and they came here without being crack-shots at leetcode, I know that much.
What makes you think only Google/Meta is the way?
Regardless, I hope you manage to come here.
FAANG for me is just a dream because of the salary. I don't think there is anywhere in continental Europe where you can make well over €100k per year other than google/meta.
Overall I think positively of the 7-8 rounds of interview + leetcode grind. If it was just because of resume or credentials, I'm not so sure someone with a darker skin tone and clearly foreign sounding name like me would even get a chance to interview. I think tech is very empowering for us, "smart" people from the minorities, at least it gives us hope of fairness and objectivity
Google/Facebook etc should feel an obligation to deflate this thing.
Context: I work at a FAANG
Interviews and hiring at big companies aren’t perfect, but they never will be. Any type of evaluation or test will at best be a proxy for the thing you want to ultimately measure: true performance in the role being interviewed for.
I don’t think it’s any company’s place to discourage the interview prep industry. Those who are most determined will seek out resources to increase their chances of interview success.
The big downside to the prep industry is that, wherever the cost is high, it lead to greater inequality. Not everyone can effort practise interviews and paid online courses.
One positive step I have seen recruiters at Apple, Facebook, and my own employer do is to share free 3rd party resources to help with interview prep. Candidates may not be aware that there are free, high quality sources. These being unofficial endorsed by recruiters helps candidates avoid some of the scammier sites.
This reminds me of the MCSE early days. That certification was extremely valuable in the late 90s, early 00s, until there were thousands of interview prep tests. Ends up people would get the cert and not have a clue how to do any type of meaningful administration. Now, the MCSE's value is quite diluted.
Given that there is now a prep industry, I don't think the leet code interviews have much value anymore. It's simply rote memorization, which was devalued given search technology we've had for ~25 years.
Stumbling into one of these without prep is like showing up for a tryout on a football team and finding out that you'll actually be playing Tecmo Super Bowl with a controller you've never held before. And slowly realizing that all the people interviewing you are fantastic video game players who have never been in the weight room, and they spend all day LARPing.
Are these people not actual product managers at the (presumably successful) company that you want to work for? What is the basis of accusing them of being LARPers?
Google engineers do not so much solve problems as create them and pretend to solve them.
This particular FAANG does have a poor track record on products that have any kind of real-world component. I tend to approach products from an issue-spotting, pre-mortem perspective that's focused on mitigating roadblocks.
I could tell where I was falling short was that they wanted to hear about how it would scale to billions of users rather than overcoming the 0-to-1, 1-to-10 barriers that I was focused on. The response was always that they could skip those steps because of their massive resources.
The parent's description of this as LARPing is eerily accurate.
I get that recruiters are incentivised to get new hires, but the whole "here's this tedious interview process, and here's everything you need to study to be able to pass it" makes me feel like they're optimizing for people who are tolerant of dealing with a lot of bullshit.
I'm a hiring manager. I've interviewed more than 100 people over the past 6 months. I really want you to be successful in the interview. I would love for a 10 minute conversation where you say "yeah, I've faced the problem you are facing. And here are the next 3 problems you are going to face. And here is how you should prepare for them." Or even "wow, I'm not equipped for this. What I really want to do is X. Is that useful?" And then I referred you to a buddy that is looking to do exactly that.
I don't want to surprise you. I don't want to give you an interview question where you get nervous and I have to guess if you actually know how to code stuff. I want to give you an environment where you rock and I can accurately tell you what problems I have and we both decide if this is going to be a good fit for us.
Somethings I don't want. I don't want you to fret or prepare for 10 hours. I don't want a take home interview that lasts >2 hours. Or a take home where you were honest, but I'm comparing you against someone who cheated.
Actually, I was going for the opposite. If a hiring manager gives you something to help you, it is because it is mutually beneficial to help.
That being said, I used to work for a fortune 500 company, and the comment about trying to select for people who can put up with a bunch of paperwork is probably an important skill to select for
https://www.metacareers.com/swe-prep-techscreen/
And heres the one I was given "the loop" interview (theres a link "our comprehensive Facebook Onsite Interview Guide" in the first paragraph):
It seems like all this preparation to pass an interview is the meta-career.
For 5-7 years "Cracking the Coding Interview" was all the rage, practically everyone said to review it, do the practice problems, etc. In the past 3-4 years it's become "make sure you practice your Leetcode an hour a day! Even some hards!", and then from what I've seen while interviewing and practicing the past 2 months, there are websites dedicated to providing study plans, additional review, recommended problems to practice to review specific patterns, etc. Youtube channels, even.
Those last few are also pretty heavily monetized. Leetcode has some limits in place to nudge people to pay for Premium plans. Some websites require a membership. Youtube videos and blogs usually have a plethora of ads.
Of course you don't _need_ to pay anything, but it tends to help more people.
Then they hire these people and need to stack rank and fire the bottom because their process makes so many mistakes.
A better interview process would involve lottery balls.
More than that, it is the illusion of merit. A lottery is an admission that the level of talent required to be productive at these big companies is vastly overstated and that the algorithmic puzzles are just eyewash. That is way too much truth.
OTOH, Passing these interviews gives you that chip on your shoulder that you passed a high hiring bar. Of course, I'm sure you know all the memorizing it took, and how you got lucky that a question you revised was asked at the interview and you feigned ignorance. It will take a critical mass of people who are willing to call out this bullshit and maybe a few really egregious cases that go viral before people start to push-back on this.
For instance, for one problem I was given in this way, I had one small logic implementation bug, about one line off that was ruining the output of the algorithm.
My interviewer went, "here, I'll just copy it from them." and pasted, presumably, a solution from Leetcode/wherever they got the problem from.
At the very least if you're going to ask a LC problem (or any problem, really) you should be able solve it yourself; this way if the candidate is mostly on the right track except for a bug here or there it gives you a real world chance to debug it with them and further evaluate their communication and collaboration skills.
Of course, so far in my recent set of interviews it never works that way.
The Leetcode interviews are a freaking step forward from that. Although they are optimizing for new graduates who have all the time to lose/spend to play with algorithms and "competitive programming"
Are you a middle age gal/guy with a family? Its easy to filter you out because you cannot put 3 hours daily to practice your l33t sk1llz
It's even worse in some companies that just give you a bunch of CS questions to solve, because a lot of the time it's possible for candidates to just memorize a bunch of interview questions and rely on that, regardless of their actual problem solving skills.
There might a better way.
When I interview candidates I've started putting less emphasis on O-notation algorithms and how to optimize them, which is pretty much the norm in most tech interviews (make this faster, do this in-place, etc), and started putting more emphasis on the candidate's understanding of IO, specifically when working with databases, congestion, rate limiting, queues, the stuff you actually encounter when working on real projects in my domain. Asking open ended questions and basically building a tiny project together.
The experience has been enlightening. You can immediately tell the person's analytical thinking because most of what they learn in "interview prep" isn't directly helpful in this situation. You can see some people frantically trying to match the problem with something they've seen in a video or a book instead of stopping for a moment and giving it some actual thought.
At the present I'm pretty certain that asking a person to build something is the best approach to understand their skill level. But this requires more time from both parties.
It's not black and white. I do think that as a tech lead you need to be able to demonstrate some technical skill in your day to day. You should be a pretty good coder. You should be a pretty good debugger. You don't need to be a competitive programmer which is what some coding problems are modeled after. You do need to know enough of your CS to recognize a pattern where there's theory that matters. You do need to be able to look up the relevant info/papers in that case and be able to understand them.
There's also a plethora of other things you need to do as a lead that related to the engineering side of things. design and architecture. testing. CI/CD. requirement management. project management. people skills.
Sort of reminds me of the joke where you take your car to the repair person because the engine is making noise. The guy listens to hit and hits a spot very hard with a hammer and the engine is running again. No noise. The bill says $100. So you ask him $100 for hitting a spot with a hammer? He's like $1 for hitting the spot with the hammer, $99 for knowing what spot to hit. Coding some dynamic programming algorithm on the fly in an interview is hitting the spot with a hammer really hard. Knowing what spot to hit is most of the what you care about in a good software engineer.
Sure it's not black and white and every team needs to hold interviews in a way that befits them most. For our team the ideas I described work pretty well and we've been able to pretty much nail it from students to seniors.
I am just advocating that recruiting should not be a one-size-fits-all thing and that the massive prep industry is only focused on a certain type of interview, which is just not always the interview you should be conducting. Give it thought and spend the time to tailor the interview process to your team.
Here's to everyone's success while interviewing!
I'm also curious what your pass/fail conditions are? I find that if the pass/fail conditions aren't rigorous, then you open yourself up to things like "I just really like that guy," and select for people more similar to you rather than people who might bring the most to the table.
Using open ended questions and building a small "system" together allows you to draw the actual knowledge limits of this person and pivot when something gets too hard so you can explore another 'direction' which will be based on different areas of knowledge or experience. It also allows the candidate to show off if they really want to feel smart.
You mentioned that it can introduce more bias to the process, so before I touch on that, I think it actually introduces a chance to test your communication with this candidate which (at least for me) is pretty much equivalent in importace to their credentials.
As for passing conditions: I prepare a standard "interview project" that has many different paths for us to work on. We work it together but it's mainly the candidate. Alongside the problem I have a fairly substantial excel sheet for assessment of all candidates. Every component in the "interview project" has some pitfalls, some more obvious than others, all occuring naturally in every path the candidate chooses. You start seeing who can see ahead and think on their feet in a situation that more closely resembles what we do in my team.
Eventually I can compare the candidates based on this standardized performance sheet, so I'd like to think it's not too biased. As a bonus, it's a pretty good experience. I know it was a good interview when the candidate thanks me for learning something valuable. It's a great interview when I learn something as well. Sometimes they want to stick around and continue tackling the problem even after we're done, or they want to actually build a POC and send it in!
As such, puzzle-based interviews are optimised to reject candidates who are not smart enough and have either not bothered to play the interview game or those who don't have what it takes to learn to play the game.
There may be a certain amount of "plays the game" necessary to succeed in one of these roles. If your first thought is "well what I would do for these companies is better than what they would want me to do", then that's exactly my point point---They may actually care more about your ability to take orders than about your ability to solve problems independently (even if they say the exact opposite in their culture talking points).
Is that optimal for the company over 100 years? I don't know. Is it even possible to know?
Just speculation.
The weird thing is that now you even have small dipsh!t start ups that have even harder/longer interview process and questions than some of the large tech cos, which doesn't make sense. It is a form a cargo cult following that it is detrimental to the whole industry.
1. Google is skiping phone screening for many (more experienced folks, as they found it was low value, and filtering out really good candidates. Yet many startups keep doing them.
2. Google is going towards a team hiring strategy, where specialized skills will be more valued, rather than the current 'generic leetcode' process.
3. I just went through an interview process of an old startup/not yet IPO company, and had to go through 10 stages!!
1. Recruiter screening
2. Phone Screening
3-8. A full round with 6 interviews (6 hrs long).
9. Final manager interview/round
10. Call for references, which a previous manager was a must
It was insane, like I was interviewing for a CEO and not just another IC Engineer role. At some point, I started refusing companies that had extremely long processes. They almost are never worth it.
I've literally never had references contacted. Where are you located?
I have had this 'references', but requiring a former manager was a first. The whole process had way more interviewing rounds than Meta and Google did. At least Google decided to skip the phone screen for me.
Money isn’t everything, for sure, so if you’re happy here stay here. But let’s not blow things out of proportion. Ranting about an exercise that involves only your brain for 30 minutes that could turn to hundreds of thousands of dollars to gain, sounds like a kid ranting about exams. Do you know other jobs involve physical labor? Have you seen cheerleader tryouts? No one owes anyone any luxury. If a company decides for any stupid reason that they want to keep a hard interview then it’s their prerogative.
Companies that can pay this much aren't rare. They're all in plain sight. FAANG, Coinbase, Stripe, Brex, to name a few.
The industry found a way to retain talent for cheap, a. la "I'll never leave my current company at this point"
The real advantage in leetcode is that it is well structured and relatively straightforward to scale preparation in. Practice lots of questions from a pre-defined bin of algorithms and data structures and you're good.
Assuming the candidate is actually skilled, the real killer in most interviews is if the format of the interview is new or if the interview is some sort of technical discussion and there is impedance mismatch between the interviewer and interviewee. Leetcode has no chance of this happening -> you get the optimal solution or you don't.
Ultimately, the problem with leetcode is that it is a very flawed way to scale the interview process that was foisted on us by Google. Interviewing is supposed to be a human process, so any way of "scaling" it is bound to be stupid in one way or the other.
From the perspective of earning potential, puzzle solving is a better skill to have as a software engineer than actually engineering software.
In theory, it's a pure test of solving a problem using code that is distinct from questions that need knowledge about particular technologies. You can give the same problem to frontend, backend, mobile, etc. candidates. You can ask them for any team. Mac, Linux, Windows: doesn't matter.
You can deliver the question over the phone or video chat. No need to clone a repo, send a ZIP file with boilerplate. Interviewers and candidates don't have to fiddle with getting an environment set up because these questions rarely require anything more than standard library on coderpad.
Does it actually do that?
Let's see who has more time to grind and memorize 200 questions: The single mom working 2 jobs or the kid from a wealthy family?
Let's say that she does, which isn't certain btw. (it's still CV-check before interview, that fact didn't go away)...then what? She now has to compete by doing something that actually has little to do with the day-to-day job she's applying for, and is time consuming to prepare for.
So, in the limited time the Philly single mom has between her current job(s) and caring for her child(ren), she not only has to teach herself software engineering (aka. the job shes applying for), she now ALSO has to grind coding puzzles, which doesn't really help her getting good at what shes trying to do, and is just for the interview process.
Maybe she's actually a natural at programming. Maybe she worked her a** off teaching herself languages, frameworks, tooling, best practices. Maybe she even built some projects to showcase her skills, ready to present to recruiters on her github.
Oh but behold: code-puzzle interviews enter the ring, and suddenly, none of that may matter, because to even get to the part of the interview process where she can show how good she is at the actual job shes applying for, she now has to tackle that additional obstacle that she may not be as good at, and certainly didn't have the opportunity to devote as much resources to as the people who were already holding all the advantages before.
Let that sink in for a moment. It is now possible for the Philly single mom to be actually better at the job shes applying for, but losing the competition against a worse candidate, who used available resources to prepare well for the code interview, enabled by how predictable the evaluation process became.
So no, this method doesn't break down any walls. If anything, it creates new ones.
I applied for a job recently and their first response was a blanket reply with a codility test. Which I ignore and moved on to other opportunities. They contacted after a week asking about it and I had to inform them I would look at other opportunities without a test barrier.
Best jobs and places I worked came because of informal conversations during the interview.
Excepting the one startup, every ody sent me a canned response with a code challenge.
The startup replied to me with a human asking me to talk. That's the place where I ended up going , and was the best decision for my career (gameloft closed doors some years later)
interviewer: um, ok, I'm not interested in that, we will spend the next 20 minutes talking about linked lists and arrays followed by random leet code live coding. Also, be sure to spend a large amount of the limited time talking about various solutions to random questions and come up with the optimal solution. I will make sure there is no time at the end for your questions.
me: okay thanks for your time, I got about 12 more linkedin messages to go through today.
Standardized tests are designed such that preparing for the test isn't helpful.
Current tech interviews aren't like that at all.
Then in your opinion are all the SAT prep books useless?
Not quite --- "preparing for the test" is also known as "studying".
You were probably thinking of IQ tests.
But I think there's a difference between preparing for a specific test, and studying in general.
Let's say you have 2 days left to study for the GMAT. You could study the relevant math, reasoning or whatever. That might help.
But you'd do far better by working through problems in a Princeton Review GMAT book, and looking at their tips for the questions you got wrong.
The tips might be generic test-taking tips (e.g. eliminate obviously wrong answers) or they might be more specific (e.g. relating to specific types of problems found on the GMAT).
"Get-to-know-each-other" type of interviews are nice, but it's rather inefficient when a job posting receives hundreds of applications.
Quite the opposite. The common IQ tests are not resistant to preparation. But the big standardized tests are.
Of course, in the real world no IQ test is ideal.
Mountains of effort go into the same project for standardized tests, because taking those tests is common, and the whole point is to evaluate people for what they are rather than what they would like you to think they are.
However, ultimately, I failed the final test, which was a non-technical sit-down with a company executive. Not a cultural fit.
I like remote work. Nobody cares if you're a "cultural" fit.
LSAT, MCAT, SAT and GMAT are all standardized tests that reward those who prepare specifically for those tests.
I used a couple of books to prepare for the GMAT. I'm pretty sure that this preparation:
- helped me get a better score than I would have gotten without that specific preparation, and
- did not improve my 'aptitude in x, y and z' (the thing the test is designed to measure)
And how is that supposed to be achieved?
When something is standardized, it follows certain parameters. After a while, these parameters are known to the public, and people can prepare for them.
2. Algorithm technical interviews provide a structure for companies to compare skill levels of different candidates against each other
3. Neither is the best scenario for either party but in a chaotic world without structure, each one is trying the best they can towards filling a job role by meeting with someone in a span of 45 minutes.
Personally as a founder of an interview prep company for data scientist (https://www.interviewquery.com/), I find that we try to just teach candidates concepts through bite-sized problems and repetition. Some people might hate it, but we're essentially playing the game that the companies are holding up. So you might as well learn to get good at it.