by nelsonfigueroa on 6/4/24, 6:47 AM with 603 comments
by SilverBirch on 6/4/24, 7:20 AM
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.
by yreg on 6/4/24, 10:02 AM
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.
by dinobones on 6/4/24, 7:11 AM
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.
by CSMastermind on 6/4/24, 7:31 AM
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.
by apples_oranges on 6/4/24, 7:24 AM
by mihaitodor on 6/4/24, 12:30 PM
> 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.
by boshalfoshal on 6/4/24, 7:16 AM
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.
by FL33TW00D on 6/4/24, 7:23 AM
It's been proven many times that the severity of an initiation ceremony significantly boosts the commitment of those admitted to the group.
by Kichererbsen on 6/4/24, 7:16 AM
by koliber on 6/4/24, 7:41 AM
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.
by begueradj on 6/4/24, 10:47 AM
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.
by delegate on 6/4/24, 8:40 AM
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.
by willtemperley on 6/4/24, 7:42 AM
by SSchick on 6/4/24, 7:10 AM
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.
by swuecho on 6/4/24, 7:23 AM
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).
by pkos98 on 6/4/24, 7:57 AM
All the talk about diversity, but no diversity of thought. Only LC chasers. I genuinely believe this decreases innovation massively.
by innocentoldguy on 6/4/24, 7:23 AM
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.
by palata on 6/4/24, 10:52 AM
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...
by rckt on 6/4/24, 9:05 AM
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.
by mrbombastic on 6/4/24, 1:15 PM
by gigatexal on 6/4/24, 8:08 AM
Of course I don’t know the replacement I just know I loathe doing these things and would rather learn more about what the day to day would be like, what’s the team like, the manager, the growth potential, etc. I am all proving my skills but can I do so in an environment that is more congruent with my actual work?
by andrewstuart on 6/4/24, 8:28 AM
BUT one of the things I've pretty much never needed is leetcode.
That says something about recruiting processes that evaluate you on your leetcode.
If you can't come up with an interview proecss that evaluates a developer against the bajllion things that developers have to do, then it says YOU the interviewer don't know what you are doing.
I think leetcode interviews are lack of imagination on the part of the interviewer.
Being good at programming does not make you good at assessing the capabilities of other programmers.
by surfingdino on 6/4/24, 8:28 AM
Exactly. I refuse to do them. Oh, your business is solving basic problems in computer science? I though you were an e-commerce platform that needed cleaning up your APIs and moving to a more efficient DB?
by weatherlite on 6/4/24, 8:07 AM
by EdgarVerona on 6/7/24, 2:37 PM
The distinction is subtle, but important in terms of what is needed for the role.
Most software engineers are going to be asked to solve problems and actively avoid recreating algorithms and libraries from scratch while doing so: it represents added time, risk of bugs, and complexity to do so for minimal gain in many cases.
For most software jobs, the more important role when it comes to algorithms is in choosing which algorithm is most relevant to a task, not implementing it from scratch. To do so is often wasting your companies' time.
It's unpopular, but most software engineering (including most of my own career) is closer to a plumber than a scientist. And you know what? We provide a lot of value as plumbers, as unsexy as it sounds.
It's for these reasons that I think leetcode is an unsuitable test for most software engineering positions.
by jsnk on 6/4/24, 7:17 AM
I too used to hate leetcode questions, but after conducting 100s of interviews as an interviewer, leetcode style questions are the best way to test intelligence and coding skills ive found in general.
However, leetcoding interviews must be paired with system design and topgrading in order to have balanced interviews. Leetcoding alone is incomplete but i find it essential.
by hcrean on 6/4/24, 11:32 AM
by isoprophlex on 6/4/24, 7:09 AM
by iLoveOncall on 6/4/24, 7:55 AM
I work at a FAANG but if I had another interviewer I probably wouldn't.
For me it's the same process as the green card lottery: apply to your target company every year / six months (cooldown period) until you eventually get it.
by fvdessen on 6/4/24, 7:13 AM
by ergonaught on 6/4/24, 12:57 PM
The industry only does it because it FEELS LIKE it tells you something relevant, and it FEELS LIKE you and your business must be important if this is how you interview people.
by kentrado on 6/4/24, 7:12 AM
Makes sense, he is older and has two daughters.
I even considered leaving the field myself.
by dicroce on 6/4/24, 11:45 AM
Also, a lot of the time it feels like the answer to most leetcode problem is some sort of trick.... and if you think of it you are golden and if you don't it sucks to be you. Most of the time I'm trying to write code that is NOT tricky... So in some ways I think the job itself will train you to seek simple clean solutions as opposed to tricks.
by JohnKemeny on 6/4/24, 7:27 AM
It's a kind of audition.
by physicsguy on 6/4/24, 8:16 AM
I’ve worked mainly on scientific software which requires a mix of domain knowledge and programming skills. I doubt many people who I’ve worked with would pass leetcode without spending a lot of time studying, because they primarily come from Physics/Engineering backgrounds, but that doesn’t mean that they are not good software engineers, that the software they’re writing is not performant, or that they can’t offer anything valuable.
by TrackerFF on 6/4/24, 12:20 PM
At some point, you end up with questions that either lucky people or savants are able to answer. Yes, that might be an exaggeration, but it's not too far off the mark.
Applicants discovered, long ago, that if you simply grind every questions on LC - you will likely get asked some of those questions wherever you interview.
Companies fight back by asking harder questions. Before you know it, a standard interview consists of LC hard questions.
And with the advent of LLMs, it is even harder to sniff out candidates if the interviews are remote.
At some point you'll just have to re-do the whole process, and built it up from scratch.
by pjmorris on 6/4/24, 12:24 PM
Their consensus opinion was that a 'work sample test' was the most reliable means of assessing whether potential hire would be a good fit. Bring the person in and pay them to work with you, in your environment, on tasks parallel to what is needed, for a short period (anywhere from half a day to a consulting engagement) and base your decision on what you learn.
It is a really strong positive signal about a company if you see them doing this.
by drones on 6/4/24, 8:10 AM
by m0llusk on 6/4/24, 10:19 AM
by spacecadet on 6/4/24, 10:48 AM
Im going to randomly and silently draw from one of 3 topics that I understand, but nothing that I don't and would need to collaborate with you to solve. It must be something I have memorized so not to risk looking less smart than the interviewee. Good we have now hired the 10,000th copy of me, the company can now continue to produce the SAME garbage across 10,000 people. I have succeeded and can now be promoted to level 5.5 and 2/5th.
by mbravorus on 6/4/24, 4:19 PM
Which leads to the current state of IT/high-tech recruitment where things are, in most cases, so mismatched between ends and means, it's not even funny. It might be very entertaining to look at how people hiring for senior+ infrastructure roles (SRE, DevOps, what have you) try to use "leetcode" style stages - unless you are a desperate job seeker. (and no, I don't think an SRE or cloud infra engineer shouldn't be able to code, I just don't think leetcode-style tests are at all relevant as tests for that)
And at the end of the day you end up with an engineering org where in the intake funnel they ask you to [competitively] solve variants of the knapsack problem, but once in, you end up solving it in the form of "how do I slice and dice a set of tickets within a completely irrelevant, misaligned and misunderstood "Agile" model so that can best pack SPs into a sprint and also do some actually useful work".
by zhvihti on 6/4/24, 7:37 AM
* Available time to prepare (esp. when holding a job) = available to work long hours
* Self-motivate themselves for a long time (esp. to do such bullshit work)
* Mental capacity to remember all the material (esp. given its useless outside of the interview loop)
The flip of the coin are people who can't put in the time due to e.g. family obligations, don't have the motivation, or don't have the mental capacity.
by chmod775 on 6/4/24, 11:08 AM
But if you have any sort of track record (previous employment/projects you can talk about, active github account), they're just insulting. They shouldn't be wasting your time if they could just have a look at the things you accomplished.
That there's companies who make all interviewees take them just means there's not enough competent software developers with sufficient self respect to just refuse that kind of nonsense.
by CSDude on 6/4/24, 7:25 AM
Not all of us get a chance to work with a great candidate pool. So, whenever someone fails to provide a solution given an integer list, find the pairs that sum is equal to N, I don't care how many technologies they have worked with or how well they can talk about it, I don't feel comfortable working with them.
by alkenes on 6/4/24, 11:48 AM
by js8 on 6/4/24, 11:26 AM
by underdeserver on 6/4/24, 8:14 AM
I always thought that while Leetcode interviews are problematic because they don't represent most of the work you're going to do, they're much better than interviews where you're expected to namedrop specific API functions or design patterns.
by fzeroracer on 6/4/24, 7:14 AM
by Pelayu on 6/4/24, 8:55 AM
Leetcode-style any day, over that.
by upmind on 6/4/24, 10:24 AM
by oooyay on 6/5/24, 12:52 AM
That creates variety in the question bank, standardizes evaluation, and will only encourage engineers who really want to work on your stack and product combination.
by osy on 6/4/24, 7:18 AM
by KoftaBob on 6/4/24, 11:58 AM
It's much closer to day to day work than code challenges are, it doesn't involve the stress factor of an interviewer staring at you while you work on a leetcode, and you can have a followup technical interview to discuss the take-home in more detail.
The most recent take-home experience like this that I saw was with Clipboard health, and I thought it was a great experience. If I remember correctly, they used Woven Teams to automate the process.
by LASR on 6/4/24, 7:15 AM
Everyone knows how pointless it is. But it’s become more like paying the tax.
For the record, I typically give away the a-ha moment early on and see how the candidate is able to take the suggestion and work through a problem with me.
by forrestthewoods on 6/4/24, 7:51 AM
This is irrelevant. No interview can accurately reflect actual job behaviors.
Job interviews are a proxy. Either they produce false positives/negatives or they don’t. It doesn’t matter that the proxy isn’t 1:1 with day-to-day.
I sympathize with job seekers dealing with leet code interviews. But I’m somewhat over the million blog posts that say the same thing. I’d be much more interested in hearing from the other side. Hiring is a nigh impossible task. People rarely share reproducible alternatives. Only hand wavey gut checks. It’s unfortunate this is the best we’ve come up with. Hiring is hard!
by dkdbejwi383 on 6/4/24, 11:44 AM
luckily, I have experience as a programmer and in a previous career, and have so far managed to mostly avoid it as there are enough companies where I am that I’ve been hired elsewhere. But it does make me wonder if I’ve either missed good opportunities, or am limiting myself for the future.
by lordnacho on 6/4/24, 1:22 PM
How often do you find an employee who if you'd just asked them an LC, they would not have gotten the job that they have proven themselves incapable of?
The times I've met a programmer that we shouldn't have hired, it could not have been detected by LC. This has tended to be things like "guy does not want to work on this problem" or "this guy is suggesting things that are obviously bad designs, and doing it with an aggressive style". Rather than "if only we'd asked him to implement Dijkstra we would have found out and not hired him".
LC also doesn't ask what you want to know. I don't need to know whether you can solve the Towers of Hanoi. I need to know that if there's a problem we need to solve, and it is a disguised ToH problem, you will recognize that there's an algo to be found, you will eventually find it's this one, and you will eventually find the solution and code it up in a sensible way that helps the team in the future.
LC problems tend to be too short to decide whether someone actually has the skill that I really value, which I guess is gumption. We have a codebase that's become crusty over time, will you take the initiative to clean it up, or will you just solve the little LCs that present themselves and add that to the spaghetti?
The interview form that's worked for me over the last 20 years is simply to have a long technical discussion, meandering across a bunch of technologies and problems. You can't prepare for it, and you can't waste your time preparing for it. Even if you say you touched a bunch of stuff, when you run out of opinions, I will know the depth of your experience. If you have an opinion, you will also know what the orthodoxy is on that area, and you can explain why you agree or disagree. If you are disinterested, it will be clear.
Now of course this isn't going to satisfy people who want something they can call standardized. Maybe a pair of twins will walk in with the same skillset, and one of them veers down one path and the other down another, so that the conversations have different questions. But I would wager that I'd find the same result.
by mean_pigeon on 6/12/24, 3:27 AM
by perrygeo on 6/4/24, 12:15 PM
Does this company value grinding at solved problems, rather than actually solving new and interesting ones? That's a dead end. I'd rather talk about how I spent my time building real stuff in prod. That's generally how I respond to leet code challenges, pointing out the existing libraries and tools that already do it and discussing their tradeoffs. Pretty good way to find out they're looking for an actual engineer or a code monkey.
by jgoodknight on 6/7/24, 3:15 PM
by sensanaty on 6/4/24, 11:08 AM
They then ruined it by still having a leetcode style interview afterwards which I found monumentally stupid, but oh well.
by praptak on 6/4/24, 7:45 AM
"But today Spolsky has mixed feelings about his guide — and its impacts on hiring in tech. “So this idea that you’re going to have a rigorous interview where you bring people in on the whiteboard and you say, ‘Show me how to copy a string while deleting the letter Q. In C, on the whiteboard.’ That was a big step up, I think, from, you know, ‘What college did you go to and who do you know and where did you work?’” [...]
“It’s a great way to hire 10 developers. It’s a very bad way to get developers in a scarce environment where you’re trying to find the people that might be good.”
A lot of good programmers end up getting rejected — while, even worse, companies end up hiring people who are good at passing tests, but underperform in the real world. “I think that method is definitely state-of-the-art 1995. It was even good for 2005. For 2018, I think you need a better system, and I think it’s probably going to be more like an apprenticeship or an internship, where you bring people on with a much easier filter at the beginning. And you hire them kind of on an experimental basis or on a training basis, and then you have to sort of see what they can do in the first month or two.”
Article: https://thenewstack.io/joel-spolsky-on-stack-overflow-inclus...
HN discussion thereof: https://news.ycombinator.com/item?id=39748546
by bradleyjg on 6/4/24, 10:57 AM
Neither does anyone else. Everything else we’ve come up with either has worse issues or is extremely expensive to operate.
by clarionbell on 6/4/24, 8:47 AM
Maybe they are right. After all, I'm not an expert on the matter of recruitment. But from my experience, I felt far better when the process was not "personal", even if I didn't get accepted in the end.
by bilsbie on 6/4/24, 11:20 AM
by treprinum on 6/4/24, 7:47 AM
by dvt on 6/4/24, 7:15 AM
The solution is simple: refuse to do those interviews. I have, and I wish more engineers would. It's one of my screening questions: do you do whiteboard style quiz/brainteaser interviews? If the answer is affirmative, I politely (and sometimes impolitely) decline.
I've written a book, edited another, contributed to plenty of open source, including Golang, started a few companies, and been around the block. I'm more than happy with a take-home or with going over code I've previously written, but doing leetcode in a "live coding session"? I'm good, thanks.
For FAANG and other huge companies, it's probably a decent heuristic (though I doubt even that), but smaller startups or non-tech companies doing this nonsense is a clear red flag. I mean, there's entire books dedicated to gaming the software engineering interview. The signal-to-noise ratio is probably so terrible, it's essentially just professional hazing at this point.
by concordDance on 6/4/24, 8:17 AM
by AYBABTME on 6/4/24, 12:12 PM
by jWhick on 6/4/24, 9:59 AM
by poisonborz on 6/4/24, 7:39 AM
by badgersnake on 6/4/24, 8:37 AM
by paulus_magnus2 on 6/4/24, 9:22 AM
by beej71 on 6/4/24, 1:46 PM
by kbar13 on 6/4/24, 7:14 AM
whether or not you succeed as an engineer generally falls down to whether or not you know how to code (pretty much anyone is good enough at this for most jobs), can you communicate effectively (covered during the behavioral portions of interviews), and do you work hard.
honestly i think it sucks, but in comparison we're pretty lucky. i think a lot of people in this world would be happy to grind a few hours a day for a couple of months to get paid 250k+ base
by kiney on 6/4/24, 1:31 PM
by NiagaraThistle on 6/4/24, 11:06 AM
I'm 45, focus on Web development, have worked in-house on teams building ecomm carts/solutions for multi-million dollar per ear local companies, in design agencies focusing on custom $100k or templated $5k Wordpress websites, and have freelanced for everything in-between.
During COVID lockdown, I got burnt out at my existing employer, resigned, and took several months of. When I started looking for work again, one potential employer was a Wordpress 'freelance' company that gave me a LC test as a second round interview.
I BOMBED - like a 27%. I've been building sites and web applications for 15+ years and had zero idea what I was even being asked in any of the 3 questions on the 'test'. The company ended the interview process and advised I study Leet Code for 1 month and come back to re-test since my experience was outstanding for what they were looking for.
I did and got an even WORSE score: 13%. I spent way to much time on trying to cram useless (for my daily work) programming techniques to pass a useless interview test when I was told I had the experience they wanted - I've built custom WP solutions/themes/plugins since wordpress first rolled out.
TLDR: With 15+ years experieince in Web development, I still couldn't score higher than a 27% on a LeetCode test and got halted in the interview process for a position I was told I was WELL qualified for.
LeetCode tests for non-overly-technical positions is awful.
by bluGill on 6/4/24, 1:34 PM
by wantedtoask on 6/4/24, 9:35 AM
We ask candidate to pick any OS project out of few dozen related their skillset. There are predefined feature request/improvement we got prepared for each one. I've been experimentimg with it, and it feels more 'natural'.
by surgical_fire on 6/4/24, 11:06 AM
They obviously are useless to measure how good a candidate is, but that is not my problem. I didn't pick the song, I just have to dance to it.
by makerofthings on 6/4/24, 11:45 AM
by stephenblum on 6/5/24, 5:43 PM
by jakubmazanec on 6/4/24, 11:37 AM
by alexey-salmin on 6/4/24, 7:24 AM
> But yet, these interviews quiz me on things that I can easily Google that I may not know off the top of my head. It’s absurd.
I don't work at Google so I'm lucky to have freedom in the way I interview engineers and usually I try to squeeze out the quiz aspect as much as possible.
If a candidate doesn't know the algorithm for a given problem and can't quickly come up with one, I usually proceed to give a detailed explanation for it. In the end the task is reduced to "write between 6 and 10 lines of code that do X in your favorite language" and yet a majority (80-90%) of inbound candidates for software engineering fail at it (for non-inbound sources a picture can be very different of course).
Contrary to a common view, I believe that this approach actually imitates my daily interactions with a developer quite well and the correlation between interview performance and job performance is very strong in my experience.
And interestingly I've seen many people who shine in oral interviews (tell me about your experience) and then fail to produce any code at all, both during the interview and at work. So even if I wanted a good alternative approach to hiring of engineers I haven't seen it so far.
by guess_do_say on 6/5/24, 9:12 AM
by guardian5x on 6/4/24, 7:17 AM
by rascul on 6/4/24, 1:16 PM
by slavapestov on 6/4/24, 12:20 PM
by ThinkBeat on 6/4/24, 12:44 PM
But I want to share a couple of thoughts.
If these interviews in general, follow a form of template as to what they contain, what to expect, how answers should be presented, then studying it, while time consuming is not that hard.
It can function as a form of "proof of work". That you took the time to prepare yourself for the interview will be points in your favor. Like putting on some nice clothes and brushing your hair. and putting together nice CV.
The second part is to perform under stress. I hate this part of modern interview processes. They want to give you something difficult, then spinkle with some rudeness and abrasive comments.
Will the candidate work under pressure or not?
Coming from the consulting world, perhaps that is more common in that sector than others.
by Crier1002 on 6/4/24, 8:33 AM
by SomeoneFromCA on 6/4/24, 9:50 AM
by moomin on 6/4/24, 8:09 AM
Would I recommend it if there weren’t so many leetcode interviews out there? No, I wouldn’t. It’s not a useful skill for actual programming; it won’t make you smarter. It will, however, establish that you have a lifestyle that affords you the kind of free time to devote to it.
So yeah, I’ll happily jump through these hoops. Honestly, I’m the personality type that finds it fun. But it’s a lousy way to assess my abilities as a dev.
by nh23423fefe on 6/4/24, 5:16 PM
> Kuberentes
by radres on 6/4/24, 7:08 AM
It is really unlikely, given a leetcode hard level problem to solve within 25-35 minutes and you can google your way out of it unless you are googling for the solution.
by graynk on 6/4/24, 7:16 AM
by peter_l_downs on 6/4/24, 12:51 PM
by johnnyAghands on 6/6/24, 3:43 AM
Some of the worst interviews I've had I've felt like I was a lab rat, just being evaluated for specific traits/reactions. The worst part is, like you said, every Tom, Dick, and Henry does this, its somehow become some kind of lazy industry standard hiring practice, hence the explosion of these interview aid services. Some people will argue it serves a purpose, but I really don't see how. It's like memorizing an answer sheet and doing well on a test. Is that really the type of problem solving you're looking for? Don't get me wrong, I do think its important to understand foundational concepts and algorithims, but like.. it's also the first thing thats abstracted away for good reason in the real world. Anyways its shit.
The worst part is even with my experience I still feel like shit after these calls though I should know better.
by NalNezumi on 6/4/24, 7:28 AM
A while ago I posted a Ask HN question about the usage of Pseudo-IQ test which is very common in Swedish interview process. Pseudo-IQ test in the sense that it is almost always just Raven Matrix test + maybe math or personality test. I tend to score pretty well on those tests and it takes maybe 1h tops, but it's annoying and stressful either way, especially knowing what ideological foundation it comes from....
Seems like the answer from the Ask HN point towards that those tests used to be common in US/SV/Software position interviews too, but it then got kinda replaced by Leetcode-style interview.
And sure, having a person staring at you commanding you to only use your brain to solve a toy problem is definitely not how you work. But it in combination of a bit of back-n-fort traditional interviewing is definitely more informative to the employee (and fair) than some pseudo-IQ test.
I just hate when Leetcode is used as *the first screening* it's such an asshole move that show high level of disrespect towards the applicants time. Maybe you can get away with as FAANG, but small companies that do this to me just signal extreme arrogant (or delusional/dysfunctional) HR or C-suite.
The best coding interview I've had is just the format "You've received a PR from a junior dev. The code compiles without error and pass the unit test. Would you pass/reject this PR and motivate why" and it often requires a better understanding of the language (such as difference between modern C++ and C++12)
by mxsjoberg on 6/4/24, 7:55 AM
be the change and so on
by nikolayasdf123 on 6/4/24, 7:58 AM
by eunos on 6/4/24, 9:54 AM
by the_black_hand on 6/4/24, 8:42 AM
by eschneider on 6/4/24, 9:42 AM
I mean, is it a great way for companies to hire? No, not really. Is it how many companies hire? Yes. Do I occasionally learn a few things while doing this sorta prep? Occasionally. All-in-all, the expected value from a bit of prep seems worth it.
by the_black_hand on 6/4/24, 8:42 AM
by dispirited on 6/4/24, 8:48 AM
by zabzonk on 6/4/24, 7:55 AM
them: implement reversing a linked list
me: your company spends a lot of time reversing linked lists?
by emodendroket on 6/4/24, 7:15 AM
> I don’t really have a solution to this problem, I just know it’s a problem.
Yeah, exactly. You don't have a better answer and nobody else does either.
by gamebak on 6/4/24, 7:48 AM
Usually, the computing part isn't the part that prevents a business from scaling more (servers are cheap).
by fHr on 6/4/24, 8:41 AM
by IshKebab on 6/4/24, 12:56 PM
I had one job working on a compiler that fairly regularly had leetcode-style algorithms problems, even novel ones.
But yeah, most don't.
by racketprogram on 6/4/24, 7:17 AM
by damontal on 6/4/24, 12:12 PM
by 451mov on 6/4/24, 7:07 AM
by nikolayasdf123 on 6/4/24, 7:58 AM
by 414owen on 6/4/24, 7:11 AM
by caff31ne on 6/4/24, 1:06 PM