Can I just add "Leetcoder" as a part time job on my resume? It is amusing how in this industry, your ability to interview will not at all be improved by spending time doing your job unless it is algo heavy. It is a separate job entirely.
Whiteboard interviews are used, not because they have a lot of relevance to the job, but because they're a hard-to-fake indicator of high intelligence. Somebody who shows a lot of mental fluidity with complex data structures, almost assuredly can quickly master any specific tech stack. Even more so than a less intelligent person with years of experience in that specific tech stack.
It's the same reason that the military selects infantrymen based on word synonyms and fast mental arithmetic. What does that have to do with loading a rifle or marching in formation? Not a whole lot specifically, but whenever they've lower the intelligence standards, the results have been disastrous.[1]
There are other important qualities for certain. Honesty, resilience, hard work, enthusiasm, being a team player, reliability, etc. But almost all of those qualities are easy to fake and hard to assess in a 30 minute conversation. People who are hired on these qualities, are usually tapped from a pre-existing network, not selected from the recruiter funnel. If you've only got a half hour to choose a candidate, then pretty much your only reliable option is test their intelligence.
[0] https://psycnet.apa.org/doiLanding?doi=10.1037%2F0022-3514.8...
That's not an argument that you can eliminate test anxiety, but certainly if we can reduce it without destructively eliminating the high value candidate pool we should do so.
If your company only hires above the 95th percentile but their method for finding that quality cutoff is heavily skewed towards a certain demographic, in the long run that company may well perform worse than a company that hires at the 80th percentile but without the demographic skew.
From the data I've seen made public, FAANG are usually more diverse than other companies.
I guess if you make the test hard enough, always change it, and add some unhealthy dose of suspicion over the candidate's behavior, you can maximize that ratio. But I'm not confident FAANG even looks at it. It's much more likely that they just postulate that a hired employee is a competent one and go on with their day.
From the candidate point of view, of course, things are very different, and the negative results are much more important.
By now it mostly correlates with effort spent preparing. There's dozens of web-sites, companies, consultants and message boards where one can train for those interviews. Whiteboarding is a skill like any other, it can be trained, faked, etc.
"But almost all of those qualities are easy to fake and hard to assess in a 30 minute conversation."
Perhaps it's not possible to assess somebody's future job performance in a 30m conversation.
I just have a problem suggesting learning this one set of skills really boosts my fluid intelligence. Im probably just as intelligent as I was before.
But I do get the cooralating signal as a cheap, low false positive approach to selecting good candidates.
And for the interviewer to not arrive with the expectation that you will pass the same hazing ritual they passed to deserve that big paycheck?
It’s been a long time since I interviewed at a FAANG but I don’t think my whiteboard mojo played much of a role. It was more down to my personality fit with the interviewers, and the correctness of my algo answers. Which were still pretty softball way back then.
Everything I’ve read and heard since then makes me think it’s much more about those things now, and even less about general mental agility.
The ASVAB iirc was designed to determine critical thinking and mechanical skills. If you aced it, you either studied or shouldn't be in the army.
The fact that they aren't trying that, and are instead attempting to get a measure of coding ability, suggests they don't really believe in the approach.
Administering an IQ test would be legally risky and could have a disparate impact on protected classes.
Griggs v. Duke Power Co.[0] is the Supreme Court case on this topic.
Surely you realize large companies are full of people whose friends just told them what the questions were going to be? Memorizing 4 problems is still easier than cramming 40.
I don't understand - what is the point of you interviewing them if you aren't there to judge them? What are you doing it for then?
That's the difference between "that interview didn't go well" and "you are a bad programmer." One's a major blow to self confidence, and the other's a bummer. It's also a helpful mindset shift for both the interviewer and the interviewee: both of us are working together to achieve the goal of proving your capabilities. My job is to give you as many opportunities as possible to do so.
I think it's because most interviewers consider people that failed their interview bad programmers.
You may not care whether I value you as a person, but at that point, that's your problem and not mine.
I'm not even exaggerating, I believe this is a major source of strife in modern societies.
The more prestigious the employer then the less forgiving they are on your shortcomings.
...isn't that judging? Making a judgement on whether a candidate is coachable is judging isn't it?
Judging whether a candidate is coachable, their thought processes relevant to the job, understands the ideas etc is what the interview is for, you're right.
But "I'm not judging" doesn't refer to that. It refers instead to the concept in the word "judgemental". Some definitions of that are "having or displaying an overly critical point of view" and "thinking, speaking, or behaving in a manner that reflects a critical and condemnatory point of view".
The use of the term "not judging" is a bit strange, without further context.
Just to theorize: how about having the interviewee write a narrowly scoped toy project that's relevant to the position? (Edit: On site, as a replacement for white boarding.) A JS to-do app for a front-end engineer, for instance. Just a short thing you and the candidate can attack together in a couple hours. The candidate can write "normal" code, google things, clarify requirements, use their own architecture/patterns/style to reach the solution, etc. You could even add/change a requirement midway through the session, too. That would be realistic, and test for brittleness (and maybe be mean).
I don't interview people, so this might be hopelessly naive, or maybe untenable for some types of positions. But that interview process strikes me as a far more representative microcosm of an actual job than regurgitating LeetCode solutions or hardcore algo arcana.
Of all the companies I have worked at, this was by far my favorite interviewing technique. But, I think it works best when you pair with the candidate. So if pairing at your company is not done, it might not be a good fit.
Unless your hiring pipeline is absolutely perfect (you pretty much get great candidates all the time and almost no bad ones) this doesn't scale at all.
Interview processes are designed mostly for the employer, not the candidate. That's just the reality.
On the other hand, something like a homework assignment is typically good for a single company, and if you fail, it's time and effort and emotional energy down the toilet.
Are extremely prestigious or have compensation clearly above market rates.
Candidates only have so much time to dedicate to homework so they will sort companies and work on homework assignments from top to bottom.
Homework are easy to grade (some of that can be automated!) and low commitment from the employer side. But that low commitment sends a signal that the candidate isn't really valued.
Having an on-site with engineers sends a much better signal as it tells the candidate he's worthy of discussing with a real engineer on company time rather than some gradings software.
Of course, if your recruiting pipeline is very poor (low signal to noise ratio, majority of applicants can't code) then sure, weed out with a homework assignment.
I get that it's not very real-world representative, and that's why homework is used instead by some companies.
Maybe the answer is to give the applicant a choice? Either be prepared to convince me you know what you claim, or demonstrate it with a take-home problem.
Personally, I'd prefer a day of in-person-pair programming as part of the interview. I'd get a better feel for the team and their workflows. If it's a total horror show, it's good to know up front :)
I prefer to have multiple short interviews with different engineers rather than a single multi-hour long one with only one engineer. You get better feedback and it helps against bias.
Not only that but a "toy JS app" implies the candidate knows JS at all. If it's college recruiting, you are better sticking with algorithms since you know that they know it.
Watching folks make something -- for any significant duration -- is perhaps a better estimator of a candidate's genuine job ability than testing how well they approximate an algorithm textbook. Well...that's the assumption, anyway.
They filter for general problem solving skills. Whether you acquired those skills through a degree, self-study, a week of leetcode or 3 months of leetcode will be up to your individual background and aptitude. It's a hiring process - filtering for something is the whole point. Personally, I prefer being tested on more general stuff (like algorithm problems) over most of the alternatives.
The way to pass a leetcode interview is to know exactly what the interviewer is asking and then pretend like you've never seen this problem before. Then you amaze them by pulling a rabbit out of a hat. We are all a bit dumber for putting up with this charade.
Not necessarily saying you're wrong, at least not when it comes to general trends, but nonetheless this definitely needs a citation. Is there really that much of a correlation between 1) general intelligence and 2) happening to find the "trick" corresponding to a typical tech interview problem?