I understand the frustration, but at the end of the day I think they do serve a purpose. They're not great at that purpose, but they're good enough and they generally produce false negatives (smart people fail) rather than false positives (you hire an idiot). And this makes sense, because a false negative is low cost (maybe you spend 50% longer interviewing candidates) but a false positive is high cost (you hire an idiot and have to spend months establishing that, firing them and starting the hiring process again).
The side effect of this though, is that it's an extremely painful process for the applicant. Even if you're a great software engineer, you're going to freeze up, miss something, have a bad day, and fail a few interviews. Now for most software engineers failure is an unusual and harrowing experience, so they react really badly to it. Especially ina
scenario where it's difficult to blame anyone but yourself. But just don't! It's fine! just move on, there's plenty of jobs and the interview process is a blunt tool, not a final evaluation of your worth in life.
At all the companies I’ve run we’ve used a simple whiteboard example for this reason. Don’t worry about typos; how does the person think.
“Trick” questions are dumb, but you want to get an idea of if the candidate knows their stuff (and let the candidate know what we’re like — interviewing is a sales process in both directions). If someone asks a question like “is it ok to modify the argument” (or says “I’ll assume I can’t modify the argument”) that’s great (or says “I can’t remember if strlen includes the 0 byte so I’ll add 1 — normally I’d look it up”) - again, no trick questions.
When I say “simple” it’s something like atoi or “shuffle a deck of cards”: basic, but not 100% trivial like fizzbuzz.
On of our best hires was a guy who made a fundamental mistake — when we asked him if it world work as intended he said “I’m a fucking idiot” and fixed it. You’re not supposed to talk like that in an interview I supposed but we read it as a strong positive signal.
We had one candidate who insisted that parsing a string and returning an integer was an unreasonable question because there was already a library function for it. “But what if you have an embedded system and no library?” (an actual situation for us, for part of our system). He was adamant — honestly that was a failure of the phone screen: had it been caught it would have saved us, and him, from wasting time.
Okay, do do quizzes, but let people google goddamn stuff because that's just how software engineers operate. Don't make it an exam. Don't mimic the worst thing about the education systems. Both in the school and in the university, these goddamn exams were the worst because they tested memory first and everyone else second, and I'm such a kind of person that I could never remember things on command. It was a real struggle. I can't be the only one.
I've never been through the "regular" IT hiring process myself, but I've interviewed several candidates for an Android developer position. I liked asking questions and looking at how the person thinks. I didn't expect exact correct answers for every question, I just wanted to see whether they have a fundamental understanding of Android. After that, they had to build a small app at home (not my initiative) to show their skills.
> They're not great at that purpose, but they're good enough and they generally produce false negatives (smart people fail) rather than false positives (you hire an idiot).
I've seen this reasoning, but I'm wondering if this is actually true, especially if you also believe the other myth in hiring: most people applying are not qualified for the job. Since most hiring actually requires you to fill the position in the end (in other words, you can't leave it open indefinitely if no one qualifies as eventually the pressure to hire mount up), every false negatives does increase the odd of you hiring a false positives as well. Just take the example at the extreme, if there is only ever one person on Earth qualified for your job and you got a false negatives on him, there is no other way but getting an idiot in the job.
They do produce plenty of false positives - just not "you hire an idiot" kind. You will hire a person completely unsuitable for the actual job, but is good at leet. Issue is not the lack of intelligence. Issue is not being software engineer despite being good at algorithms. Or not being good at whatever your position requires.
I do work in a team where majority was hired by puzzles of sorts. All of them are smart. They are not software engineers and it shows massively.
Hard leetcode questions hire grinders, not thinkers. Many of those questions were thesis/publication-worthy decades ago when first solved; it's unlikely for even a very intelligent person to produce a similar result in just tens of minutes. So if someone solves it, it's much more likely to be because they saw it or a similar question while grinding practice questions than that they genuinely derived the optimal solution from scratch.
>because a false negative is low cost (maybe you spend 50% longer interviewing candidates)
this would make sense if they filled these positions in 2,3 weeks tops. But that's the insane part; I hear of interviews going on for 6-7 stages now, lasting almost 6-10 weeks. At that point I feel you are no longer avoiding false positives, but simply hiring the most desperate programmers willing to jump the hoops. The best candidates will get an offer mid interview at that rate.
>But just don't! It's fine! just move on,
I've been "just moving on" for some 9 months now. There's only so much morale in a tank, no matter how BS you know the whole process is. I just wanna move on in life, not be bogged down on how many permutations you can color an N x M grid with.
That false negative can be pretty damn expensive if the good engineer you didn't hire could have saved your ass from the situation the less-good engineer you did hire couldn't handle.
FWIW, I have come across examples in the wild of engineers who were extraordinarily polished and facile at everything leetcode, and poor at computer science. Not many, but some. This is a somewhat recent phenomenon.
Best tests are simple and common computer science problems in algorithms and data structures with no tractable solutions. There is no facile answer, you truly have to reason from first principles for any particular scenario because there is no alternative.
The problem with Leetcode-style test nowadays is that there's too much cramming. Otherwise, leetcode-style interview has certain correlation with one's geekiness and raw talent. Just this week my team solved a long-tail performance issue by first building a simulation of a queuing system, and also built a customized Coffman–Graham algorithm to resolve the order of execution of a complex task graph. I would certainly appreciate that my team members just get it when someone mentions basic CS concepts like topological order in a graph or queuing theory.
If, after all of the normal interviews, you randomly selected candidates who passed and do not make them offers . . . you generally produce false negatives (assuming the interviews mostly worked).
How do you know they produce false negatives over false positives? How do you know if your top candidates simply didn't cheat over the honest candidates that produced worse but honest code?
I once had an interview that I really liked. It was for a bank.
They give the candidate some messy, done-in-a-hurry code (but not purposefully obfuscated) and ask them to refactor it to the best of their ability. The interviewer sits next to the candidate and talks to them throughout the whole process. It's pretty much pair programming, but the candidate has the initiative.
I found it to be a breath of fresh air after all the leetcode interviews. Of course, they have the luxury of doing this, because they know what exact technologies they are using and they don't need to measure candidate's ability to learn new tech, etc. In their situation they are more interested in topics like whether the candidate can produce maintainable code, name things properly or communicate with co-workers.
This is an interview style I do often.
The first bit is just super basic shit (since I mostly do database stuff) and then a code review section.
What's super interesting is I have actually had people pretty much fail the basic stuff (which was probably nerves) and then go on and kill the code review section in ways that shows their serious expertise.
IMO interviews are pretty bad at demonstrating people's ability to work, but if you can zoom in and out on a problem and do good enough on the coding stuff its usually a win.
Leetcode style interviews probably serve two functions:
1) A way to suppress wages and job mobility for SWE. Who wants to switch jobs when it means studying for a month or two? Also, if you get unlucky and some try hard drops an atomic LC hard bomb on you now you have an entire company you can no longer apply to for a year.
2) A way to mask bias in the process while claiming that it’s a fair process because everyone has a clear/similar objective.
Meet someone who went to your Alma mater? Same gender? Same race? Give them the same question as everyone else, but hint them through it, ignore some syntax errors, and give them a strong hire for “communication” when they didn’t even implement the optimal approach…
Or is it someone you don’t like for X reason? Drop a leetcode hard on them and send them packing and just remain silent the entire interview.
To the company this is acceptable noise, but to the individual, this is costing us 100s of thousands of dollars, because there’s only a handful of companies that pay well and they all have the same interview process. Failing 3 interviews probably means you’re now out $200-300k of additional compensation from the top paying companies.
I’ve interviewed for and at FAANGs. I can’t believe the low bar of people that we’ve hired, while simultaneously seeing insane ridiculous quad tree/number theory type questions that have caused other great engineers to miss out on good opportunities.
Someone will reply to me “if you know how to problem solve you will always pass.” Ok, come interview with me and I will ask you verbatim one of those quad tree/number theory/inclusion exclusion principle questions and I’d love to see you squirm, meanwhile another candidate is asked a basic hash map question.
The important thing to screen a software engineer for is not knowledge but the strength of their problem solving and ability to build mental models of problems.
Whiteboard interviews are a good way to evaluate these skills - assuming the candidate hasn't seen this particular problem before and the interviewer understands that this is what they're supposed to look for.
Goodhart's law applies - the measure becomes a target and it ceases to be a good measure.
People who have weak problem solving skills or poor abilities to form mental models still want high paying software jobs so they "grind leetcode" until they can pass these interviews.
Then over time these grinders get high enough up they start becoming interviewers themselves and they don't understand that they're even supposed to screen for talent, they conduct the interview like a memory test since to them that's what it was.
In spite of this, there's no better interview type I've seen proposed given the constraints most companies are under (don't waste candidate's time, have a consistent rubric that HR likes, etc.) so for now we're going to keep using it.
A friend once in the middle of a technical interview stopped speaking, stood up and went out. They ran after him, "what's wrong, you're doing fine!" and he told them it depresses him too much and he's not interested anymore. Sad, given that this is a fun profession for most of us (I assume)
5 years later, I still refuse to do them and I don't want to put myself through that process ever again. I got bullied, harassed, laughed at and taunted by people who use this as a one-hour game of kicking people around and I'm not interested in entertaining them any more. I have the following disclaimer both on my LinkedIn [1] and GitHub [2] profiles because I had plenty of surprise-leetcode interviews, so I want to make it clear up front what's acceptable and what isn't.
> I have a personal policy against any type of live coding or online coding tests during interviews and I don't enjoy or engage in any form of competitive programming. Otherwise, I am happy to work offline on coding assignments with reasonable goals and deadlines and to have in-depth technical discussions about software architecture and design as well as relevant technologies.
I like the idea of your approach. Can you share anything about how well it's worked out for you?
My main concern is that with the allegedly rampant cheating on take-home assignments, the number of employers willing to use them may drop precipitously.
I see these posts a lot, and I sort of disagree with where they are coming from so I'll play devils advocate. Leetcode is used to select for one of (or both of these) 2 things for the average IC hire:
1. Do you work hard (i.e a person who studies many problems, memorizes solutions, and regurgitates then)
2. Are you smart (i.e a person who doesn't do any leetcode but knows the fundamentals and can sythesize past knowledge well enough to answer a new question)
Now in a vaccuum, my takeaway from someone who doesn't pass a leetcode question is that they are more likely to not be either of those (given no other information about them). In my opinion, solving at least one leetcode easy - medium question (maybe with some direction from the interviewer) should be the standard for any role where you need to code.
And realistically, companies index less on leetcode skill as you become more senior or apply to more niche roles. And plenty of companies out there have bug squash rounds, system design, behaviorals, take homes, trivia, background specific questions, etc. Leetcode is usually not the be all end all for hires above entry level. Leetcode is not meant to magically select for the best engineers. Its simply another signal for the hiring committee to use.
The last few interviews I've run, I've shown the candidate sample code and asked them to review it. We have samples that have at least one bug / problem per line. Then some modeling task (whiteboard). We have some simple exercises (fizzbuzz style) to figure out if juniors actually can junior and as a springboard into discussing topics like runtime complexity, memory layout and stuff. This is all highly interactive, depending on how well the candidate does. The idea is to figure out if the candidate somehow faked themselves through screening as well as to somehow get a feeling for cultural fit...
Send the candidate off with a broken unit test to fix, own tools, comfortable environment like home, 1 hour time box.
I like to do something horrible based on timezones, or phone number validation, with a Wikipedia article that is the spec.
At the end, ask the candidate about their solution, and do a code review session.
The (best) seniors just use a library.
The good candidates roll their own, but can explain the tradeoffs.
The juniors get the test to pass and stop.
I've interviewed developer candidates who seemed to know a lot of theory, but when it came to write some code, they failed miserably. They could not implement fizz-buzz. Senior Java developers who could not import HashMap without looking it up.
It's kind of like math. If you need to multiply 562 * 1041, you should use a calculator. If you need to reach for a calculator to tell me how much 3 * 7 is, I will doubt that you are an expert.
Many companies overdo the leetcode interviews. A live coding interview that shows that a person can do array manipulation, implement flow control, and use basic data structures shows me that you have the muscle memory that only comes with experience. If you need to study graph-traversal algorithms in order to pass, it's probably too leet.
Such interviews are made to legally discriminate against old developers.
A freshly graduate student has more chance to still know this or that algorithm, and prepare for that.
An old/experienced developer has dealt with plenty of real world complex problems. So much that his attention is absorbed by them, not by what is the best way to search for an element in a tree.
I know what you're saying but I don't think there is any kind of nefarious backroom discussion that goes on to this purpose.
I think more likely though are the accidental favoritism in the industry where engineers submit resumes of other engineers they know who are looking for a job who, surprise, are also white males.
I don't believe it is either racist or sexist however. It's just "who people know". Nonetheless, you're going to build a hive-minded team if you don't go out of your way to break these patterns.
Perhaps similarly leetcode interviews come about from engineers who were leetcode interviewed. Again, no need to jump to ageism as the cause.
(And if anything I think it may have turned a corner where the older devs may have more experience with interesting algorithms that, I don't know, might not be taught any longer in CS?)
The whole point of being an “experienced developer” is that you know more than the new grad. What kind of experienced developer forgets basic computer science on top of which all else is built?
I've interviewed lots of developers and recommended 'hire' to about 15 people in the last several years and not once did we get it wrong.
All it takes is a short problem to solve at home, which can be easily googled and one hour architecture interview, where we discuss the technical architecture of a hypothetical 'real world' service.
It takes about 20 minutes to determine if the candidate has the experience with the technologies listed in the resume.
Little experience is not necessarily a show stopper.
True that the language we hire for (Clojure) filters out a lot of people ahead of time, but knowing the language is not exactly what I look for..
What I look for is 'passion' - does the candidate love programming and can the candidate articulate technical issues with ease.
The other question I try to answer - will the candidate enjoy working in our team and will we enjoy working with him/her.
Smart people will shine in a certain way, even if they bomb specific questions - they have an opinion, they try, they ask the right questions.
I'd be sad if we missed on some of the people in our team because of automated (inhuman) puzzle interviews.
We're not looking for a problem solving machine, we're looking for a partner to create something great together, someone who shares our passion for hacking and someone who we'd love to work with.
I share TFA's opinion that leetcode-style interviews are not the way to go and I hope the industry comes back around and focuses on the human side more.
I'm happy that Amazon have a horrible leetcode style interview practice. In my interview I had to design an algorithm to detect certain combinations of fruit and veg bought from Amazon fresh, which would trigger fruit-machine style payouts. If I hadn't said "f this" and did something that actually interests me, I would probably have a huge mortgage sitting in rainy ol Blighty designing user hostile experiences like Prime cancellation. I'm poorer, happier, healthier and mentally iron-clad doing my own thing, making just enough money and travelling to where life has a reasonable cost.
Isn't the entire point of memoizing this to demonstrate you are able to study/grind rather than prove intelligence? Different companies/managers have give me different reasons for the usage of this style of interview but it was usually to 'assess ability to get through rough stuff' and 'assess cognitive abilities'.
Idk anymore either and I refuse to conduct these interviews.
I generally prefer somewhat realistic problems that are multi-disciplenary but have ties to real world applications related to the role.
The market is so bad, and most interview sucks one way or another. The main reason is interviewer have tens or hundreds application for same position.
I have just went through one interview that have 4 rounds.
1. half hour talk
2. 2 hours coding for several crud api.
3. system design project ( I spend 2 days on it. they told I have about a week on it)
4. another half hours with CTO.
and then got rejected. (The interviewers does not bother to send a reject letter. I asked them they told me the position is closed).
Since 99% of people have to study hard to pass LC (medium/hard), it effectively acts as a selector for employee conformity. People who play by the rules imposed upon them, who work long hours if corp wants them to etc.
All the talk about diversity, but no diversity of thought. Only LC chasers.
I genuinely believe this decreases innovation massively.
I quit doing engineering work for companies, but back when I did, I'd take some complex code I'd written to interviews. I tell the interviewers that I'm happy to step through my code and explain it during the interview, but that I wasn't interested in wasting hours of my weekend writing a werpderzle or answering gotcha questions.
Some companies agreed and I ended up working for them and some companies didn't, so I'd end the interview. In my experience, companies that over-complicate the interview process also over-complicate their day-to-day work, and I don't have any interest in working in that sort of environment.
I wish I could, as a candidate, ask leetcode-style questions to my interviewers, too. If I am to work with them, they should prove to me that they can pass them, right?
Interviewers tend to forget that they are in a dominant position: they have nothing to lose, they are the ones who take the decision, and they are the ones who chose the questions. I have been in such interviews where I completely failed, but where I am absolutely certain that I could have made the interviewer fail as well were the roles inverted. It feels a bit hypocritical to fail someone who did not actually do worse than you would have done...
It is perfectly fine to ask anything from the interviewer. How long have they worked there? Did they have other jobs? Why did they leave? Is there anything specific that is great about this place? Why are you looking for employees? Did someone quit? Do you have a lot of meetings? Do you enjoy coding? Do you have anything interesting on github?
Not specifically that but give it your own twist.
If they are confused remind them that getting along with people and fitting the team is at least as important as the ability to do work. The work is the least of your concern. It will probably involve dusting off some old skills and learning some new things.
A good interview is an absolutely rare thing. I can't name the chances, but throughout one's career it's going to be close to amount of jobs one's going to land. More likely less than that number.
From my experience you can say it's going to be good or bad right from the start. 5 minutes into an interview and you can already see where's it's going to end.
I don't understand when companies try to give test assignments to senior devs. Even if your GitHub or whatever profile is not rich with projects you can evaluate person's professional level during the conversation.
And I also hate stupid riddles during the interviews. But there was an interesting case. I got a couple of verbal puzzles that I should have solved right at that time and I failed. But I got the job anyway. So I guess if people in the company are common sense driven it helps to choose hiring strategies that work for both sides.
Agreed on first two points. You often can get a feel of a company based on the interview.
> I don't understand when companies try to give test assignments to senior developers.
I think this is perfectly valid, though. When I interview candidates, I start with the conversation and I can tell you that more often than not it goes very well: talking about software design, architecture, what they think about various frameworks, etc.
But you would be surprised how many people can talk their way through the interview, and then get totally blocked on a simple syntax error in the code. (Stress being accounted for).
I agree, though, that the questions should be fairly designed before the interview and be consistent with the level of the expertise expected for the position. I would never ask a senior developer to implement a FizzBuzz. We'd rather sketch an architecture for some piece of software with some specific constraints, discuss the choices of the language and libraries and argument them, etc. And yes, eventually code something: just sketch some core domain logic. I would never hire a software developer, whatever the level, without seeing them coding first.
Everyone thinks they are google, if you are like 90% of tech companies and have a crud app, maybe a couple mobile apps and a few backend systems and admin tools, a radical idea is to involve your engineers in the interview design process and tailor your interview to the actual job they will actually be doing. Front end engineer and your stack is react? Pair with them on fixing a UI bug, backend engineer in rails, pair with them on a adding a basic endpoint. You get the point. If an engineer pairs for 30 min with someone I can pretty much guarantee they will have a strong sense of how they work and whether they know their stuff. I really don’t know why we treat this like it is some impossible task to determine if someone can do the job, just try doing the fucking job.
[+] [-] SilverBirch|1 year ago|reply
The side effect of this though, is that it's an extremely painful process for the applicant. Even if you're a great software engineer, you're going to freeze up, miss something, have a bad day, and fail a few interviews. Now for most software engineers failure is an unusual and harrowing experience, so they react really badly to it. Especially ina scenario where it's difficult to blame anyone but yourself. But just don't! It's fine! just move on, there's plenty of jobs and the interview process is a blunt tool, not a final evaluation of your worth in life.
[+] [-] gumby|1 year ago|reply
“Trick” questions are dumb, but you want to get an idea of if the candidate knows their stuff (and let the candidate know what we’re like — interviewing is a sales process in both directions). If someone asks a question like “is it ok to modify the argument” (or says “I’ll assume I can’t modify the argument”) that’s great (or says “I can’t remember if strlen includes the 0 byte so I’ll add 1 — normally I’d look it up”) - again, no trick questions.
When I say “simple” it’s something like atoi or “shuffle a deck of cards”: basic, but not 100% trivial like fizzbuzz.
On of our best hires was a guy who made a fundamental mistake — when we asked him if it world work as intended he said “I’m a fucking idiot” and fixed it. You’re not supposed to talk like that in an interview I supposed but we read it as a strong positive signal.
We had one candidate who insisted that parsing a string and returning an integer was an unreasonable question because there was already a library function for it. “But what if you have an embedded system and no library?” (an actual situation for us, for part of our system). He was adamant — honestly that was a failure of the phone screen: had it been caught it would have saved us, and him, from wasting time.
[+] [-] grishka|1 year ago|reply
I've never been through the "regular" IT hiring process myself, but I've interviewed several candidates for an Android developer position. I liked asking questions and looking at how the person thinks. I didn't expect exact correct answers for every question, I just wanted to see whether they have a fundamental understanding of Android. After that, they had to build a small app at home (not my initiative) to show their skills.
[+] [-] NhanH|1 year ago|reply
I've seen this reasoning, but I'm wondering if this is actually true, especially if you also believe the other myth in hiring: most people applying are not qualified for the job. Since most hiring actually requires you to fill the position in the end (in other words, you can't leave it open indefinitely if no one qualifies as eventually the pressure to hire mount up), every false negatives does increase the odd of you hiring a false positives as well. Just take the example at the extreme, if there is only ever one person on Earth qualified for your job and you got a false negatives on him, there is no other way but getting an idiot in the job.
[+] [-] watwut|1 year ago|reply
I do work in a team where majority was hired by puzzles of sorts. All of them are smart. They are not software engineers and it shows massively.
[+] [-] logicchains|1 year ago|reply
[+] [-] johnnyanmac|1 year ago|reply
this would make sense if they filled these positions in 2,3 weeks tops. But that's the insane part; I hear of interviews going on for 6-7 stages now, lasting almost 6-10 weeks. At that point I feel you are no longer avoiding false positives, but simply hiring the most desperate programmers willing to jump the hoops. The best candidates will get an offer mid interview at that rate.
>But just don't! It's fine! just move on,
I've been "just moving on" for some 9 months now. There's only so much morale in a tank, no matter how BS you know the whole process is. I just wanna move on in life, not be bogged down on how many permutations you can color an N x M grid with.
[+] [-] hiAndrewQuinn|1 year ago|reply
[+] [-] Suzuran|1 year ago|reply
[+] [-] jandrewrogers|1 year ago|reply
Best tests are simple and common computer science problems in algorithms and data structures with no tractable solutions. There is no facile answer, you truly have to reason from first principles for any particular scenario because there is no alternative.
[+] [-] hintymad|1 year ago|reply
[+] [-] drewcoo|1 year ago|reply
But it's entirely pointless.
[+] [-] fzeroracer|1 year ago|reply
[+] [-] yreg|1 year ago|reply
They give the candidate some messy, done-in-a-hurry code (but not purposefully obfuscated) and ask them to refactor it to the best of their ability. The interviewer sits next to the candidate and talks to them throughout the whole process. It's pretty much pair programming, but the candidate has the initiative.
I found it to be a breath of fresh air after all the leetcode interviews. Of course, they have the luxury of doing this, because they know what exact technologies they are using and they don't need to measure candidate's ability to learn new tech, etc. In their situation they are more interested in topics like whether the candidate can produce maintainable code, name things properly or communicate with co-workers.
[+] [-] palata|1 year ago|reply
Well leetcode interviews do not measure the candidate's ability to learn new tech either, do they?
[+] [-] hobs|1 year ago|reply
What's super interesting is I have actually had people pretty much fail the basic stuff (which was probably nerves) and then go on and kill the code review section in ways that shows their serious expertise.
IMO interviews are pretty bad at demonstrating people's ability to work, but if you can zoom in and out on a problem and do good enough on the coding stuff its usually a win.
[+] [-] dinobones|1 year ago|reply
1) A way to suppress wages and job mobility for SWE. Who wants to switch jobs when it means studying for a month or two? Also, if you get unlucky and some try hard drops an atomic LC hard bomb on you now you have an entire company you can no longer apply to for a year.
2) A way to mask bias in the process while claiming that it’s a fair process because everyone has a clear/similar objective.
Meet someone who went to your Alma mater? Same gender? Same race? Give them the same question as everyone else, but hint them through it, ignore some syntax errors, and give them a strong hire for “communication” when they didn’t even implement the optimal approach…
Or is it someone you don’t like for X reason? Drop a leetcode hard on them and send them packing and just remain silent the entire interview.
To the company this is acceptable noise, but to the individual, this is costing us 100s of thousands of dollars, because there’s only a handful of companies that pay well and they all have the same interview process. Failing 3 interviews probably means you’re now out $200-300k of additional compensation from the top paying companies.
I’ve interviewed for and at FAANGs. I can’t believe the low bar of people that we’ve hired, while simultaneously seeing insane ridiculous quad tree/number theory type questions that have caused other great engineers to miss out on good opportunities.
Someone will reply to me “if you know how to problem solve you will always pass.” Ok, come interview with me and I will ask you verbatim one of those quad tree/number theory/inclusion exclusion principle questions and I’d love to see you squirm, meanwhile another candidate is asked a basic hash map question.
[+] [-] CSMastermind|1 year ago|reply
Whiteboard interviews are a good way to evaluate these skills - assuming the candidate hasn't seen this particular problem before and the interviewer understands that this is what they're supposed to look for.
Goodhart's law applies - the measure becomes a target and it ceases to be a good measure.
People who have weak problem solving skills or poor abilities to form mental models still want high paying software jobs so they "grind leetcode" until they can pass these interviews.
Then over time these grinders get high enough up they start becoming interviewers themselves and they don't understand that they're even supposed to screen for talent, they conduct the interview like a memory test since to them that's what it was.
In spite of this, there's no better interview type I've seen proposed given the constraints most companies are under (don't waste candidate's time, have a consistent rubric that HR likes, etc.) so for now we're going to keep using it.
[+] [-] apples_oranges|1 year ago|reply
[+] [-] mihaitodor|1 year ago|reply
> I have a personal policy against any type of live coding or online coding tests during interviews and I don't enjoy or engage in any form of competitive programming. Otherwise, I am happy to work offline on coding assignments with reasonable goals and deadlines and to have in-depth technical discussions about software architecture and design as well as relevant technologies.
[1] https://www.linkedin.com/in/mtodor
[2] https://github.com/mihaitodor
[+] [-] 6510|1 year ago|reply
[+] [-] CoastalCoder|1 year ago|reply
My main concern is that with the allegedly rampant cheating on take-home assignments, the number of employers willing to use them may drop precipitously.
[+] [-] boshalfoshal|1 year ago|reply
1. Do you work hard (i.e a person who studies many problems, memorizes solutions, and regurgitates then)
2. Are you smart (i.e a person who doesn't do any leetcode but knows the fundamentals and can sythesize past knowledge well enough to answer a new question)
Now in a vaccuum, my takeaway from someone who doesn't pass a leetcode question is that they are more likely to not be either of those (given no other information about them). In my opinion, solving at least one leetcode easy - medium question (maybe with some direction from the interviewer) should be the standard for any role where you need to code.
And realistically, companies index less on leetcode skill as you become more senior or apply to more niche roles. And plenty of companies out there have bug squash rounds, system design, behaviorals, take homes, trivia, background specific questions, etc. Leetcode is usually not the be all end all for hires above entry level. Leetcode is not meant to magically select for the best engineers. Its simply another signal for the hiring committee to use.
[+] [-] FL33TW00D|1 year ago|reply
It's been proven many times that the severity of an initiation ceremony significantly boosts the commitment of those admitted to the group.
[+] [-] resource_waste|1 year ago|reply
What is a better capitalistic company hiring programmers:
>Lots of smart similar people who believe in correct answers
>Lots of random skilled people
If you said the latter, you are idealistic and your opinion genuinely doesnt matter. Nature will replace you with someone smarter and realistic.
[+] [-] Kichererbsen|1 year ago|reply
[+] [-] throwaway346434|1 year ago|reply
The (best) seniors just use a library. The good candidates roll their own, but can explain the tradeoffs. The juniors get the test to pass and stop.
[+] [-] codegladiator|1 year ago|reply
https://github.com/emilybache/GildedRose-Refactoring-Kata
in their favorite language. Has been a very effective filter
[+] [-] koliber|1 year ago|reply
It's kind of like math. If you need to multiply 562 * 1041, you should use a calculator. If you need to reach for a calculator to tell me how much 3 * 7 is, I will doubt that you are an expert.
Many companies overdo the leetcode interviews. A live coding interview that shows that a person can do array manipulation, implement flow control, and use basic data structures shows me that you have the muscle memory that only comes with experience. If you need to study graph-traversal algorithms in order to pass, it's probably too leet.
[+] [-] begueradj|1 year ago|reply
A freshly graduate student has more chance to still know this or that algorithm, and prepare for that.
An old/experienced developer has dealt with plenty of real world complex problems. So much that his attention is absorbed by them, not by what is the best way to search for an element in a tree.
[+] [-] JKCalhoun|1 year ago|reply
I think more likely though are the accidental favoritism in the industry where engineers submit resumes of other engineers they know who are looking for a job who, surprise, are also white males.
I don't believe it is either racist or sexist however. It's just "who people know". Nonetheless, you're going to build a hive-minded team if you don't go out of your way to break these patterns.
Perhaps similarly leetcode interviews come about from engineers who were leetcode interviewed. Again, no need to jump to ageism as the cause.
(And if anything I think it may have turned a corner where the older devs may have more experience with interesting algorithms that, I don't know, might not be taught any longer in CS?)
[+] [-] slavapestov|1 year ago|reply
[+] [-] pprotas|1 year ago|reply
[+] [-] delegate|1 year ago|reply
All it takes is a short problem to solve at home, which can be easily googled and one hour architecture interview, where we discuss the technical architecture of a hypothetical 'real world' service.
It takes about 20 minutes to determine if the candidate has the experience with the technologies listed in the resume. Little experience is not necessarily a show stopper.
True that the language we hire for (Clojure) filters out a lot of people ahead of time, but knowing the language is not exactly what I look for..
What I look for is 'passion' - does the candidate love programming and can the candidate articulate technical issues with ease.
The other question I try to answer - will the candidate enjoy working in our team and will we enjoy working with him/her.
Smart people will shine in a certain way, even if they bomb specific questions - they have an opinion, they try, they ask the right questions.
I'd be sad if we missed on some of the people in our team because of automated (inhuman) puzzle interviews.
We're not looking for a problem solving machine, we're looking for a partner to create something great together, someone who shares our passion for hacking and someone who we'd love to work with.
I share TFA's opinion that leetcode-style interviews are not the way to go and I hope the industry comes back around and focuses on the human side more.
[+] [-] willtemperley|1 year ago|reply
[+] [-] ojhughes|1 year ago|reply
Feeling a bit triggered by this - but also curious how you escaped :)
[+] [-] was_in_amazon|1 year ago|reply
[+] [-] SSchick|1 year ago|reply
Idk anymore either and I refuse to conduct these interviews. I generally prefer somewhat realistic problems that are multi-disciplenary but have ties to real world applications related to the role.
[+] [-] stavros|1 year ago|reply
[+] [-] swuecho|1 year ago|reply
I have just went through one interview that have 4 rounds.
1. half hour talk 2. 2 hours coding for several crud api. 3. system design project ( I spend 2 days on it. they told I have about a week on it) 4. another half hours with CTO.
and then got rejected. (The interviewers does not bother to send a reject letter. I asked them they told me the position is closed).
[+] [-] pkos98|1 year ago|reply
All the talk about diversity, but no diversity of thought. Only LC chasers. I genuinely believe this decreases innovation massively.
[+] [-] kristopolous|1 year ago|reply
[+] [-] resource_waste|1 year ago|reply
Nice belief, but good luck proving it.
I imagine the people grinding LC are harder working/more innovative than people who watched TV instead.
[+] [-] innocentoldguy|1 year ago|reply
I quit doing engineering work for companies, but back when I did, I'd take some complex code I'd written to interviews. I tell the interviewers that I'm happy to step through my code and explain it during the interview, but that I wasn't interested in wasting hours of my weekend writing a werpderzle or answering gotcha questions.
Some companies agreed and I ended up working for them and some companies didn't, so I'd end the interview. In my experience, companies that over-complicate the interview process also over-complicate their day-to-day work, and I don't have any interest in working in that sort of environment.
[+] [-] palata|1 year ago|reply
Interviewers tend to forget that they are in a dominant position: they have nothing to lose, they are the ones who take the decision, and they are the ones who chose the questions. I have been in such interviews where I completely failed, but where I am absolutely certain that I could have made the interviewer fail as well were the roles inverted. It feels a bit hypocritical to fail someone who did not actually do worse than you would have done...
[+] [-] 6510|1 year ago|reply
Not specifically that but give it your own twist.
If they are confused remind them that getting along with people and fitting the team is at least as important as the ability to do work. The work is the least of your concern. It will probably involve dusting off some old skills and learning some new things.
[+] [-] rckt|1 year ago|reply
From my experience you can say it's going to be good or bad right from the start. 5 minutes into an interview and you can already see where's it's going to end.
I don't understand when companies try to give test assignments to senior devs. Even if your GitHub or whatever profile is not rich with projects you can evaluate person's professional level during the conversation.
And I also hate stupid riddles during the interviews. But there was an interesting case. I got a couple of verbal puzzles that I should have solved right at that time and I failed. But I got the job anyway. So I guess if people in the company are common sense driven it helps to choose hiring strategies that work for both sides.
[+] [-] alentred|1 year ago|reply
> I don't understand when companies try to give test assignments to senior developers.
I think this is perfectly valid, though. When I interview candidates, I start with the conversation and I can tell you that more often than not it goes very well: talking about software design, architecture, what they think about various frameworks, etc.
But you would be surprised how many people can talk their way through the interview, and then get totally blocked on a simple syntax error in the code. (Stress being accounted for).
I agree, though, that the questions should be fairly designed before the interview and be consistent with the level of the expertise expected for the position. I would never ask a senior developer to implement a FizzBuzz. We'd rather sketch an architecture for some piece of software with some specific constraints, discuss the choices of the language and libraries and argument them, etc. And yes, eventually code something: just sketch some core domain logic. I would never hire a software developer, whatever the level, without seeing them coding first.
[+] [-] mrbombastic|1 year ago|reply
[+] [-] DEADMINCE|1 year ago|reply
It doesn't help that so many companies think they have slick ways to root out better qualified people when most are just a waste of time.