I have a decade of experience, working as a senior and staff engineer at megacorporations, have experience as a research scientist, am in a PhD program for computer science research, but lets just double check that I know how to use a hash table.
If it is standard at the company to give all candidates that same question, this is actually a good way to reduce bias in hiring decisions. Otherwise, you might bias toward hiring, say, people with college degrees or people who worked at large corporations, for example. And this might unintentionally bias against certain demographics that obtain college degrees at lower rates (for example).
Also, typically the point of these questions is to see if the candidate can solve a novel problem not if they can use a hash table.
People out there who can’t code interviewing for SWE roles, I can’t speak to, but there are definitely folks being asked to be fluent in code for non SWE roles who aren’t SWEs, so it makes sense everyone gets put through the leetcode grinder rubric to calibrate their level. I don’t think this is about misrepresentation, but expectation misalignment and a crude tool being necessary to evaluate human skills against a baseline.
(nearing 40, 22 years in tech, getting out asap, ymmv)
I did a bunch of really quick 15~20 min pre-interviews to check if the person was entering the right process before we both wasted hours of our time. Some who were supposed to have coded and deployed whole applications didn’t know how their versioning system worked. Or they reviewed PR/MRs a lot and tweaked a few lines here and there but had little practical knowledge of issues you’d regularly hit when developing, and only heard of popular tools and resources by name.
We could still had them onboard and give them time to get up to speed, but it’s harder to do when they weren’t upfront about it and you’re there trying to guess what else they’re bulshitting on their resume.
I’m a staff engineer and tech lead at a MANGA company. I code in up to 5 languages a day. I’ve written Network stacks, compression software, virtualization software, and the backbone of multiple PaaS platforms. And they were focused on whether I knew niche algorithms (apparently based on EXT3) and other stupid stuff.
That's a new one to me, what's it made of?
(All that's coming to mind is I presume totally unrelated: https://en.wikipedia.org/wiki/Manga )
there are a lot of them
At my last company, I joined as their lead developer and discovered they already had another developer in the pipeline they were thinking of hiring. They thought the guy was super senior, and when I read his CV sure enough he came across that way. He emphasized on his CV that he was not only a Java expert but an expert on the internals of HotSpot itself.
Probably he'd been saying that for years, and given how many firms use the JVM it's probably a great line. Unlucky for him he got an interviewer (me) who actually was an expert in the HotSpot internals and liked to relax by reading its source code. Guess what? He knew nothing about the JVM, not even stuff you'd learn by reading the user guide. I got the sense he'd read one or two popular press articles about it 20 years ago, put it on his CV and never updated it.
So we progress to some coding. He can't code. He struggles with even the basics of starting a new program in an editor and compiling it.
The guy was demanding a huuuge salary and great perks. After I wrote up what I'd found from the coding interview he was quietly dropped from the pipeline. They'd been about to accept because they were so dazzled by his claims but weren't checking them.
The "knew it once maybe sorta" problem is common, especially with C++ where lots of people were struggling with it in the 90s and then jumped to Java/C# as soon as they came out. But they still list C++ on their CV. Ask them to write a C++ program (that does anything at all) and they'll just refuse or state point blank they'd feel really uncomfortable doing that.
Lots of people lie about their experience unfortunately. They probably don't think of it as lying. They just write down every possible thing they've ever thought or read about and exaggerate, gambling that they'll never be called on it. And, they're probably right. That's why coding interviews took off.
Well, job postings are infamous for listing a ridiculous number of "requirements" that aren't really requirements. Those who are familiar with hiring know that job postings themselves are lies and encourage people to ignore the requirements and apply anyway. Even the people who work for the hiring company say this! So it's a two-way street. There are already perverse incentives created by the hiring companies. And we also know that resumes are screened for specific buzzwords. You may not be recruited or interviewed unless unless your resume has the right buzzwords.
I interview tons of software engineering candidates (pre pandemic it was at least one or two a week). At least half of my senior candidates fail basic phone screener questions.
These are questions that reflect something they'd be doing day to day in the role, but also are incredibly standard in our field.
The issue in most of them is that they've taken their support network for granted. The tons of developers before them who laid groundwork, and the others currently who take care of many tasks they consider junior.
Well that leaves them in a weird spot where they've not actually done a lot of the foundational work their predecessors set up for them, and they've let a lot of their skills atrophy by delegating to juniors. They'll even say as much and say "oh so and so does that, or they had it set up and it's great"
But then what am I hiring them for? Certainly they're not bringing a wealth of programming ability over, so maybe soft skills? That's hard to hedge bets on for a SWE, maybe as an product manager or something.
Again, at least half of software engineers I talk to for the screening round are not strong developers for the reasons I mentioned above.
I asked “do we want to have consistency or availability for this?”, to which the interviewer said “I want both”, to which I said “umm, I’m pretty sure you can’t have both, CAP theorem and whatnot”. We spent two minutes arguing which led to me taking out my phone and pulling up the CAP Theorem Wikipedia page, and eventually the interviewer begrudgingly admitted I was right.
I surprisingly did get an offer after that interview but I found it a little annoying to be interviewed by a person with less experience than me who I have to argue with because his understanding of computer science is wrong.
This is a hyperbolic rhetorical question but consider how much of modern work really is CRUD API gluing, and how much of that work is not rigorous engineering, but tedious implementation as per documentation and wading through hastily-thrown together legacy cruft written during previous crunch time.
How much of that work involves novel programming and memorized understanding? Most of it requires study of existing codebases, not given a blank REPL to hash out something new.
When I started interviewing I started off by jumping into what I considered to be not insulting questions, but I very quickly learnt how awkward that can be if the candidate just had no clue.
Now I start with for loops and preface it with "apologies if this seems too simple" or something like that.
You would be surprised how many people can't do a simple for loop. I mean really simple.
I really hate the contrived problems that interviewers pull from HackerRank and its ilk. Even if you could glean useful information from watching someone program a knight hopping around a phone dial pad (a real problem I've gotten, which I'm highly skeptical of its utility), it comes off as pretty irritating to the interviewee. You're not solving little programming riddles on day to day work, you're solving engineering problems, and I think that these leetcode questions don't reflect that.
I think there's evidence of this too; you can study for these leetcode questions and get better at them, so what exactly are we testing? You're not testing the person's experience, you're testing how long they spent on hackerrank the night before, or how many interviews they had recently.
I think one can fairly accurately determine my level of skill from my resume, and thus I don’t think that the leetcode interviews are all that useful. I keep hearing about senior engineers who can’t code, and maybe I’m just lucky, but that really has not been my experience when interviewing, and I don’t think “spent the previous night practicing on hackerrank” really gives you any useful information.