return to table of content

I am sick of LeetCode-style interviews

dinobones
162 replies
11h17m

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.

emodendroket
47 replies
11h12m

I'm sure anyone determined to do so can act unfairly regardless of what process is in place, but the fact that there is a standardized test in my mind does the opposite and makes the process much fairer. Assuming a fair-minded interviewer, the process gives a chance to a candidate whose resume may have less vaunted names on it to demonstrate their skill. I'm quite sure that I'd never have had some of the opportunities I have, not having a CS degree, if it weren't for whiteboarding interviews. I can't imagine any possible process that would thwart interviewers intentionally subverting it to hire their friends.

369548684892826
27 replies
10h53m

the fact that there is a standardized test in my mind does the opposite and makes the process much fairer

The problem isn't standardized tests, it's that leetcode questions are about having the time to have learnt the answer beforehand, rather than raw ability for problem solving.

jonkho
12 replies
10h10m

That’s not true. In any discipline when confronted with a test there are two strategies: brute memorization of the question/answers, or developing the skills to tackle the problem dynamically. You cannot categorically claim that LC tests are largely memorization tests rather than raw problem-solving skills. That is just the approach you are capable of taking. Not being able to see up the mountain doesn’t imply there are no climbers above you.

KaiserPro
8 replies
8h0m

You cannot categorically claim that LC tests are largely memorization tests rather than raw problem-solving skills

If that were the case then a normal, well accomplished software engineer shouldn't need to "grind" leetcode to pass an interview.

its just a cargo cult. Getting someone to do a code review is a much much better test of skill:

Do they ask questions?

are they kind in their assertions?

At what point do they go "I don't know"?

Do they concentrate on style or substance?

do they raise an issue with a lack of comments?

do they ask why the description of the PR is so vague?

When they get a push back, are they aggressive?

All of those are much better tests than "rewrite a thing that a library would do for you already"

hackinthebochs
7 replies
6h59m

If that were the case then a normal, well accomplished software engineer shouldn't need to "grind" leetcode to pass an interview.

No, what this shows is that the skill range for accomplished professional software devs is absolutely massive. What these companies want is to find the tail end of this very wide distribution. Leetcode interviews do a decent job at this. If you have been coding for a decade and can't do leetcode mediums with almost no prep, and hards with a moderate refresher on data structures, then you're simply not the in the right tail of the skill distribution and they don't want you. This is what so many in our industry can't accept: you're just not talented enough to earn a FAANG job.

KaiserPro
3 replies
5h36m

Leetcode interviews do a decent job at this.

I mean it doesn't, because I'm at a FAANG, At a FAANG you are infantalised from the very start, sure you passed a very difficult interview where you have to balance a binary tree efficiently as possible. But you're going to use none of those skills here.

what you actually end up doing is copy/pasting some random code you found using internal code search, because the sensible way of doing it can't happen as that would involve porting a thirdparty library, and doing all the procedural work that follows.

so you hack some shit together, ship out out and hope that it doesn't break. You then decommission the nasty hack you shipped last year and claim credit for innovating. Is your product not hitting the right metrics? loosing users? doesn't matter, so long as the super boss is happy that you've hammered in the REST API for the stupid AI interface, you're not going to get fired.

In a startup/small company, if you fuck up, the whole place is going under. Need metrics? you'll need to find a small, cheap and effective system.

Here, we just record then entire world and then throw hundreds of thousands of machines at it to make a vaguly SQL interface. Don't worry about normalising your data, or packing it efficiently just make a 72 column table, and fill it full of random JSON shit. Need to alter a metrics? just add a new column.

In short, don't praise or assume that FAANGs are any good at anything other than making money. They are effectively a high budget marvel movie, Sure they have a big set, but most of it is held together with tape and labour. Look round the side and you'll see its all wood, glue and gaffer tape.

hackinthebochs
2 replies
5h20m

But you're going to use none of those skills here.

FAANGs want the top .1% of developers, they don't necessarily need them for most roles. But the point is to hire developers that you could put into any role in the company within reason and have them be successful. 99% of development work at a FAANG is pretty unexceptional and doesn't require exceptional developers. They hire for that exceptional 1%.

KaiserPro
1 replies
4h50m

FAANGs want the top .1% of developers,

FAANGS want a load of loyal, naive people who are willing to work loads of overtime and not ask too many questions. Who better than posh kids from great universities who haven't quite figured out that life isn't a meritocracy yet!?

Sure they also want the top 0.1%, but they have a different interview track. Do you think all those OpenAI engineers that were going to follow Altman were asked to do leetcode?

hackinthebochs
0 replies
4h3m

Do you think all those OpenAI engineers that were going to follow Altman were asked to do leetcode?

I don't know about OpenAI specifically, but I have heard of interviews at other top ML research positions were partly based on leetcode problems.

throwaway7ahgb
1 replies
5h48m

FWIW I sort of agree with you.

Background:

I'm in a FAANG type company now, a YC company, 3000+ engineers. I'm a Staff SWE with 20+ years of experience (ECE degree) and make $600k+ per year. I've went through the promo cycle here (it sucks).

I can't do any leet hards and can do leet mediums after studying. Some easy's take me a couple of tries. I usually do very poorly in interview coding exercises.

** throwaway , main account is 10+ years old.

6510
0 replies
2h49m

Curious, would you say FAANG offers the right challenges to stay in the 0.1% or 1% if one started out there? Are they actually in the right place to grow?

DragonStrength
0 replies
6h27m

No, these engineers at FAANG companies could not solve those problems cold without having been taught how. I have worked at two, which is how I know. I have never seen a question in an interview I haven’t seen before. Many of these questions went unsolved for decades in the industry, so no, these engineers, who mostly aren’t DSA experts but distributed computing experts, could not solve them cold. I also saw how interviewers used questions to re-enforce their own biases on university, gender, or home country in these interviews.

johnnyanmac
1 replies
7h36m

You cannot categorically claim that LC tests are largely memorization tests rather than raw problem-solving skills.

Sure I can. By the time you get to Leetcode hard, these aren't just "can you derive the answer". The questions by design take 45+ minutes and have some weird quirk in it that is nominally related to the core concept being tested. These aren't necessarily meant to be done on the fly during an interview period.

Not being able to see up the mountain doesn’t imply there are no climbers above you.

a better analogy is that youre on a road and you see a freeway above you. The people above you aren't "better", they are simply on another road, to another destination. But they aren't necessarily worse either. They could be on their way to a dead end job or could be a billionaire CEO.

That is to say, it's useless comparing yourself to other people you don't know. Everyone has their story.

jonkho
0 replies
2h29m

Thank you. You just proved my point that “categorically LC is not largely memorization” by reinforcing that only in specific cases in some specific levels that you do need some specific domain knowledge.

Tade0
0 replies
9h45m

That's exactly true.

LC tests typically copy problems from the university the interviewer graduated from. College programs differ, so this is really a case of what you were introduced to.

There's a fairly popular online LC test company in my corner of the world which was formed by graduates and lecturers from a certain university and they started out by just giving the problems from the curriculum. Result was heavy bias in favour of students and alumni of that university.

koolba
9 replies
10h9m

The problem isn't standardized tests, it's that leetcode questions are about having the time to have learnt the answer beforehand, rather than raw ability for problem solving.

This sounds like you want to penalize students who studied for the exams. Or at least not reward them.

Like all interview formats, it’s a proxy for understanding if the prospect would be able to get the work done and be a good fit with the rest of the team. I’d say it’s a pretty good proxy for work ethic at crunch time as well.

If your complaint is that a normal person wouldn’t have the time to study these things in detail, why would a company want to hire someone who has external obligations?

mvdtnz
3 replies
9h45m

If your complaint is that a normal person wouldn’t have the time to study these things in detail, why would a company want to hire someone who has external obligations?

External obligations like full time employment and a family?

koolba
2 replies
9h40m

Yes exactly. All things being equal, I’d rather higher someone who’s going to dedicate his entire life to the soul crushing work he will be assigned.

myspy
0 replies
7h59m

Wow, look guys I've found the fool.

azangru
0 replies
6h3m

I don't disagree; but why does the work need to be soul-crushing?

John23832
1 replies
6h38m

Why should a job be an exam? For someone who has worked at both FAANGS and startup, I've never found a job that remotely matches a leetcode problem.

Most companies are building products anyway.

bluGill
0 replies
5h10m

The only value in leetcode is you should be able to solve a couple in a short time and thus prove you are least know something about writing code. We use them as an interview prescreen because once in a while someone seems like a good person we would like to work with, but we have no clue after the interview if they can really code.

We had one person who worked on [censored] 20 years ago, then was manager of [non-programmers, rest censored] - now wants to get back into coding - can this person still code? If so I want them, but if they have forgotten everything... I of course censored details for privacy reasons.

worthless-trash
0 replies
9h51m

This sounds like you want to penalize students who studied for the exams. Or at least not reward them.

s/exams/interview/g

johnnyanmac
0 replies
7h27m

This sounds like you want to penalize students who studied for the exams. Or at least not reward them.

Interviews are like exams but you don't have any clue what topics are on the test. If Leetcode was some licensed, standardized approach to getting some license to verify my ability to code myself out of a paper bag: I'd hate it, but I'd grit my teeth and study it. exams can be studied for.

But it isn't, so I can be studying leetcode questions and be hit by a dozen other topics. I don't have time to study everything, and the market right now isn't worth pinpointing specific companies unless you have a stellar reference.

I’d say it’s a pretty good proxy for work ethic at crunch time as well.

I couldn't disagree more. Someone so prepared for interviews have the least skin in the game. Layoffs come and they didn't work > 40 hours but were otherwise excellent? oh well, get another job in a month because interviews are a breeze for them because they breathe DS&A.

why would a company want to hire someone who has external obligations?

I'd love to know the answer here as well. Why do companies internally penalize workers who were laid off, but then try to "steal" currently happy employees but make them jump through these hoops? The logic seems backwards; interviews should be hard and depress wages for the laid off, desperate workers so you can get a desperate unicorn. But you want someone who lacks the time to study because of current job obligations to get to an offer faster. Their proof of work ethic is being employed to begin with.

exe34
0 replies
9h40m

it's a good measure of whether they will sacrifice their home life and spend unpaid time doing extra work for you.

mathgladiator
1 replies
6h50m

Some of us derive the answer on the spot...

John23832
0 replies
6h39m

For the hashmap problem, sure. Any SWE worth their salt should be able to figure those out.

I highly doubt you are sight-reading atomic bomb LC hards.

johnthewise
0 replies
10h4m

Some people can't do it whether they had the time to study, which the point of the test.

fifilura
0 replies
9h27m

Any advanced topic requires struggling through a big set of "special cases" to master.

This is how I learned mathematics for example.

After you have learnt enough of the special cases (trees) you start to be able to connect them and see their relation (the forest).

Benjammer
9 replies
10h59m

So are we just going with a base assumption that interviewers can NEVER be trusted with anti-bias training and learning how evaluate people fairly? The examples mentioned in this comment section are all blatantly intentional biases that people are choosing to use. The amazing part is that all the “standard test eliminates bias” people seem to the most ignorant to where bias helps THEM. Forcing people to study for two months is blatantly discriminatory to age and family status, at a systemic level. While “this white straight guy might explicitly choose to give the other white straight guy an easy question,” is very subjective and intentional on the individual level. Like, employees can always choose to do bad things, in any situation. That’s why we have at-will employment…

Is the culture just so broken at these companies that it’s hopeless to expect people NOT to blatantly exploit the system for their friends? Why don’t people get fired for doing that?

Aunche
4 replies
10h26m

Forcing people to study for two months is blatantly discriminatory to age and family status, at a systemic level.

How is this any less discriminatory than any other assessment based interview where you need to prepare? Non-assessment based interviews end up being vibes based which is much more discriminatory.

angoragoats
2 replies
7h57m

You’ve set up a false dichotomy here; for any given position, there is typically a way to conduct an assessment-based interview that doesn’t require too much preparation for qualified candidates.

For example, at my current job, we hire web developers with Rails experience. Our technical interview process consists of either a pair programming session or an async/take-home task (candidate’s choice) which requires the candidate to implement a small feature in a Rails codebase. We do have some room to improve on objective evaluation of the candidate’s performance, but there is a test suite and a rubric which we use to evaluate their work. None of this should require that the candidate study, unless they’re coming in to the interview without Rails experience.

Aunche
1 replies
3h45m

This may work out great if you happen to have worked on Rails for your last job. However, I doubt that everyone you interview is actually that familiar with Rails but rather is pursuing any sort of opportunity that they can get. In that case, they would actually more time to brush up multiple different tech stacks than simply on algorithms.

angoragoats
0 replies
3h18m

In that case, the interview question is working as intended. For most of our roles, we want several years of Rails experience, and we are clear about that fact in the job listing. If someone applies without Rails experience, they either didn't read the job listing, or are desperate to find any job. While I empathize with folks in the latter situation, our positions really do require the experience, and the job market isn't so bad right now that a smart candidate should be going a long time without finding something.

If you happen to have Rails experience but it was several jobs ago, the task we give you is basic enough that you should be able to Google what you need during the task to refresh your memory fairly quickly. In fact, I did this when I applied, having not worked with Rails in a number of years.

Edit: My main point is, even if you technically do have to "study" (really, just Google a few basic Rails concepts) if you're rusty, everything you do is preparing you for the actual job. Studying how to implement a hashmap, or computing the longest palindrome from a string of characters, or whatever other harebrained problem FAANG etc want to ask, is 99% of the time not really helping you prepare for those jobs.

johnnyanmac
0 replies
7h20m

any other assessment based interview where you need to prepare?

because most other assessment based interviews are based on what you do on the job, likely stuff you've done at previous jobs as well. Less prep time when you spent thousands of hours already as a career.

johnnyanmac
3 replies
7h21m

are we just going with a base assumption that interviewers can NEVER be trusted with anti-bias training and learning how evaluate people fairly?

Yes. Because interviewing is

1. hard, but no company has proper full time proctors. So "expert interviewers" are a rarity

2. not standardized in the slightest. So your performance varies entirely by the interviewer, their style, and their mood that day.

3. some weird blind test where you hope you studied the right topics. You're not getting the best out of a candidate, you're basically hoping they read your mind and know exactly what you want them to say.

Is the culture just so broken at these companies that it’s hopeless to expect people NOT to blatantly exploit the system for their friends? Why don’t people get fired for doing that?

Sure. but that's a universal problem. "It's who you know, not what you know" is advice that has spanned centuries. I can't even blame the modern tech industry for that one.

That + the above issues with interviewing mean you're always going to go with a referral over a random applicant.

bluGill
1 replies
5h7m

2. not standardized in the slightest. So your performance varies entirely by the interviewer, their style, and their mood that day.

That isn't always true. When I interview HR gives me the exact questions I'm allowed to ask. These are vetted both to prevent me from asking something illegal, and also by research to get the type of things useful for interviews. Sometimes it is annoying - you can easially finish the interview with a great score but I have no clue if you can write code or not. However we are carefully trained on how to ask the questions and how to grade them.

johnnyanmac
0 replies
4h40m

That makes sense for soft questions. But I doubt it's HR devevloping a dynamic programming problem and writing a rubric for how good a score you can give based on a response.

I was mostly referring to technical tests, but I understand there are definitely some set of questions you need to ask no matter what. I don't really knock recruiters too much for repeating the usual "are you authorized to work in the US" kinda stuff even though it is the first question on their job application.

Benjammer
0 replies
2h5m

1. I’ve worked at multiple companies that absolutely have expert interviewers who design the interview questions and then teach mid-level engineers how to proctor them correctly. It’s like one 30 minute meeting, it’s not that big a deal.

2. All tech companies I’ve worked at since around 2015 have completely standardized interview questions, sometimes also hosted in a GitHub repo where any employee is free to comment or even open a PR to request a change. Every candidate gets the same questions. This thing where “faang” interviewers just pull a random LC question out of their ass is complete insanity to me. An organized set of questions takes a senior engineer like a week to organize and commit to… And if your questions can be memorized and recited by rote memory and the candidate can do well on it without the proctor knowing, then your questions are BAD or your proctor is a moron.

3. I’ve never worked anywhere where I would describe the interview like this. Even the startup where I was the first engineer and there was no formal “test”, it was an hour long chat with the technical cofounder where he grilled me about coding skills and past experience/accomplishments. I won’t take a job if the interview isn’t asking me things that focus on my existing experience and skills, it’s a red flag about the company culture in general.

As for your “universal problem,” I disagree with fatalistic takes where you just throw your hands up and say “whatever shall we do” all the while YOU are the one benefitting from the system that cannot be changed. This is how simple-minded people think about the world.

jkukul
4 replies
9h11m

A leet-code test would be much more standardized if candidates could solve it at home. Just send me a link to the quiz and let me solve it within a specified time frame.

I've done tests like this for some companies. It felt a lot fairer and more closely resembling the actual work environment than live leet-code interviews, with biased interviewer(s) and a stress factor that's not a part of the actual job.

skeeter2020
3 replies
6h32m

As a hiring manager I HATE leet-code tests, and they do nothing to differentiate candidates, but a take home in the era where people run chatGPT beside the interview window, or have someone else do the interview for them? Not a chance. You are 100% correct that it is way more representative, but the prevalence of cheating is ridiculous.

oytis
0 replies
6h21m

Take home is fine if you discuss it later in the interview. But also there should be some pre-screening to keep the number of interviewees reasonable.

jkukul
0 replies
5h38m

I totally understand you, but want to offer a different perspective.

They will also be able to use ChatGPT on the job. And StackOverflow. And Google. If they know how to use tools available to solve a problem, that will benefit them on the job.

If you're testing them for what ChatGPT can already solve, then are the skills being tested worth anything, in this day and age?

Take-home LeetCode, even with cheating will still filter out a good chunk of candidates. Those who are not motivated enough or those who don't even know how to use the available help. You'll still be able to rank those who solved the task. You'll still see the produced code and be able to judge it.

Like other commenter points out, you can always follow up the take-home LeetCode. Usually, it becomes apparent really quickly if a candidate solved it on their own.

CoastalCoder
0 replies
5h16m

This does seem like a vexing problem, especially when interviews are conducted remotely.

I wonder if either of the following could be cost-effective:

(a) Fly the candidate to a company office, where their compute usage could be casually monitored by an employee.

(b) Use high-quality proctoring services that are nearby to the candidate. E.g., give them 1-2 days in a coworking space, and hire a proctor to verify that thy're not egregiously using tools like ChatGPT.

Or alternatively, would it suffice to just have a long conversation with the candidate about their solution? E.g. what design trade-offs they considered, or how might they adapt their solution to certain changes in the requirements.

bossyTeacher
1 replies
7h44m

I'm sure anyone determined to do so can act unfairly regardless of what process is in place, but the fact that there is a standardized test in my mind does the opposite and makes the process much fairer.

This is what privilege looks like. The inability to see barriers that affect others in a worse position.

Standards do not imply fairness only consistency.

You got a test that filters out people who lack the time to train for these tests. Basically, devs with a life (see family)

CoastalCoder
0 replies
5h11m

IIUC, in your view using standard tests is a damned if you do, damn't if you don't scenario.

Is there a solution that you'd recommend?

scott_w
0 replies
9h35m

the fact that there is a standardized test in my mind does the opposite and makes the process much fairer.

It can make the process fairer but it's not a given. You can do the classic "no dogs, no blacks no Irish," and that was a standard across pubs in England. It certainly wasn't fair, unless you were racist.

If you're committed to fairness, then a standard will help. It gives you a clear point to fix and improve things and something you can use to measure if you're achieving your stated goals. That's definitely something you can't do if you're just making things up as you go along.

And yes, I made a deliberately provocative statement. I'm obviously not saying whiteboard tests are the equivalent of segregation.

civilized
0 replies
7h40m

the fact that there is a standardized test

...a standardized test? No. There are tests. They sure as heck aren't standardized.

Maybe they should be, since everyone seems to be doing the same thing.

ownagefool
36 replies
10h46m

I don't think the problem is the format, i.e. a 30-50 minute interview on simple coding with DS&A problems, but the escalation.

The reality is, fizz buzz got us 75% of the way there. It turns out when pressed, a lot of people can't write code. Yes, there's false positives, but there's also people brute focing their way through via copy & paste.

This doesn't manifest as a person who can't do any task, just as a person that's slow, delivers weird abstractions, and would take a lot of your time to get anything useful from.

But those people are also making those arguments, because, as you said, there's hundreds of thousands of dollars in it.

sjaak
29 replies
10h12m

I've also used FizzBuzz at several companies, and the insane amount of people it filters out continues to boggle my mind.

XorNot
16 replies
9h29m

Do you tell them what the "mod" operator is before giving it?

The failure rate of FizzBuzz has always struck me as depending on the idea that you can do a lot of programming and just never need that operator.

sensanaty
4 replies
9h0m

Yeah I know how to implement FizzBuzz since it's such a meme, but I've basically never used the mod operator in real code. Maybe it comes up in more math-y code I suppose, but for most backend/frontend/SQL code I've never reached for it.

wruza
0 replies
7h32m

  for (…) {
    heavy_op();
    if (i % 100 == 0) {
      printf("not dead");
    }
Classic

vundercind
0 replies
7h41m

I’ve used it for coloring alternating lines differently in UI code, and as a lazy way to log only every so many times some loop runs.

I only know it well because it was covered near the beginning of one of the first programming books I picked up (on Perl 5) and it stuck with me because it seemed wild to me that they had an operator for that.

stefan_
0 replies
8h31m

More mathy code like checking if a number is even or splitting a total number of seconds into minutes and seconds?

kmoser
0 replies
5h28m

Depends on the application. I've written accounting software that makes use of it, along with heavy use of floor() and ceil(), including in SQL.

sjaak
2 replies
7h41m

No but I permit internet access as long as they don't search for the solution (I trust them not to do that, and don't monitor what they do)

DonHopkins
1 replies
6h6m

You're too trusting.

ownagefool
0 replies
3h42m

Whilst I agree, his point still stands that either they do it fast or never.

arethuza
2 replies
8h19m

I once worked with a guy who was an incredibly good developer and I was surprised when he didn't see anything special about the number 64 (i.e. a power of two) - turns out that he'd never done any bit fiddling type work so he hadn't had to think in those terms. It wouldn't surprise me if a lot of people hadn't heard of "mod" either....

dkdbejwi383
1 replies
6h53m

A huge majority of programming work is basically just CRUD stuff and other data shuffling. It’s not surprising that someone wouldn’t have needed to work with big shifting (or modulus) in that case.

arethuza
0 replies
6h44m

He was an expert in complex multi-organisation enterprise integration and was the go to guy to work out why horrific distributed transactions were failing... He also did a lot of cool stuff as side projects in his own time - just none of them happened to involve worrying about powers of 2.

daemin
1 replies
6h58m

Unless you specifically want a compiling and running version of FizzBuzz you don't actually need to use or know about the mod operator.

At least for me it would be sufficient if the person used a function like IsMultipleOf(x, m), or Remainder(x, n). This would at least make it clear what the function did even if they didn't get the exact operator.

The other thing to note is that the mod operator works differently on different languages and platforms.

DonHopkins
0 replies
6h11m

the mod operator works differently on different languages and platforms

Not with positive inputs, which is the domain of FizzBuzz.

Even if you don't know what "mod" means, if you have no idea know what a remainder is, and that the problem calls for it, and you can't derive the mod operator using integer addition, subtraction, multiplication, and division, then your math and problem solving skills are pretty weak, which FizzBuzz tests.

ownagefool
0 replies
3h42m

I stopped using fizz buzz a long time ago. 90% of candidates can't define a 2d array in their chosen language without first filtering the candidates, where you get to about 50%.

eschneider
0 replies
8h59m

Even if that's so, modulus (or at least the concept of remainders) are elementary school math and any competent programmer could bang together an (inefficient) modulus operator in a few minutes.

So even in a language w/o a mod operator, it's not a hard problem if you understand how to solve problems with code.

azornathogron
0 replies
8h39m

You don't actually need mod to do fizzbuzz, even if that's the most obvious way for people who know what mod is.

But without any "real" math at all you can do it with, eg, two counters and some if statements. Or if you recognise that there's a repeating pattern you can work out that pattern manually and just write code to emit it over and over.

hcrean
4 replies
7h13m

I failed FizzBuzz the first time someone gave it to me in an interview...

The specific failure was that I first attempted to solve by using repeated subtraction. The guy kept asking me to "solve it a different way", or saying "there is a better way to solve this". I tried using arithmetic tables, I tried using results about base10 remainders and I even tried using one of the corollaries to Fermat's little theorem to speed it up for larger inputs... every time I was told I was getting it wrong because "there was a better solution". In the end he pointed out that the only solution he would accept was use of the mod operator.

Since then I have actively kept a tally: I naturally use the mod operator an average of twice a calendar year, it has always been in personal life code when dealing with complicated geometry problems, the bit of code containing it almost always fails on some edgecase because at the point of using mod it is convoluted.

vaylian
2 replies
6h39m

FizzBuzz is a highly artificial problem. It makes sense that people who are not familiar with it will assume that there is an elegant solution. But in the end the right approach is to be very boring and to notice that you need to check for divisibility with 15 before you check for divisibility with 3 and 5.

bluGill
1 replies
5h1m

FizzBuzz is a problem that doesn't have an elegant solution. That is the point: to see how you approach the problem. (there are 3 possible solutions, each in-elegant in their own way)

ryandrake
0 replies
37m

I don't like FizzBuzz because it over-weights the interviewees knowledge of the relatively obscure modulo operator. Yes, there are other ways to do it, but the expectation of FizzBuzz is that the candidate has that "Eureka" moment and remembers modulo.

If I need a "Non-Programmer Weed Out" question, I'd rather give a problem that is 1. as easy as FizzBuzz, but 2. is just 'if' statements and loops and cannot be solved by knowledge of a particular operator (or bit twiddling tricks).

johnnyanmac
0 replies
6h50m

Honestly sounds like a bad interviewer. repeated subtraction is a good first step and I would try to push more if that was the first implementation. But If you could derive a base 10 remainder you know conceptually what problem the mod operator is trying to solve.

a % b = a - (b * a/b) /assuming a sane language with integer division, else cast a/b to int/

Figuring the above operation (or getting close) is when you should more or less pass, and That's a good point to show the interviewee what the operation is. That should be the point of an interview problem, to show the thought process, not that you know fancy tricks.

But alas, I was shown an XOR swap in an interview last week and spent 3 minutes deriving it on paper instead of 3 seconds saying "oh yeah, a => b and b => a" to a trick that I haven't seen since college some decade ago. The current market loves tricksters, I suppose.

And yes, the actual real world use of modulo is surprisingly sparse, despite easily imagining situations where you could use it.

arethuza
4 replies
8h16m

I once froze in an interview when asked a simple technical question - I'd been giving a presentation for an hour on how to launch a new product and I was asked by the CEO how to do something technically trivial - my brain could not do it. So he probably thought I was some marketeer pretending to be technical - which isn't really true.

I suspect quite a lot of people who are labelled as "can't code" are freezing like I did.

sjaak
2 replies
7h36m

When I ask people to code FizzBuzz I:

  - give them ~30 minutes on their own machine
  - they get to pick the language they code in
  - I leave the room for large parts of it
  - I bring them a drink
  - I tell them I want to see what they can do and that I don't care if they complete it
  - permit them to search on the internet (as long as they don't copy/paste a solution)
I see this usually:

  - they finish in a few minutes
  - they just can't do it, even with hints

johnnyanmac
0 replies
6h47m

permit them to search on the internet

really? they get 30 minutes + internet and they couldn't google "javascript how to get divisible by 3"? That's just bad research at that point.

arethuza
0 replies
7h28m

Yes that sounds pretty sensible.

Do you ever have a conversation with these people as to why they think they couldn't do it?

ownagefool
0 replies
3h56m

I suspect some do, and some will be a lot when you bunch them all together.

However, counter point, I've had people forced on me through much of my career who just can't code for the most part, and despite being pretty reasonable about it ( it's part of the nature of the work I do ), I'm very rarely surprised by competency.

piva00
0 replies
9h23m

Same experience, used FizzBuzz at many places and always got surprised by the amount of people it can filter. The best interview process I've ever ran at a company consisted of a basic FizzBuzz for about 15-30 min followed by a pairing session no longer than 1h30m on a problem that could get as tricky as we wanted to assess their skill level.

We would both test the basics as well as go through with the candidate on how they think, how they collaborate, help them out if we felt nervousness was impacting them showing their skills, and in the end got a much better grasp on how skilled they were than if we were looking at Github repos or giving DS&A trivias to solve.

CoastalCoder
0 replies
4h48m

Some years ago I was remotely interviewing at Google, and I was asked to code up the reversal of a linked list. But my brain just froze.

This is something I can easily solve in 5-10 minutes, correctly handling every plausible corner-case.

I'm curious how common this is, statistically speaking. I'm also curious how it correlates with other things about the interviewee.

wruza
5 replies
9h32m

A lot of people couldn’t even read this thread if someone was watching closely. They’d recognize words and idioms, but couldn’t make sense of these or think. It’s called anxiety and rarely has anything to do with actual performance. Anxiety is a frequent guest in a smart guy’s home.

As an early 2000s integrator/analytics I learned to write code when someone watches out of interest or straight time pressure (still taxing sometimes). But most developers that I know intellectually curl up in such situation, regardless of their skill or performance levels. We worked with one very math-y low-level-skilled guy whom our clients described as “literally freezes for an hour without moving, should we pay for it?” when he did field work. He was a very strong developer otherwise.

Not that a company must hire or want these people, but the idea of writing code under uncanny pressure all day makes as much sense as that swordfish scene.

ownagefool
4 replies
8h24m

I have empathy for the false negatives. I have been them, or maybe at times I'm simply a false positive, the problem is those people are likely to freeze no matter the interview.

Further still, I get push back with folks citing self-prescribed medical conditions, but the same people generally display the same behaviours during the working day.

So other than contract to hire, which typically limits you to people with a job, I don't personally have a better way.

CoastalCoder
3 replies
4h52m

I have empathy for the false negatives. I have been them, or maybe at times I'm simply a false positive, the problem is those people are likely to freeze no matter the interview.

I can't speak to the statistical claim that "those people are more likely to freeze no matter the interview."

But just my personal anecdote: I do fine on take-home coding tests, but I freeze up on live-coding tests.

This is one reason I'm vexed by the allegedly common cheating in take-home coding tests. It makes employers suspicious of the testing style that I'm best at.

ownagefool
2 replies
4h37m

I've actually had people cheat on live coding sessions.

For north of $2m over your career, cheating probably is the smart thing to do, especially for a borderline candidate, as there's a fair amount of evidence that the prestige on your CV will make things easier going forward.

However, my problem with take homes was never that the candidate would cheat, but rather they'll probably spend way more time than the 2 hours allocated.

I'm actually less worried about the candidate doing that, than I'm worried that the interviewer bakes in a bunch of assumptions like having a machine setup to do the task, having the specific domain knowledge and experience, and then accidentally trolls the candidate with little to no avenue for feedback.

CoastalCoder
1 replies
4h29m

I've actually had people cheat on live coding sessions.

What tipped you off?

Also, I'm curious: do you think having them discuss their solution in depth would have been a good countermeasure?

ownagefool
0 replies
3h50m

I mean it was pretty obvious with their eyes darting then several lines of code appearing in the code editor.

Of course, this doesn't mean I've discovered 100% of the cheaters, just the obvious ones.

Also, I'm curious: do you think having them discuss their solution in depth would have been a good countermeasure?

To some degree. But not everyone communicates as well as they code or vice versa, and then it comes to what you're trying to qualify.

boshalfoshal
27 replies
11h0m

The problem you are describing is interview variance and hiring bias, not leetcode. This happens irrespective of interview style.

Many companies have question banks that are specially designed to be fair/have some contextual relevance (ideally) to some "realistic" problem. Or at least, many of the companies I've interviewed at follow this model. I consider these coding questions to be "leetcode" style because at the end of the day they are an isolated coding problem, even though they may not be a problem from leetcode verbatim.

Companies that execute on that style of interview well are generally fairly pleasant interviews, at least in my experience. Good companies/interviewers will gauge more than just the final code to determine a hire or no hire. And a large portion of companies also have hiring ratings on a scale to make it less binary.

kidintech
19 replies
10h47m

Question banks that are too big: huge variance, and OP's point stands.

Question banks that are too small: leaked on eastern forums immediately, candidates show up reading answers out to you (some of the guides include guidance on when to pretend to think, I am not kidding).

The idealized version of "question banks" might work. The real one does not; you'd require employees constantly scouring forums in every language known to mankind, immediately removing anything that gets leaked. On top of that you'd probably require a competent committee overseeing all questions in the bank constantly and ensuring the lack of variance in difficulty.

Source: I interviewed at and for Goog and Pltr.

Rinzler89
11 replies
9h5m

> leaked on eastern forums immediately

What exactly are "Eastern forums"? "Eastern" what? Europe? Asia? The world?

kidintech
10 replies
8h48m

The most common example would be 1point3acres.

I'd prefer to not be more specific; I chose the word Eastern on purpose.

For DEI committees reading this: I am both eastern european and asian, so I hope to be exempt from any scrutiny.

Rinzler89
8 replies
8h36m

So you wanted to say "Chinese forums" but couldn't say it out of fear?

kidintech
7 replies
7h43m

no.

I wanted to say Eastern, as I have examples from both Asia and East Europe.

I wished to not be more specific so as to not derail the discussion into "user kidintech implied that nation X has a tendency to cheat".

Rinzler89
5 replies
7h30m

Out of curiosity, can you share some examples from eastern Europe? Where does one find such websites?

Also, IMHO, blanket generalizations like "Asia" and "Eastern Europe" in such contexts can actually be more offensive than just mentioning the one country where the thing happens since you're basically painting with tar a whole sub-continent with dozens of different countries, just for the things happening in one country.

What I mean is, if by Eastern Europe, you actually mean some dodgy Russian forums, I think a lot of Eastern Europeans from Bulgaria all the way to Poland and the Baltics might feel offended of being included since we are not the same.

johnnyanmac
2 replies
7h10m

Yeah, there's also the implication here that Americans rarely cheat. They aren't as public because English is under a microscope, but there are definitely answer banks if you know the right person and can fork over the cash.

If it's anything like High School/College, the sad part is these kinds of people could probably do well in interviews regardless. These answer banks are simply the difference between an A and an A+. And sadly the current market seems to only want A+ candidates. Who's fault is it really?

Rinzler89
1 replies
6h52m

> And sadly the current market seems to only want A+ candidates.

You mean the current FAANG market paying top dollar. I know plenty of unknown companies taking B candidates because they aren't paying top dollar (in Europe at least)

>Who's fault is it really?

The governments and central banks for devaluing the currency post-2008 with their zero interest rates, causing the value of savings and wages to plummet and the value of assets, housing and stonks to skyrocket, causing people to chase get rich quick schemes on the stock market and on the jobs market. Coupled with the VC promoting for an unsustainable growth (more like pump and dump) of so called "tech companies" who's products were not economically viable from the get go, they just survived on zero-interest money and fake promises, artificially boosting the demand for SW workers casing many young people to go into tech just to chase money, money that's now gone and so is the demand for coders.

Without this artificial demand for devs caused by zero rates and overhype in the tech industry of financially unsustainable products that were banking on skirting the local laws (AirBnB, Uber, etc), then those people chasing money would have went into finance or investment banking to chase money there instead of causing a huge backlog of candidates in tech. Just my 0.02$

johnnyanmac
0 replies
6h25m

I know plenty of unknown companies taking C-/B+ candidates because they aren't paying top dollar.

in my experience: not these days. And I work in games, so "top dollar" was never in question.

My 0.02$

That's a fair take. Tech in some ways was indeed a necessity with a huge reach, so I don't think the overhype was the difference between being a trillion dollar industry and a million dollar one. But tech would probably still be a billion dollar industry without all the factors you mentioned.

Games... well, stability was never a factor, and I knew that going in. It's a shame they are doing the exact same pump and dump schemes tech has fallen into. And it's not like layoffs were uncommon after a project finished; it's just that they are doing it purely for better looking earnings call instead of "we cannot keep funding studios anymore".

kidintech
1 replies
7h14m

No, because I feel like mentioning previous employers AND mentioning the languages I speak would get quite specific.

You are interested in Eastern Europe, so you should be familiar with olympiads; ask around any circle of ex-olympiad participants and you are bound to find something.

I am not sorry if you took offense; you're either from one of these countries and are clueless to the circles that exist next to you, or you are not from one of these countries and are trying to be offended on behalf of others.

Rinzler89
0 replies
7h3m

>ask around any circle of ex-olympiad participants and you are bound to find something.

Obviously I'm not a golfer.

DonHopkins
0 replies
6h23m

So New York, Boston, Washington, Baltimore, Philadelphia, Washington DC, Maryland, Virginia, Delaware, New Jersey, Main, Connecticut, Rhode Island, etc?

Or by "cheating" are you specifically referring to the lying cheating treasonous fraud from New York who was just found guilty of 34 felonies to cover up cheating on his wife with a porn star to inflence the election?

skeeter2020
0 replies
6h30m

> I am both eastern european and asian, so I hope to be exempt from any scrutiny.

This only works if because I'm western and white I must ALWAYS be scrutinized.

boshalfoshal
6 replies
10h36m

I agree with you, but I don't really see how this invalidates the style of interviews where you're presented with some timeboxed coding problem (of reasonably scaled difficulty) and are asked to solve it.

There will be bad actors regardless of the interview style, thats why companies have multiple interview types/styles/rounds to sus out a candidate, as you probably know.

If they BSed their way through a leetcode interview, then they probably won't make it past a behavioral interview where they have to go in depth on some past project. And if they BSed that as well as every other round, then hey maybe they are crafty enough to succeed at the actual job.

kidintech
5 replies
10h28m

and are asked to solve it.

I think this is where our different opinions come from, while we agree on the other aspects.

In my personal experience, I have never felt that the hire/no-hire decision relied exclusively on my ability of solving the presented problem; I have passed interviews where I did not solve the LC-style problem optimally but I communicated clearly, picked up on hints, was aware of when I hit "walls" and provided working but less than ideal alternatives when I could not figure out the neat tricks.

Reading through the thread it seems that my experience is not universal, and the majority here have had less pleasant interviews, so I understand where you are coming from.

johnnyanmac
3 replies
7h14m

Reading through the thread it seems that my experience is not universal, and the majority here have had less pleasant interviews, so I understand where you are coming from.

it changes immensely based on the job market. I've defintiely tanked some inerviews hard, stumbling on softball questions that shoulda been a bullet point. But I get pretty far or even gotten offers.

The last 12-18 months though? I've had interviews that felt like a dream but got zero follow up to. Been ghosted after seemingly final rounds where I spent 5+ hours on technical tests. It's not even enough to "understand the problem and communicate steps". You gotta be flawless, and you still might be cut compared to 3 years ago where a "C" performance could still land multiple offers as long as your experience made up for the quiz questions.

CoastalCoder
2 replies
4h57m

it changes immensely based on the job market.

I dodged the .com bust because I worked for the U.S. DoD at the time.

But I got laid off for the first time during last year's "15% bloodbath".

If I compare my current job search vs. all of my job searches in the past:

(1) As parent comment said, the bar seems to be much higher. I've thought that I did really well on some interviews, only to not get an offer.

(2) Some interview processes are way more rigorous. For a DevTech role within nVidia, I had 12 interviews + 2 take-home problems. (BTW, the take home problems were incredibly fun. Well done nVidia!)

(3) I've finally accepted a job offer from a large, established tech company, and the pre-onboarding process is amazingly slow. I accepted the offer a month ago and still don't have a start date. In a better job market either (a) they'd probably work harder to be good about this stuff, or (b) I'd just take a different job because of the delay.

ryandrake
0 replies
49m

(2) Some interview processes are way more rigorous. For a DevTech role within nVidia, I had 12 interviews + 2 take-home problems. (BTW, the take home problems were incredibly fun. Well done nVidia!)

That's ridiculous, tho.

Did they really not have enough information on the 11th interview to know whether or not they wanted to hire you?

CoastalCoder
0 replies
1h50m

I forgot to mention another:

(4) Ghosting candidates seems common now. I'd never experienced it before now.

bombela
0 replies
9h16m

I have had all possible experiences. Sometimes I feel like genius and ace some leetcode with an almost novel solution. Sometimes I missunderstand the question/scope and mud myself into the hole of despair.

I have been rejected for one mediocre interview among many good ones. Or the other way around accepted even though I didn't perform well.

Sometimes the interviewer works with me. Sometimes against me. Sometimes a war story impresseses positively, sometimes raises suspicions.

At this point it feels like gambling.

I have also ran almost 400 interviews on the other side over the years, and to me it seems quite clear when somebody cannot write code at all. I like to think I am not biased. But who knows.

dinobones
6 replies
10h33m

I take issue with it because Leetcode gives tech people a fake feel good, “yeah but at least it’s fair” illusion, when really it’s probably just as biased as any other hiring method.

This is ironic considering these companies have forced mandatory DEI seminars (which I have no problem with btw), inclusive language, #EveryoneCanCode, and so on.

But despite all this, you end up with teams and organizations that are 99% of the same X somehow. Replace X with race, school, even state from home country sometimes.

You know there are websites where people share all the interview questions to these hard interviews / referrals exclusively in their language and behind a pay or rep wall? And there are Telegram groups where international students leaks the questions or do interviews in place for one another.

It’s inevitable these types of issues arise when there’s so much at stake, ex: in just 5 years, a $200k TC advantage at a top company, becomes $1m or more with appreciation.

I just really dislike the veneer of “fairness” when there are so many problems with the process, even beyond the questions that have nothing to do with the job.

lupusreal
5 replies
10h11m

This is ironic considering these companies have forced mandatory DEI seminars (which I have no problem with btw), inclusive language, #EveryoneCanCode, and so on.

I really do wonder what those sanctimonious sermons are meant to accomplish. People who are already ideologically aligned with them won't learn anything new and may just resent it, while people who aren't aligned won't become aligned as a result of that "training".

But you're talking about it as though you expect it to have a constructive impact, resulting in irony when it doesn't. I don't see the irony because I don't expect any benefit from those struggle sessions in the first place.

workingjubilee
1 replies
8h21m

struggle sessions usually involve public torture or executions. it's laughable to compare "being mildly inconvenienced" with that.

lupusreal
0 replies
4h50m

Struggle sessions in their basic form used social coercement to extract confessions of guilt against some collective cause. This describes the DEI training sessions I've been in well. Admit that you have bias (effectively confessing guilt to a "crime" that gives your employer leverage over you) or get dogpiled and have your refusal to admit guilt cast as evidence of your guilt anyway.

matheusmoreira
1 replies
9h8m

They're supposed to absolve the corporation and its leadership of responsibility and liability. By giving that training they get to claim they did all they could.

lupusreal
0 replies
4h52m

I think that's precisely right.

asmor
0 replies
6h33m

You'd be surprised how much self-perception and reality can differ. Lots of types that think they're the best allies ever and then show a total lack of empathy (especially if someone's different in their immediate family) that'd need a reality check.

Though usually the intersection of people running DEI initiatives and those people make a large set. Assimilated gay people love talking shit about how trans people make "us" look bad.

martindbp
5 replies
6h42m

It's also a great way to filter out anyone who has any kind of commitment like kids, aging parents to take care of, or have health issues themselves that makes it hard to cram leet code non stop on top of a busy career.

For companies this is very rational, you want non-distracted employees who can work over time.

hobs
4 replies
6h14m

It's really not that rational unless you want someone only familiar with being the top code monkey.

In all my years of sw dev the number of times that would have helped vs being able to communicate and manage expectations across a swath of people is like 1:1000.

slavapestov
3 replies
6h1m

To be fair, you need at least one person on the team to do the actual work, while everyone else is “communicating and managing expectations”.

pavel_lishin
1 replies
5h18m

That statement is not untrue, but I think it over-estimates how much of the "actual work" is banging out code, vs. making sure the correct code is being written.

ryandrake
0 replies
45m

Yea, I've worked in a place where it was just "coders coding" and nobody was communicating and managing expectations, and that was its own unique form of awful. You need both.

bandyaboot
0 replies
5h24m

It’s actually possible for members of the team to be capable of doing “actual work” in addition to being good communicators.

wruza
4 replies
10h2m

Naive questions ahead, if hires weren’t made scarce by some absurd filter, why would they pay $200-300k extra? Feels like the whole idea of stellar salaries must be based on something stellar. Afair, before Google(?) made it normal, developers were sort of dirt cheap. Weren’t developers in abundance at all times?

palata
3 replies
7h30m

The reason they pay $200-300k extra is to attract the best they can. Say you got the same salary working in an ethical company than in a FAANG, would you go for the FAANG?

The absurd filter is just some kind of lottery. They could have a different one: at the end of the day, it's only when the person starts working that you can actually see what they are worth.

The thing with a filter like this one is that it filters out a whole category of people who may actually be good. And it reinforces itself: you hire people who are good at leetcode, who will themselves possibly be good at hiring people who are good at leetcode. Does a company of leetcoders perform better than a company made of a diversity of good engineers? Not clear.

CoastalCoder
1 replies
4h31m

Say you got the same salary working in an ethical company than in a FAANG, would you go for the FAANG?

Very much a tangent, but what do you mean by a company being "ethical"?

I have a few concerns about how that term is often used in these discussions:

(1) it's treated as a binary quality, rather than some kind of continuum, and

(2) there's rarely a recognition that different persons have different conceptions of what's ethical, let alone a justification for what the writer's preferred definition is uniquely superior.

palata
0 replies
4h14m

The beauty of it is that my question is still valid :-). Let me rephrase it:

Say you got the same salary working in a company that you found more ethical, would you go for the FAANG?

Everyone is different, but it's amazing how many excuses we can find to justify doubling/tripling our salary :-).

wruza
0 replies
5h49m

I agree with this. But the root commenter talks about it as something these people are worth, when it’s just that - a lottery. A company that has so much money that they don’t know which barrier to put there to stop the flood. You jump through absurd hoops and join the club. Kinda like being accepted into a cool kids league, but activities are the same.

johnnyanmac
3 replies
7h42m

because there’s only a handful of companies that pay well

If this was just FAANG I wouldn't even mind it. Bigger compensation means bigger hoops to jump through, artificial or otherwise. At least those bigger companies come with interview guides.

But I've been dropped Leetcode mediums on some Unity game dev jobs barely paying 40/hr with minimal benefits. Game interviews already have an absurd number of topics to try and guess you'll be quizzed on. (last interview wanted low level C memory/bit manipulation question... the one before that did Unreal Engine trivia... then the one before that decided to give me vector math and ray intersection questions), adding in random string manipulation questions when you will barely use more than concatenation on the job doesn't help with studying.

bena
2 replies
6h45m

If you are applying for game dev jobs, C memory management, the gnarly parts of Unreal engine, vector math, and ray intersection are all things you could be doing on the job.

Game dev is lower paying, less structured, and more involved than typical web dev jobs.

I’d really only want to get into game dev early in my career or as an independent creator. It’s a touch exploitative.

johnnyanmac
1 replies
6h31m

It sure is. I could also be questionied on:

- CPU/GPU architecture

- graphics/shader programming ( I do enjoy graphics programming, but I have been asked these questions despite not applying for graphics roles)

- GPGPU

- traditional software engineering (programming patterns, architecture)

- netcode (I never applied to a network engineering position. I in fact actively avoid that part of the stack)

- general industry questions (what kinds of bugs can appear on shipping build that may not appear on debug builds?)

- a myriad of gameplay programming paradigms

- coding tests in Unity, despite applying for an unreal engine position (this has in fact happened twice now. I know Unity, but come on: can you imagine getting a javascript test for a c++ position?).

I've been asked all of these in some capacity over the years. At what point is it on me for not being some sort of omni net/graphics/engine gamedev that can answer any question on the fly, and not on the company for being paranoid about professionals studying for the skills they are clearly seeking? If someone can "study for your interview", why wouldn't you want that person? That's what they do on the job after all.

I’d really only want to get into game dev early in my career or as an independent creator.

I'm already 8 years in, so a bit late for that. My plan is eventually to go indie, but I need a bit more time in my career before making that jump.

Despite the common advice c. 2022, getting a boring cushy tech job right now isn't very viable, so may as well stick to what I'm actually getting interviews for.

bena
0 replies
4h32m

Fair enough man. I've done hobbyist game development, independent game development, and applied to some shops myself early on. But eventually, you get a job and your path diverges, etc, etc. Like, I'm not anywhere I'd imagine I'd be when I was in school.

I think at least half of all programmers got into it because of video games. They know it's desirable, so they can filter almost as hard as they want.

Like, the industry is just way more jacked up than general software development. I understand your pain.

Although, if you're currently between jobs right now, you could crank out a prototype of something and see where it takes you while job hunting. Because you will always feel like you could use just a bit more time. Sometimes you just gotta do it.

simplefish
2 replies
8h3m

I interviewed at a company known for consistently asking one of the same four questions in a specific interview round. These questions were widely shared on forums like Blind, Leetcode, and Glassdoor. The recruiters also provided strong guidance on the type of problems to expect.

I prepared thoroughly for all four main questions and any other plausible ones I could think of. I practiced writing solutions to ensure I was fast enough for the interview. Additionally, I pre-prepared ideal answers for each question in case I got stuck.

When the interview came, I got a total curveball: a question that was significantly harder than the usual ones. It didn't fit the round's theme (it was a DSA question, but I'd already aced the DSA round), was obscure enough not to be on LeetCode, and required writing a solver for a hard variant of a known algorithm. I panicked, copied the prompt into ChatGPT (despite being instructed not to use it), transcribed the result, and pretended I had recently studied the relevant algorithm.

I passed the round, nailed the other interviews, got the offer, and accepted. Later, I found out that interviewers are instructed to pick one of four specific questions for that round, and the one I got wasn't in the list.

I'm left wondering if the interviewer was trying to sink me or was just bored with the usual questions. The whole experience raised several questions for me:

Is it cheating if I already had pre-prepared answers for the questions they were supposed to ask? What's the difference between using pre-prepared answers and using Google or ChatGPT during the interview?

If the interview had gone according to plan, what was I actually demonstrating? My ability to use Google?

When the interviewer asked an impossibly difficult question, I would have failed if I answered it legit, even though I'm a good engineer. Failing such an unfair interview round doesn't serve the company's interests.

What is this interview process meant to demonstrate? My true value as an engineer lies in my ability to communicate clearly, think outside the box, identify and address technical tradeoffs, mentor juniors, and propose technical solutions that meet requirements while minimizing risks. Yet, I'm expected to solve a hard variant of the Traveling Salesman Problem in 45 minutes or I don't get the job? Why?

The whole process seems broken, but I'm not sure how to fix it.

weatherlite
0 replies
4h56m

How did you do it without them noticing, you weren't sharing your screen ?

CoastalCoder
0 replies
4h22m

What is this interview process meant to demonstrate?

IIUC, the interview deviated from the company's interview policies.

Could the answer simply be that the company has no intentions regarding the aberrant interview process that you experienced?

bdangubic
2 replies
6h39m

there’s only a handful of companies that pay well

with all due respect I believe this is about as far from the truth as it gets. I believe the issue is that people think they have to work at FAANGs in order to be paid REALLY well which is just nuts.

I know many people making (very) high 6 figures working at places most have never heard of. instead of looking for FAANGs people should be looking at companies that have been in business for 20+ years (if publicly-traded company the easiest "measure" would be whether you would invest your own dough into that company) and then make your self indispensable there (this is much easier than it sounds) to a point where you are more valuable to the company they company is to you. This is un-achievable at FAANG but this should be everyone's career goal. once you are worth more to a company then company is to you, compensation-wise sky is the limit :)

ZephyrBlu
1 replies
24m

I know many people making (very) high 6 figures working at places most have never heard of

You know people making ~800-900k at places most people have never heard of? That is what "high 6 figures" means. I have to assume you mean more like ~$180-190k?

fragmede
0 replies
15m

Not op, but FWIW, I know people who make high six figures (explicitly, $750k>) at companies that aren't household names or FAANG(ish) companies (or AI companies for that matter), though I also know my share of people that are at such companies that most people, or maybe just people here have heard of, that also make > $750k. Some of them aren't even software engineers! Most (all?) of them aren't paid that much on their W2 though and have lucked out with stock options/RSUs/related compensation (again, at non-FAANG companies, some private).

Not trying to brag that I have well-paid friends, though it might come across that way; just corroborating the fact that it's possible for late-career professionals to make that kind of money at non-FAANG companies.

yobbo
1 replies
10h6m

What about a type of blind interview where neither of the two know the problem or solution in advance. After, their solution is blindly reviewed/graded by a third party.

- Input from the interviewer reflects communication ability, cultural fit, and so on of the candidate.

- Input from the blind grader reflects ability of them as a team.

- Low grades count against the interviewer as well.

Bingo; now both are stakeholders in success.

eschneider
0 replies
8h56m

This is very much like the "real world" situation. OTOH, I think this leaves the interviewee even more vulnerable to the unfortunate situation where they correctly solve the problem but the interviewer is convinced that a different, wrong solution is correct. Live long enough and you'll have that happen to you.

OTOH, seeing how the interviewer reacts to that situation will tell you a lot about whether you really want to work there.

yieldcrv
1 replies
11h11m

wait, can Lisa Khan at the FTC attack this too?

lr4444lr
0 replies
7h53m

Nah, this will be an EEOC bogeyman.

noodleman
1 replies
8h21m

This is a good assessment. 1 and 2 are why the system won't change, but I don't think they were intentionally designed with that in mind. I think it's a hang over from academia, bearing in mind how many of the top engineers at FAANG are PhDs.

Well, that and how almost nobody who successfully finds employment after "grinding" leetcodes wants to remove the barriers for entry.

I think Leetcoders can't envisage a better way to assess someone than by subjecting them to the same kind of hoop-jumping you get made to do in university. They're not interviewing you for a job as there's no module on interviewing candidates on the CS curriculum, and don't have much professional experience outside of academics or software engineering. They're simulating a dissertation defence, because that's how they were assessed for their competence.

That's my charitable interpretation. If I'm being cynical, it's elitism - a way of making sure you're "one of us" (read: obnoxiously academic, Type-A personality, "logic over feelings").

KaiserPro
0 replies
7h56m

how many of the top engineers at FAANG are PhDs.

Not that many, but its interesting how many are from "elite" universities. I'm in a research org for a FAANG and we often get to see all the handwringing about how we can't recruit more of people type x.

Well, if you only hire from MIT, Stanford, Oxford etc, then they are all going to look the same.

For those outside the research org, its a bit better, but its still the most uneven place I've worked.

Tainnor
1 replies
10h2m

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.

If you want to earn top money, you gotta play the game. This is true in every profession, you think lawyers that want to work at top law firms have it any easier?

There's a lot of valid criticism with respect to today's tech hiring practices (especially because it doesn't only affect top paying companies), but I don't feel like "I can't get ridiculously wealthy without selling my soul" is a particularly compelling one.

7thpower
0 replies
6h23m

Although I find it disappointing, this is the truth. It is a function of supply and demand. There is always a gating function when you have an abundance of supply; sometimes it is leetcode, sometimes it is school, take home work, resume formatting, a mixture, all of the above, etc.

Everything is a proxy because, in most scenarios, there is no way to understand effectiveness of an employee until they have worked for you for a while.

Of course there are other ways, but they all carry their own risks.

That’s why referrals, imperfect as they are, carry so much sway. In theory they reduce uncertainty and require some expenditure of political capital.

weatherlite
0 replies
9h49m

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.

I don't think this is an issue of bad luck, its quite probably to get difficult interviews especially if you're applying to the popular names.

vundercind
0 replies
8h54m

The proof of some of this is that these companies could come up with a standardized test maybe with, say, smaller-scale refreshers every few years (this is normal in some professional certs) and save a ton of money if it were really about ensuring a base level of competence using these sorts of questions as the yardstick.

But that would dramatically increase worker mobility, for one thing. So they don’t do that.

(“No it’s because they don’t want you to be able to test prep” that makes no sense because 99% of the way to prep for these is… exactly like test prep)

valicord
0 replies
6h35m

I will ask you verbatim one of those quad tree/number theory/inclusion exclusion principle questions

Why don't you list them here to illustrate your point?

tzs
0 replies
4h32m

A way to suppress wages and job mobility for SWE. Who wants to switch jobs when it means studying for a month or two?

If what Google search tells me is true the average SWE tenure is only a couple of years or so.

I might need a month or two of study (or more!) to be able to handle the harder Leetcode problems, but if I was expecting to have to do this every couple of years or so I'd consider taking some steps to maintain that knowledge between jobs.

That would probably be considerably less overall effort than forgetting it and having to cram for months every couple of years.

tgv
0 replies
6h20m

this is costing us 100s of thousands of dollars

That depends very much on your world view. If you get the job, it would imply you've just cost a lot of other people $100ks. That simply can't be true, because there's a small number of such jobs.

The only way this can possibly hold is if you hold that only the "best" candidate should get the job, and by "best" you mean: the one that gets most of the leetcode questions right. But then there's no us.

Edit: I'm not in favor of leetcode interviews, and I do understand that there's a bias in interviews (which won't go away when you drop the leetcode).

sethammons
0 replies
10h20m

There is no grand conspiracy. People try to develop what they feel is a fair interview with good signals. It simply turns out that many people are not good at that and have biases that they may not even be aware of. Tackle on some cargo culting and "best practices" and you have your typical broken process.

For those wondering what the alternative is to leetcode: a work sample test. Take a real problem your team solved recently, distill it down to remove internal-specific knowledge, and give candidates 3x the time to solve it compared to what it takes an internal dev to solve. Bonus points for having a rubric guide the scoring.

robbyiq999
0 replies
10h28m

I totally agree with A and B and have further suspected they use leetcode as a means to support a H1B candidates employment prospects (for those who do pass)

mike_tyson
0 replies
8h31m

part of the problem is saturation in the job market.

higher education, even job experience is no longer considered a sufficient barrier to entry.

reminds me when the guy who wrote homebrew failed the apple interview. if i recall.

ironic because they use brew so much internally.

mateus1
0 replies
7h57m

This reads very similarly to consulting case interview questions. 1) It requires a lot of free time beforehand to study the frameworks so it filters intent but also removes those who need to work and 2) it seems objective on the surface but you can essentially pick winners by choosing difficulty and nudging along.

lijok
0 replies
7h51m

I think you’re overthinking it. Hanlon’s razor applies - the industry as a whole is incompetent at interviewing. And to be clear I’m not being smug here - every time I’ve ran recruitment rounds the interview process was a mess. It’s an extremely difficult equation to balance and as an industry we have never made the commitment to figure out a golden standard for how to do it.

kbar13
0 replies
11h12m

yeah i agree that "if you know how to problem solve you will pass" statement is a joke. you absolutely need to memorize most of these problems as you'll never encounter them out in the real world. i think we need to get better at the behavioral side of interviewing - this should be the juice of getting at whether or not an engineer is good. and if they're really good at lying... CEO material? lol.

jboggan
0 replies
8h14m

3) It's also a form of hazing to make the engineers conducting the interview feel better about their current station.

dukeyukey
0 replies
7h35m

“if you know how to problem solve you will always pass.”

See, this is true eventually. But it's _definitely_ not true in 45 minutes.

choppaface
0 replies
10h50m

Engineers typically optimize for their own learning, and the false negative rate can reflect more about how aggressively the interviewing panel wants specific peers versus how much they actually want the job done well.

Suppose there was a SWE union and the union has to create their own reference compensation bands. Would the union again lean towards leetcode or some other standardized test? Or just use years of experience and maybe past projects?

When weighing the “effectiveness” of leetcode interviews, it’s important to weigh that thus far SWEs have failed to effectively unionize despite e.g. the past class-action no-poaches clearly showing C-suites should be paying engineers a larger share.

bena
0 replies
6h55m

We’re hiring for an entry level position where I work. So entry level, that their first month is going to be dedicated to simply learning the framework we use.

However, we do require a base level of competency. We give out a 40-ish minute assessment. Two multiple choice and three coding problems.

And they’re easy. One of them is essentially “John has a 5 gallon bucket and 3 gallon bucket, how many buckets does he have?”. All you have to do is rewrite the clearly labeled circuit diagram as a Boolean expression.

Not a single person this round has passed. Several have failed the simple ones.

So while grilling people on the minutiae of a language or asking them to solve the traveling salesman is not beneficial, neither is nothing.

We should be testing floors, not ceilings

bambax
0 replies
7h51m

I'm not sure there's so much agency in any of this. Most of it is probably cargo-culting. Every software shop wants to be Google, so they do what Google does (or what they think Google is doing). It doesn't matter if they do it well, or understand (or agree with) the ultimate purpose of the process.

If Google engineers all wore pink robes and top hats while interviewing then we'd see that everywhere.

azangru
0 replies
6h6m

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…

I do not know how hiring is done at megacorps; but on the few occasions I participated in tech interviews, we were looking for candidates to join the team that I was on. So, what I was interested about the candidates was how well they were prepared for the kind of work our team does; and how much I would like to work with them. I am sure this second question introduces all sorts of subjective biases; but then, hey, aren't you going to spend countless future hours with that person? At least the first concern incentivised us to make sure candidates were sufficiently competent. BTW, we didn't ask leetcode-type questions.

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

I am not sure I am following the argument. If there is only a handful of companies that pay well, and if you only consider companies out of that list for employment, isn't it reasonable to predict that there will be lots of other candidates who want the same, far more than the number of available positions at those companies. How, then, should those companies select from such a pool of candidates?

aqme28
0 replies
10h16m

I don't buy the analysis on 1). Leetcode interviews restrict the pool of SWEs. You have a lot of SWEs who fail to qualify any more, but the few that do are more coveted and get to command higher wages

JKCalhoun
0 replies
6h8m

Leetcode feels meritocratic. I suspect many people (engineers perhaps more so) don't trust their ability to "size someone up" from 45 minutes of casual conversation alone. Or worse, they worry that they'll have to defend their hire/donthire based on what amounts to a casual conversation whereby they were trying to judge character, affability, confidence, drive, motivation....

Leetcode is lazy, easy.

FabHK
0 replies
3h58m

And you think without leetcode questions the despicable biased interviewer from your example would not be able to hire someone from their Alma mater over someone else?

SilverBirch
79 replies
11h8m

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.

watwut
17 replies
10h39m

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.

resource_waste
11 replies
10h33m

They are not software engineers and it shows massively.

Coming from Real Engineering and making 2x more programming, I lol at people who say there is any Engineering in software.

We are programmers dealing with layers upon layers of abstraction. Knowing to optimize for time by using vectors is more of an art, than a science.

I did do safety critical C code and Assembly which are probably my hole in the whole 'its not engineering'. But javascript/python/backend work: programming.

palata
2 replies
7h20m

Coming from Real Engineering

One related problem I see is that Computer Science tends to be under-estimated by other engineering fields. A ton of software engineers did not study software. They learned to program as part of their engineering studies, and they believe that they learned both Computer Science and their engineering topic at the same time.

I may be biased, but I see fewer computer scientists pretend to be mechanical engineers because they once tuned a PID.

resource_waste
1 replies
3h50m

One related problem I see is that Computer Science tends to be under-estimated by other engineering fields.

If Bachelor of Science computer science grads were that much more extraordinary, they wouldnt be working side by side with non-degreed programmers.

Chem Engineer here, I wrote random forest once. My coworker with a CS degree, all front end work.

palata
0 replies
3h5m

My mistake. If you wrote a random forest once, it certainly means that you should be the CTO of Google. And that chem engineers are all smarter than computer scientists.

lupusreal
2 replies
10h3m

The fact that in 99% of cases "software engineer" is just an aggrandizing title given by management to any and every programmer at their company should put a bullet in the head of the pretentions of this being an engineering field.

ljm
1 replies
7h12m

The term is used ubiquitously in the field of technology and has been for a long time. We also have Tech or Software Architects, and quite obviously they don't do Real Architecture™ or civil engineering, but the concept makes sense.

It's just a job title, arguably one without the protections or standards afforded to chartered engineers, and with an incredibly low barrier to entry. Pretty much the reason we have to do this ridiculous dance with tech tests, LeetCode, and 12 stage interview processes.

lupusreal
0 replies
4h48m

It's just a job title

Exactly my point.

Edd1CC
2 replies
8h28m

Hillel Wayne did a good "study" on this by speaking to a bunch of engineers who moved into software, engineers who stayed in software, and engineers who only worked in software (yes, you can be a chartered engineer in most Western countries including the US and UK purely from software).

The strong consensus was that software is an engineering discipline, and the nitpicking you can have on any particular topic that is/isn't engineering-y can be applied across the board.

But this conversation is totally moot IMO because if you have a bachelors in computer science or software engineering, and a masters in the same discipline, and several years experience, you can apply and become the same chartered engineer from the same association that does "real" engineering.

halfcat
1 replies
5h12m

The strong consensus was that software is an engineering discipline

I see it as a difference in time and stakes.

We’ve built bridges and boats for thousands of years, where the outcome of failure is people die.

This has a lot to do with why it’s easy to estimate the time and cost to build a house, but it’s a rare shaman who can consistently estimate software projects well.

Once we’ve built software for even a few hundred years, we’ll probably have it pretty dialed in, too.

Edd1CC
0 replies
4h59m

We’ve built bridges and boats for thousands of years, where the outcome of failure is people die.

We write software that has killed people due to bugs too, such as Therac-25 releasing too much beta radiation killing patients.

This has a lot to do with why it’s easy to estimate the time and cost to build a house

My parents and in-laws are property developers and I've also been involved in a build; not one was on time or budget. Some are really off budget, beyond the scale software projects that mess up are. In China they've had projects run into the billions and be decades late.

I do understand your points, but this is what I mean when I say you can nitpick any issue with software not being Real Engineering and apply it to other engineering categories too.

But yeah we may have a very different process in 50 or 100 years. I'm only 10 years into my career and it's already pretty different to when I started!

johnnyanmac
1 replies
6h8m

I lol at people who say there is any Engineering in software.

There definitely is. Safety/mission critical code is definately a more rigorous, formal process where you don't just download a library for padding a string (you probably wouldn't use built-in strings anyway on this kind of code).

But I agree that the way most coding works (i.e. move fast and fail often) is completely antithetical to how engineers should work. But there's infinite moneys and almost zero accountability, so who's gonna stop them?

Knowing to optimize for time by using vectors is more of an art, than a science.

that's definitely why I fully agree with calling programmers creatives over engineers. once you get past dead simple problems, no two programmers are going to approach a prompt the exact same way. performance, scalabiliy, documenting, version control friendliness, even ephemeral stuff like code style. coders very much are artists who happen to know a lot of math.

justjash
0 replies
5h42m

As someone who started going to school for Mechanical Engineering and ended up in Comp Sci, I think your last paragraph is what drew me in. So many different ways to solve the problem at hand.

mvdtnz
2 replies
9h36m

Most interview processes I've been through (many, 15 year veteran) involve both the leetcode crap and at least one fit/culture/soft skills round.

valenterry
0 replies
9h13m

Which is insufficient in terms of technical tests.

praptak
0 replies
4h57m

The fit/culture/soft skills/ is actually a fall back to "where did you go to college and tell me about how good you are", which was the pre-leetcode standard.

It is a downgrade in my opinion.

silvestrov
0 replies
8h49m

I think Google suffers from a side effect: only the academic side was valued so maintaining existing systems is considered career suicide.

Most programming work needs common sense a lot more than it needs theoretical algorithmic knowledge.

And almost nobody values good documentation, especially as a competetive advantage.

FabHK
0 replies
4h15m

So how do you find, in an interview setting, good software engineers? (And better than with LeetCode-style questions?)

gumby
13 replies
8h10m

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.

lumb63
4 replies
7h2m

I have come to like this approach reasonably well. My current company uses a similarly simple problem to evaluate candidates. For me, it was a breeze, and I thought we’d be hiring slouches left and right. Once I started administering the interview, I realized that the majority of candidates absolutely bomb this simple question for one reason or another.

It seems that “able to code a simple problem well” is a far less ridiculous proxy for good software engineer than “able to code a hard problem at all”. Much to my surprise.

tnel77
1 replies
2h54m

I have a friend who has interviewed about 30-40 software engineering candidates for his company (small, publicly traded company from the midwest). He said that FizzBuzz alone is enough to filter out 25% of applicants. The next slight more challenging question will axe another 30-40% of candidates. I think Leetcode hards exist to stroke the egos of select software engineers.

ryandrake
0 replies
1h7m

Yea, smaller and medium sized companies just don't have the recruiting infrastructure to weed out the fakers. When I worked in FAANG companies, by the time a candidate got to me, they were pretty good. They went through enough filters and checkpoints and annoying gates that I never really had to do a FizzBuzz equivalent.

When I worked for more medium sized companies, I'd get software engineering candidates who obviously did not even remotely know how to code. Imagine the worst possible software candidate, and then lower your expectation even further. One couldn't even tell me what an "int" was. I think a single "for loop on a whiteboard" question would filter out at least 50% of candidates.

bena
0 replies
4h46m

You test the floor, not the ceiling.

Truth is, I'm never looking for "the best", I'm looking for "good enough to do the job competently". Because we can hem and haw over what is best for hours. And we could disagree with what qualities in what proportion make someone "the best". But we can all generally agree with "could do the job". As I've mentioned elsewhere, we're hiring right now and we have the duality of candidates in our pool.

There's one guy who is just a hard no from at least two people in the group. And that translates into a no from the third member simply because we're so adamant that he's not the guy. And there's another who we're all feeling really solid on. Not "the best", but solid floor and we feel they'll be able to learn.

But being able to weed out people who can't even perform the basics despite having a decent resume is invaluable.

Frost1x
0 replies
5h12m

“Simple problems” often aren’t as “simple” as the retrospectively sound if you consider everything like stress level, mixed mindset of the interviewee (they’re not just thinking about a programming problem, they’re also thinking about social queues, mixing conversing in, peer judgement, and loads of other anxiety inducing factors), etc.

The software industry is notorious for underestimating overall complexity factors, understanding uncertainty, and time to manage them and interviews seem to be no different. So “simple” problems are often good (I agree with you) because they’re actually not so simple for most people when you factor everything in, they’re often reasonably challenging under the set of circumstances.

Meanwhile genuinely difficult problems (in any arbitrary setting and longer timelines) require a whole lot of rote training and reusing little clever idiosyncratic techniques that may or may not be generally useful, so you very often end up with a question lottery on whether you already know how to address the problem in question or not correctly vs having some problem where a reasonable solution and expectations around that can be derived in the time (and environment) it’s taking place. Lots of nonsense.

Aurornis
2 replies
5h13m

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.

Trying to debate the interview format or reject interview questions is one of my hard-stop rejection triggers in interviews now.

The couple times I’ve been part of hiring pipelines where candidates argued about the interview itself and then got hired anyway, they became extremely difficult employees within the company. Arguing about interview questions turned into arguing about every other ticket, code reviews, and every architecture choice.

I’ve had the same experience where we take an actual problem we solved in our codebase and turned it into a small interview problem. Same thing: Some candidates will try to debate the relevance or try to wriggle out of it.

red-iron-pine
1 replies
3h25m

there is a lot of stupid bullshit in most orgs, and things only get fixed by often irritable, unreasonable people. "shut up and do it" was only an acceptable answer when I was in the military.

if the interviewee pushes back and find they don't like the answer, then it's a good signal to both parties.

ryandrake
0 replies
1h11m

This is definitely something that is dependent on the company culture and the personal preferences of the team. I would never want to work with someone who is constantly argumentative over everything, just because he thinks he's pushing back on bullshit.

Sometimes you just have to "document your objection, but do it anyway."

IshKebab
1 replies
5h27m

I agree with all of this. Leetcode questions are fine as long as they aren't actually difficult maths puzzles or brain teasers. We also used atoi/itoa loads and it was pretty much the perfect difficulty.

Though I still do start with a short fizzbuzz-level question because you would be surprised how many people fail that and it makes it way less awkward if you start with atoi and they can't write a loop.

If they fail fizzbuzz I generally just turn the interview into a chat or give them easy questions to practice, rather than say "yeah no thanks", because I feel like the latter is a bit mean, and everyone can benefit from interview practice.

gumby
0 replies
1h5m

If they fail fizzbuzz I generally just turn the interview into a chat or give them easy questions to practice, rather than say "yeah no thanks", because I feel like the latter is a bit mean, and everyone can benefit from interview practice.

It’s kind to politely ramp the interview down in that case but I’ve learned to then cut off any later interviews. It’s a waste of the company’s time and the candidate’s too.

If we were going to have lunch the recruiter takes them to lunch anyway, unless the (now former) candidate doesn’t want to.

giancarlostoro
0 replies
5h29m

That I wouldnt mind. I didnt do a full on CS degree, that never stopped me from being a good contributor to various teams over 8 years. I have learned the best candidates are the ones who like you say are open about how they messed up, and can get along with your team. It takes one toxic dev to ruin productivity for an entire team.

dicroce
0 replies
6h57m

Yeah, that's much better.

EnergyAmy
0 replies
34m

Offtopic, but there's an interesting parallel between making a mistake like that and AI hallucination. In a human, that behavior is a positive signal, but for many people, that same behavior is proof of how LLMs are just a toy that will never rival human intelligence.

kristopolous
11 replies
10h49m

There's an entire industry of bootcamps built on the premise of teaching you how to pass this exact test in like 6 weeks.

And because they ask pretty irrelevant questions, the 6 weeker will do better then the recent Stanford PhD who has been studying a specific problem for 5 years or the multimillionaire who spent the past 10 years building and selling successful software companies.

Those people will fail and your 6 weeker who's never heard of cmake, diff or gdb will pass.

When I see there's leetcode as the hiring process I presume the place is full of bozos because the process actually strongly preferences them.

alexey-salmin
6 replies
10h9m

I believe this is a common myth. I've spend around seven years teaching programming and people who can go from zero to decent problem solving in just six weeks are virtually non-existent.

Either it wasn't a true "zero" but rather they were really good e.g. at advanced math or physics and managed to see some parallels, or it has to be a genius. I'd be very interested in hiring such a person.

kristopolous
4 replies
9h56m

Leet code is not "decent problem solving skills" but it's almost always about three types of programs: sliding window, linked list rearrangement, and BFS.

The code to solve basically all of them look nearly identical after you classify it and the questions asked (what's the big O of this) are also all identical.

It's an extremely narrow and teachable class of problems.

There's outliers for sure but the 80th percentile are basically just the same damn things slightly rephrased. It's extremely gameable and doesn't test the kind of breadth say, fixing a crashing program would show.

Here's a list of 16 https://github.com/Chanda-Abdul/Several-Coding-Patterns-for-... ... That's the 99th percentile.

If you think someone passing that means they can fix the conda bug in your k8s cluster or whatever real problem you have, dream on. It'd be like hiring a cook by quizzing them on the names of kitchen utensils.

alexey-salmin
2 replies
7h54m

Well the thing is, I keep hearing about these people who can't code but excel at leetcode, even that they are mass-trained in some bootcamps, but somehow I never saw one in reality and I interviewed hundreds of people. So I'm kind skeptical this is a real issue.

The other way round (people who code, but can't leetcode) I agree it's an issue. Unfortunately as noted here in comments, cost of a bad hire is much much worse than cost of a no-hire, so it's the price I'm willing to pay.

lll-o-lll
0 replies
6h49m

I think all leetcode gives you is a proxy for IQ in the language of code. If someone excels at leetcode, they should be relatively smart and able to write code.

Excellent! That’s a something, a something you can measure. Back when I was involved in hiring, it was definitely better than not having that (at junior levels).

However, the idea that “IQ is all you need” is so obviously false that I think you need to reconsider. Bill Gates famously, (infamously?), hired for IQ. Microsoft used puzzles as their IQ proxy, and I think leetcode is just a modern variant. Possibly a worse version, as training has a bigger effect.

Bill Gates later would claim that he overvalued intelligence. I would say that intelligence is necessary but insufficient. We would get further, faster, with a quick IQ test and then dig into the candidates experience, communication ability and personality. No need to study!

The FAANG companies all have a line a mile long of candidates willing to put up with any amount of BS for a chance to work for the name and $$. If you aren’t such a company, trying to hire that game changing person for $$’s you can afford to pay is going to require a different approach.

johnnyanmac
0 replies
5h57m

I keep hearing about these people who can't code but excel at leetcode

I think the mass trained at bootcamp is an exaggeration. The best bootcampers are those that use it as an extended education from learning the traditional ways. I'm sure most people here complaining about leetcode can indeed spend 6 weeks there and be interview ready. But few have that time nor spare cash lying around for such a venture. And why should we need to spend thousands just to ace a quiz like it's some SAT?

cost of a bad hire is much much worse than cost of a no-hire, so it's the price I'm willing to pay.

At this point I wonder. Hearing way more stories about "survivors" from layoffs burning out from jobs that keep promising that they'll hire more staff to help out with. When in reality they have a hiring freeze or are trying to offshore the work that ends up needing more time to be fixed.

The stalls in a no-hire aren't just costing money in the lack of productivity, it's costing currently working employees who are doing 2,4, 8+ jobs without any meaningful increase in role/salary. It's not sustainable. You're draining a little bit of blood from a rock, but the rock is clearly starting to crumble.

CoastalCoder
0 replies
6h4m

Leet code is not "decent problem solving skills" but it's almost always about three types of programs: sliding window, linked list rearrangement, and BFS.

I could be wrong, but I think dynamic-programming problems belong in that list.

batshit_beaver
0 replies
9h55m

It's not "decent problem solving" that these folks demonstrate though, it's the ability to grasp and regurgitate common DSA patterns that show up in most leetcode style interviews. Does this ability make these people highly desirable hires? Should you hire such people over engineers with more real world knowledge, but who don't want to spend the time learning or practicing leetcode?

CarpaDorada
2 replies
10h5m

Well said, like IQ tests, if you train for it you're better at it, but it the meaning of the results is dubious.

Recently I failed the first round of a fintech analyst position because I didn't complete the 9 undergrad (or high-school, in certain talented schools) math problems (I have a math PhD) in the 1 hour time frame. In retrospect, I should've cheated using computer/online assistance, and my true failure was my unwillingness to cheat. Not because fintech analysts are cheaters, but because the testing process is nonsense, so recognizing that, one should cheat it (indeed, an analyst mindset!) I'd rather be jobless than to adopt that mentality though. (and in fact I am, the only job I was able to find was a minimum wage service-type job, it can't even pay for daycare, I'd rather raise my child on my own while wife works thank God.)

We have high-interest rates and global crises resulting in companies not hiring while simultaneously governments give orders to news media to tout the strong economy. Ineffective hiring practices will always exist, but people don't complain when jobs are available; you only see this type of discussion online when things have gone sideways.

kristopolous
0 replies
9h53m

If you want to work, you just need to find the right job.

CoastalCoder
0 replies
6h8m

... and my true failure was my unwillingness to cheat.

Integrity is really tested when it costs you something. I'd call this a true win.

(I recognize there are dire situations where cheating might be warranted. I hope you're not there yet.)

lr4444lr
0 replies
7h42m

Not my experience at all. Ask a bootcamper a slight variation on a problem they're clearly doing from memory and they fold. Ask a solid CS person, and they usually get intrigued, and dive right in.

NhanH
9 replies
10h8m

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.

breckenedge
5 replies
5h38m

In my years of hiring experience, it doesn't hold up. I've hired folks who could leet code all day long, but couldn't develop a feature from scratch, or figure things out without enormous hand holding. I want to hire problem solvers who also know how to code. I stopped doing leet-code interviews about 7 years ago. By all means have people code in interviews, but don’t do leet code.

FabHK
2 replies
4h18m

How do you test whether they're problem solvers that also know how to code, without leet-code interviews?

breckenedge
1 replies
2h49m

Giving people real world problems and pairing with them on finding a solution.

rented_mule
0 replies
33m

I'm retired now, but I used a variant of this that worked well for me. In my experience, much of what we do as engineers is learn new tools and application domains and apply what we learn to solve problems. So I wanted to test how good a candidate is at leaning and whether they appear to enjoy it (good and enjoy often correlate).

We would work together at the whiteboard, with me teaching them the basics of our application domain and our internal distributed computation framework. Then there were a series of 5 increasingly difficult iterations we'd work through. First, do a simple calculation. Now there's a need for a more difficult computation. And an even harder one. Then explain that it needs to run over billions of log lines, and it's I/O bound, so let's make it faster. Finally, a problem that requires them to probe me deeply about the nature of the data and only needs a hand-wavy answer (calculate a median in a single pass with limited memory - not too bad once you extract from me that the samples are all integers between 0 and 500). To the candidate, this looked like iteration driven by evolving requirements, not 5 interview questions.

I mostly let them drive, but I jump in now and then to keep things on pace. And I would try to answer any question the same way I would as a teammate / mentor.

They don't need to get every problem right. The increasing difficulty is designed so that almost everyone gets something right and something wrong (< 1% gets all the way through the last one). That's an opportunity for me to give supportive feedback to see how they respond. The best responses to feedback yielded something like "oh cool, I can also use that over here to simplify the code". The worst was someone insisting that you can flip the order of addition and division without changing the answer (i.e., order of operations doesn't matter), me saying "I think it does matter, try doing 1/2 + 1/4 in different orders", and them saying "no I have a math degree, I know what I'm talking about."

What they do need to do is be able to solve problems collaboratively, extract learning from an eager mentor, and extrapolate from those learnings to solve problems. The best candidates start finding trade-offs across the application domain / tech tooling boundary that I haven't even brought up.

One of the downsides is that it takes a while to calibrate as an interviewer, and that calibration is not entirely transferrable across interviewers, as candidates will respond differently to different interviewers. I did this interview thousands of times (my record was 14 times in one day, and frequently 20+ times a week - we were scaling an org from ~50 engineers to over 1,000). I never stopped learning about signals I was seeing, but I was mostly calibrated after a few dozen candidates. Leet code calibration is much more transferrable, but what use is that if it's not measuring what matters?

One thing that I think leet code interviews get very wrong is that interviews involve two sides trying to evaluate each other. Wearing people down with leet code is not a good pitch for your work environment. Many candidates told me at the end of my interview that they were shocked at how much fun/educational an interview could be, and many hires said that this interview style was the reason they accepted our offer over more lucrative offers, because they felt they would learn more and have more fun with us.

Jensson
1 replies
3h0m

Were those juniors with no experience developing features? Leetcode doesn't test if they have experience, you need to check both if you want someone that can do everything.

Someone who does well on leetcode is usually easy to teach so they will become good/great in a year or two, but if you don't have that time then go for leetcode+experience just like everyone else is.

breckenedge
0 replies
2h46m

Leetcode deselected too many good experienced candidates, which is really who I prefer to hire. I have hired good leetcode juniors that did not improve and are no longer working in software.

Aurornis
2 replies
4h57m

if you also believe the other myth in hiring: most people applying are not qualified for the job.

Depends where you’re looking in the hiring pipeline. If you’re looking at raw applications submitted to a publicly listed job posting, I can say without reservation that the majority of candidates are not qualified. The pre-screening candidate pool is extremely bad on average, especially for remote job listings. Some people spend all day clicking the apply button on every job listing they see.

Your post constrains another misunderstanding about the hiring process: The goal isn’t to hire the first person through the system who is good enough to pass some arbitrary threshold. The goal is collect a number of candidates and hire the best one. People hate this reality, but it’s true.

NhanH
0 replies
2h15m

Your post constrains another misunderstanding about the hiring process: The goal isn’t to hire the first person through the system who is good enough to pass some arbitrary threshold. The goal is collect a number of candidates and hire the best one. People hate this reality, but it’s true.

I definitely do not have any misunderstanding here, and my description of hiring is the same as what you wrote, just in different phrasing: after a period of time, the company has to pick a candidate, presumably the best one by their interview signals.

I am disputing the standard claim of "it's better to have false negatives than false positives" by pointing out how that mindset does not work: since you have to choose someone anyway, the whole "avoiding false positives" might not be a thing at all

FabHK
0 replies
4h24m

and hire the best one

Or rather: the best fit. You don't need a Turing Award winner to clean up your website.

logicchains
7 replies
10h34m

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.

concordDance
6 replies
10h15m

I disagree with this. I can solve the majority of leetcode hard problems in under an hour despite not having seen them before and I'm far from the smartest person I've met.

batshit_beaver
3 replies
10h1m

Congratulations, you've memorized leetcode patterns. Proves nothing beyond that (except that you've also had the time recently to practice leetcode).

concordDance
2 replies
6h38m

I have never practiced leetcode puzzles or memorised solutions to them. I don't understand why you jumped to this conclusion.

kirth_gersen
1 replies
5h5m

Probably because you said you "can solve the majority of leetcode hard problems in under an hour". That could easily give the impression that you have practiced them. If you haven't practiced them, then how do you know you can solve them?

concordDance
0 replies
2h42m

Sample of 5-6 I tried for fun. Along with a handful of similar puzzles from other places.

triyambakam
0 replies
8h17m

Under an hour is... not enough time for an interview. Needs to be under 20-30 minutes given that most interviews are 60 minutes and the other 20-50% is taken up by other conversation.

djeastm
0 replies
5h7m

I don't know you or the people you've met, but if you can do this without studying the questions before and the solutions are performant, then I would put you in the "very smart" category

hiAndrewQuinn
5 replies
10h59m

Bingo. A good hire is a windfall, a bad hire can be an existential threat to the team or the entire company.

KaiserPro
2 replies
5h47m

a bad hire can be an existential threat to the team or the entire company.

Totally, but leetcode wont filter them out.

Incompetent is fairly easy to navigate around, pathological bastardness is impossible to work past. I know that some companies use psychometric tests, but they are not based in anything remotely scientific, but are also super easy to game.

Aurornis
1 replies
4h38m

Totally, but leetcode wont filter them out.

Coding challenges won’t filter every pathological bad hire, but coding challenges do catch a lot of bad hires.

LeetCode shouldn’t be the entirety of the interview. It’s just part of it.

KaiserPro
0 replies
1h12m

but coding challenges do catch a lot of bad hires.

leetcode doesn't catch bad hires, as someone whos done a lot of interviews, we could easily catch "bad" coders with a very simple whiteboard test or a "look at this code and tell me what you think"

but people being bad at code aren't the company killers, its the toxic people who are "good" at coding that do. They can be very good at these kind of tests, but are absolute shites to work with.

I think we actually agree more that I let on, and you are right that coding tests should only be a part of the interview process.

beej71
1 replies
4h49m

But you hired them at-will, right? The bad hires I've seen that are existential threats were only there because management refused to fire them.

FabHK
0 replies
4h23m

Depends on the jurisdiction, needless to say. I've interviewed in London, say.

fzeroracer
5 replies
10h53m

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?

mvdtnz
4 replies
9h35m

How do you cheat at live coding?

ljm
2 replies
8h43m

I’ve interviewed people who wore an earpiece and were fed instructions on the fly, and also people who kept their cameras turned off to try and hide the fact they were getting assistance. You started picking up on patterns like them repeating your questions, or spending a lot of time in silence (asking their friend a question) without any other communication or activity on the screen. Like they weren’t there.

shitlord
1 replies
6h45m

I once interviewed someone who was on a call with someone but messed up their audio feed. I could hear the third person but the person I interviewed could not.

mrbombastic
0 replies
5h21m

That is hilarious

lokhura
0 replies
7h27m

Nowadays it's easy by using undetectable interviewing AI tools. See:

- https://ultracode.ai

- https://interviewsolver.com

Well worth it. Highly recommend these tools to play the dumb interviewing game.

Suzuran
1 replies
5h31m

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.

FabHK
0 replies
4h17m

The latter would be a false-positive, which by assumption is both expensive and rare.

johnnyanmac
0 replies
6h19m

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.

grishka
0 replies
9h9m

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.

drewcoo
0 replies
10h28m

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).

But it's entirely pointless.

koliber
16 replies
10h48m

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.

watwut
10 replies
10h37m

Senior Java developers who could not import HashMap without looking it up.

Eclipse does not without me having to even look at it. IntelliJ does the same. In what situation these people had to import it by hand? They had no ide available or what?

koliber
3 replies
9h23m

No IDE, specifically to test basic ability. We use a web-based shared editor, that has syntax highlighting, and auto-tabbing, but specifically no auto-complete nor auto-import. Sometimes, it's just pseudo-coding, either in a conversation, or on a whiteboard.

Even though Eclipse does it, I'm sure you know where HashMap lives. Some people are compile-and-pray type devs. They lean on auto-complete for everything, not as a productivity tool, but because they don't know how to do even basic things. We don't want those on our team.

vundercind
0 replies
9h4m

Jesus. The last time I could maybe have passed something like that was 20 years ago when I’d only worked in one language and had only recently stopped writing code in MS Notepad.

[edit] oh god it’s closer to 24 years. The time, how she flies.

tiew9Vii
0 replies
7h27m

Senior Java developers who could not import HashMap without looking it up

No IDE, specifically to test basic ability. We use a web-based shared editor, that has syntax highlighting, and auto-tabbing, but specifically no auto-complete nor auto-import.

I can sympathize with the candidate and think the test is poor and not surprised people had to look it up.

I've been doing Java since early 2000's and off the top of my head can't tell you what package HashMap is in without looking it up except it starts with `java.` something, probably. I type `HashMap` in my IDE, hit auto complete. I haven't needed to remember the exact package name since early 2000's when I started coding so don't know it, no need to, why waste space in my head for it. If there's a second HashMap class available on the class path I can tell you the one I want from the suggestion list.

You're trying to test someones memory on something they haven't needed to remember for decades now, knowing a specific fully qualified path to a class/what package it is in isn't a useful test. Knowing what a HashMap is and how to use it is useful.

Enable auto complete/import. You don't have it disabled for your currently employed devs and they'd not function well without it and probably fail the same test.

david_allison
0 replies
8h41m

Even though Eclipse does it, I'm sure you know where HashMap lives.

Why?

----

I'd struggle. It's a trivia question as it has no bearing on modern Java development

Modern IDEs both collapse the import section, and auto-import on the fly

The only reason I'd see the line is:

* Looking up documentation: very rare

* Conflict on the import - unlikely

* Code Reviews - skimmed over

batshit_beaver
3 replies
9h44m

Google used to ask people to write code in a Google doc. No tools allowed.

Facebook to this day disables intellisense in their coderpad interviews.

It's fucked up.

kristopolous
1 replies
9h4m

It'd be like interviewing a chef and you give them twigs and a flint rock to roll their own stove.

I don't get what these tests are trying to show.

Breadth? Depth? There's other ways. Give some complicated code that touches a bunch of things and have them work with that.

emblaegh
0 replies
8h25m

From my interview at facebook some four years ago, I am inclined to believe they disable intelisense so the candidates do not get tangled up in the minutiae of language syntax, function arguments, etc. and instead focus on the algorithm they are trying to write.

Der_Einzige
0 replies
6h14m

I actually got a google doc interview where they asked me to code up a hyperparamater optimizer from scratch. I couldn’t believe that they asked me to code in a google doc. I should have stopped the interview right there.

xxs
0 replies
5h32m

If I am looking for a senior java developer I absolutely expect that they know about java.util and java.lang classes w/o any reference whatsoever. Heck, I expect they know why java.util.HashMap is subpar, or even the common hash mul-and-add const 31 is suboptimial.

gjadi
0 replies
10h9m

And now any editors with LSP integration do the same.

raincole
2 replies
7h50m

To you, someone who doesn't know which namespace HashMap belongs to is like someone who can't do 3 * 7...?

Not sure it's a satire about interviewer stereotype or...

johnnyanmac
1 replies
5h9m

in all fairness, Java.util isn't some esoteric namespace. But the fact that you can do years of Java without touching core Java libraries (e.g. maybe you're highly reliant on DI, or have a proprietary library at work) does make it hard to properly gauge with.

I'd say it's a fine question if interviewers stopped treating their technical tests like trade secrets and just said "okay, interview is next week, make sure you know the some the basic built-in Java namespaces and yadda yadda". I can understand wanting to avoid googling, but consider the situations:

- someone truly out of their element won't pass, study or not

- someone who knows the stuff after a quick refresher is a perfectly functioning programmer, it's something all programmers do on the job.

- someone who truly knew nothing but could pass a test in a week is clearly a fast learner, the perfect candidate for many roles with changing demands

- and ofc the best interviewers aren't impacted. Simply more confident.

unless you truly need an expert/principle level engineer in a domain to solve problems (and let's be real: few companies do), I don't see many downsides to this approach.

SCLeo
0 replies
4h51m

I think most people just start typing "HashM..." and trigger auto complete, and hit tab to import and auto complete HashMap.

xcv123
0 replies
6h48m

Memorization of the hashmap package name is the stupidest Java programming test I have ever heard of.

lordnacho
0 replies
5h28m

could not import HashMap without looking it up

I think this is silly. On its own, you could imagine a kid in college who had just seen an example of HashMap in Java remembering what the import was.

But this isn't the only thing you need in a program. There's going to be many things that are trivial that your program needs, all of which would need to be memorized in your world.

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.

The strange thing about this is, I would expect you to know how to calculate 562 * 1041, in other words the principle of how it works. You might mess up the calculation, but you can't mess up the idea of how long multiplication works. In that context, it is perfectly permissible that you have forgotten some entry in the times table, like 3 * 7.

After all, you are a programmer, you organize calculations, you do not work them out yourself, the computer does that.

If you need to study graph-traversal algorithms in order to pass, it's probably too leet.

This I agree with. You should know where to find the solution to whatever the issue is, you don't need all the solutions to hand.

willtemperley
12 replies
10h46m

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.

was_in_amazon
9 replies
10h35m

Ex Amazon here. I never heard of leetcode style interviews at Amazon.

was_in_amazon
4 replies
6h2m

So what? The log parsing thing is a reasonable question, not some obscure bitshift find-a-binary-paindrome hack.

willtemperley
3 replies
5h35m

The so-what was just to confirm that Amazon do leetcode interviews, contrary to your statement.

was_in_amazon
2 replies
5h15m

If you call any coding test "leetcode like interviews" then YES

willtemperley
0 replies
5h4m

You're slowly getting it

johnnyanmac
0 replies
4h52m

I'd consider

- a coding test in a short time frame (30-90 minutes)

- implementing some singular function that expects a singular answer

- expecting time/space complexity optimizations, often those not naively thought about in said short time frame

- in synthesized test environments (as opposed to something representing a real world environment)

to fall under "leetcode like interviews". Log parsing can fall into either camp depending on the prompt. Once it's asking you something esoteric like to locate a timestamp in Log(N) time it starts to fall into Leetcode territory.

Der_Einzige
1 replies
6h12m

I literally interview on purpose with Amazon to waste their time (revenge for them mistreating my partner). After at least 10 full onsites, I can tell you that Amazon uses leetcode style interviews in every single one of those onsites.

Feels nice to come into their stupid contrived behaviorals and not even care about the “Star” method or their stupid leadership principals. I even straight up told them in one interview that their principals were stupid and victim blaming. I’m shocked that they haven’t blacklisted me yet - and doing so would be nice because Amazon recruiter spam is actually quite annoying.

was_in_amazon
0 replies
6h7m

I was in Amazon years ago and there wasn't a standardized set of questions. At the time I never heard of teams using leetcode style questions - things went downhill I guess.

upmind
0 replies
9h48m

As someone who's interviewed there and received offer (though for internship), for entry positions, internships + their lowest level of engineer (don't recall the name), I can confidently tell you they mainly use leetcode with some Amazon principle questions too

ojhughes
1 replies
10h15m

I would probably have a huge mortgage sitting in rainy ol Blighty

Feeling a bit triggered by this - but also curious how you escaped :)

willtemperley
0 replies
9h44m

Haha it's a lot easier than people imagine - if you have no dependents, leave your stuff in storage or with your mum and get on a plane with some clothes, a laptop and £15k income or savings per year. Personally I bring climbing gear too. 500 quid a month gets you an epic condo in SE Asia with 500Mbps symmetric (I'm talking city centre with rooftop infinity pool). Visas can be complicated but it's far easier here than Europe. They only managed to destroy our freedom of movement in Europe, not the rest of the world.

apples_oranges
12 replies
11h5m

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)

boffinAudio
7 replies
10h44m

I've done the same thing, at a games company well-known for its perks and benefits, but also its crazy production schedules .. I thought I wanted to work there, and up until about half-way through the interview, I did, but then out came the whiteboard and in came the peers to see me implement basic things in pen, and actually it felt like a ritualized mobbing, because as I progressed through their challenges, things got more and more antagonistic and downright rude, and I realized they were testing me to see if I could deal with vitriol and hostility while producing technically minor results .. I simply stopped the interview, stood up, and said "I've made my decision, I don't really want to work with you guys now that I've seen how things are done, thanks for the opportunity and sorry to waste our time" .. and walked out.

The CEO chased me out into the parking lot and begged me to tell him what I saw and why the interview went awry. He was legitimately shocked that an interviewee could make such a decision, mid-interview .. All I could tell him was that it wasn't going to be a great fit, the culture didn't seem aligned, and the people who were brought in to the interview seemed desperate and hostile to each other - and that simply wasn't the way I had hoped that the company operated.

People forget that job interviews are a two-way street.

I realized that day that I have every right to inspect all aspects of a company that I might work for, and that I don't really have to make compromises if I see something negative during the process. It was the right decision because the very next day, at another competing firm, I met folks who have continued to be good, close friends and colleagues, whom I actually really enjoy being around.

This profession is fun. But when the fun gets farmed and exploited, its enslavement like any other.

CoastalCoder
2 replies
5h54m

I realized that day that I have every right to inspect all aspects of a company that I might work for, and that I don't really have to make compromises if I see something negative during the process.

I think this is really contingent on your negotiating position.

I've been unemployed for over a year. The lower my savings get, the less picky I can be about potential employers.

weatherlite
1 replies
4h53m

Hell. What area do you live? Are things that bad or were you just too picky?

ryandrake
0 replies
25m

I've been ~2 months from missing rent having to move my family into a van. At that level of desperation, you're willing to stomach a lot of non-ideal companies. If I didn't get that (as it turns out, terrible) programming job, my next step would have been to try to get a job stocking shelves at Home Depot.

davedx
1 replies
10h22m

Yeah games company interviews can be hilarious.

I had an interview for a company in the south of England a long time ago. The first half went okay, then in the second half the whiteboard came out, and I was asked to "implement C++ object oriented method dispatch in C" with a chunky marker pen. I mean, it's not exactly a rocket science question, but it's not easy either (on a whiteboard, with a chunky pen), and in the end it just felt like it was some weird hazing rather than any test of my actual software development or programming ability.

I stayed in the interview, went home, never heard from them again. I ended up getting a job at a different studio that had a slightly saner technical interview, and after I started there, I heard the first place had gone bankrupt! Sometimes you just dodge bullets...

CoastalCoder
0 replies
5h50m

Depending on the specific job role, I actually like that interview question.

It tests knowledge of the C++ vtable and function pointers, which is probably a good marker for intermediate-level C++ knowledge. Especially for debugging some heinous bugs.

Phelinofist
0 replies
10h8m

Fortunately I never had a leetcode style interview. But I once interviewed at a place a friend worked at and they needed someone to bring their development up to speed (re-architecture, establishing processes, technical lead) and he recommended me for that. The interview partner was their new CTO (joined the company 2 months prior). From the start of the talk he was acting almighty and acted like I should be thankful for the opportunity I have been given. He was asking misleading technical questions. I was super confused first because I assumed malice first ("He is trying to trick me!") but as the interview continued I figured out that he really had no clue what he was taking about. Later during the interview I should describe my experience and I told him about the retail app suite I was the lead dev of for about 2y (POS software + back office + SAP interfaces). He proceeded to tell me that sounds quite nice, but the previous company he worked at did one million transactions per month - hah, eat that stupid peon! I was confused yet again, because that is really tiny? I told him that the project I led did that in a day. He accused me of lying. At that point I politely pointed out that we are not a good fit and wished him the best. 30 mins later my friend called me to ask what happened. The CTO apparently told everyone how poorly I behaved and how measly my skills are. When I told him about what really happened he was quite shocked. He talked to the CEO who did call me next day. I told him a sugarcoated version of what happened. A week later the new CTO was gone. According to my friend he also behaved to other employees in a similar way. The whole story is bizarre.

JKCalhoun
0 replies
6h4m

it wasn't going to be a great fit, the culture didn't seem aligned

I laughed when I read that - turning around the same BS they spew for why they claim they didn't hire someone.

weatherlite
3 replies
9h29m

Done a similar thing in a Zoom interview. I had a horrible hard Leetcode question, was completely stuck and was getting nowhere (neither did the interviewers seemed keen on helping me out). I told them hey thanks this isn't my day I want to quit the interview - at this point they really tried hard to make me stay for the rest of the time. I think if a candidate wants out - you should let him.

CoastalCoder
1 replies
5h57m

I'm curious what motivated their attempts to keep you there. I can think of several possibilities.

weatherlite
0 replies
5h13m

I was referred to this company through a past colleague that was currently working there so it's possible they didn't want to bum out this person, but I actually don't think that was that - they looked genuinely surprised and a bit shocked when I wanted to stop which I can understand, it's not something that happens often at all. I think they just felt it was 'wrong' for an interview to be stopped short by the candidate and tried to rectify the situation.

6510
0 replies
1h3m

if I may be so rude to ask, what was the question?

fvdessen
11 replies
11h16m

The unfortunate reality is that If you don't do this you'll hire people who can't program

esafak
1 replies
11h0m

This is so true. You see it when you are on the hiring end. There are all kinds of people out there. I fully expect every hireable programmer to be able to set up a class, instantiate it, and use types. A lot of people are not even at that level. They know just enough to be dangerous.

Der_Einzige
0 replies
6h7m

The overwhelming majority of AI code is written without any concept of objects what-so-ever.

Wilya
1 replies
10h56m

It depends how it is done. I used to think the same way, and I would never hire someone without having seen them program live.

But having experienced leetcode-style interviews on the candidate side, it's clear to me that they are no longer about figuring out and coding a solution on the spot. Interviewers expected a solution FAST, and to match that you need to have studied and learned the answer beforehand.

raverbashing
0 replies
9h24m

Interviewers expected a solution FAST, and to match that you need to have studied and learned the answer beforehand.

Yeah this is the real BS behind the tests. Good interviewers help you manage and try to find a solution. Not just "answer is binary tree"

throwaway346434
0 replies
10h24m

Nonsense. Ask a candidate to add a feature to an open source product similar to your own, and share the PR. Ask them to do it with a time box. Guaranteed better results.

mjfisher
0 replies
11h7m

There's a difference between asking someone to invert a binary tree, and asking someone to sum up a list of numbers. The latter finds the people who can't code much more quickly!

kristopolous
0 replies
8h55m

Substitute it with something real and you're good to go

easyThrowaway
0 replies
10h42m

...Instead you end up hiring people who can memorize every test from leetcode.com without having the slightest idea on how or when to use those data structures and algorithms in the real world.

bargainbin
0 replies
10h40m

My company does this and hired thousands of people who can’t program so I don’t think it’s that black and white unfortunately.

__alexs
0 replies
10h57m

Programming is not a binary. Leetcode does almost nothing to help you level people on the majority of real world coding problems people face.

AnimalMuppet
0 replies
5h37m

No. The unfortunate reality is that if you don't do something - if you don't find a way to test whether they can actually program - then you will hire people who can't program. You need something.

But that "something" doesn't have to be leetcode. There are much better (and less abusive) ways of doing the same thing. All it takes is a programming problem that they've not seen before. That's it.

boshalfoshal
11 replies
11h13m

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.

varjag
1 replies
10h13m

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)

I'm sorry but it's incredible hubris to think you'll come up with say Dijkstra's algorithm during the interview from the first principles. The only reason you can do it is you studied it before.

kristopolous
0 replies
9h30m

Right. I look at this like a Bayesian

Chance of someone

- seeing it before: 10%

- being a liar: 5%

- being the next Claude Shannon: 0.000001%

So someone coming up with the right answer and claiming they've seen it is useless.

Right answer and claiming they hadn't seen it is basically a guaranteed liar.

You can use it to filter out the liars I guess. But you'll also filter out your Claude Shannons as well.

Either way, it's a dumb test unless you're genuinely getting a steady stream of Princeton and Cambridge magna cum laudes waltzing through the door and can reliable bump the last two priors by a few decimal points.

poisonborz
1 replies
11h6m

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)

Leetcode questions can by definition never come close to real life problems - they are simply out of context. Working on a project even a few weeks will grant a smart person any insights he might actually need. The kind of out of the blue puzzle problem a leetcode presents is more akin to crosswords in old leisure magazines.

dep_b
0 replies
6h20m

It took Dijkstra an hour to come up with the Dijkstra algorithm. Why would you expect me to do better?

cranium
1 replies
7h21m

I know people in the four quadrants of {no-hire, hire} x {would not pass LC, would pass LC}. In my world, conditioning on [would pass LC] does not improve the hire odds.

Even worse: it misses out on the hire people with no formal training too busy to waste time on skills with little use outside of the interview (in the real world, they'd use a library).

beezlebroxxxxxx
0 replies
6h2m

Spend enough time around hiring teams or recruiters and you'll see that 99% of them are simply very bad at hiring. They put almost no effort into a search. They can definitely find someone. But finding someone that is hired for their actual ability to solve the problems that the shop or team is working on is rare. Leetcode is just a way of culling the herd. The idea that it somehow reflects the requirements of the job are a useful fiction to obscure how little effort most teams and shops actually put into hiring.

weatherlite
0 replies
9h32m

1. Do you work hard (i.e a person who studies many problems, memorizes solutions, and regurgitates then)

Most people applying already have a job. And if they work hard its actually quite uncommon for them to have ample energy to do leetcode questions on the side. So you might get the opposite - you'll get candidates who aren't great performers in their current roles but used their extra energy to grind leetcode.

throwaway346434
0 replies
10h27m

Yeah, no. Show me your GitHub commit history, and point out where you used some leetcode magic. Should be easy, right? Like every other week you'd be using it? Or... is 95% of code somewhat boring, and ideally maintainable?

kristopolous
0 replies
11h2m

It's skills that a 4-year college student learns at approximately 19 and then promptly does not use for their next 50 years of actually building things.

It leaves out looking at the engineering skills it takes to put something past the finish line on budget.

It's at best, an adjacent sideshow and at worse a proxy for ageism to preference people closer to 19 and less capable at getting quality software out the door.

And maybe that's why the industry has such a damn hard time getting quality software out the door.

Maybe.

Here's a far better idea. Give them a broken build or crashed code or some other failure and ask them to fix it. If they can navigate around a system, diagnose a defect, find the cause, offer a patch, and match the coding/commenting style etc, that's an actual player you need, not someone who can still solve an algo question from their CS101B midterm exam at 37.

This version can go deep as well. You can have separate branches and an issue tracker, maybe with the conversation of the bug already going. Maybe the comments have a patchfile that needs to be manually applied. Maybe the patch has a new bug in it ... Perhaps it's a red herring and addressing a similar but unrelated issue. Maybe it's a closed bug and a regression and nobody wrote a unit test for it. Maybe the unit test is there and it's up to the candidate to discover it or the unit test is out of date, buggy and useless.

This is the real stuff.

Get them to communicate after. Saying something like "the unit tests were broken" versus "I was unable to understand how to get them to work right so I moved on" ... That's a huge difference in attitude - only one of them is a team player.

johnnyanmac
0 replies
5h35m

And realistically, companies index less on leetcode skill as you become more senior or apply to more niche roles.

when does this start? I'm over 8 years in and I'm tired of being told to make a dang NxM Bingo solver in 30 minutes.

Leetcode is not meant to magically select for the best engineers.

I'd agree with you in 2022. in 2024, I'm being way more filtered out for questions that I get right but didn't solve fast enough, or with zero hints. I was never a leetcode savant (too many other things to study for, and LC is maybe 20% of my interviews) but I don't feel that much worse than 2 years ago. Companies just have sky high expectations and are on a bargain bin for 15+ year roles paying 5 year salaries.

fzeroracer
0 replies
11h4m

1. Do you work hard (i.e a person who studies many problems, memorizes solutions, and regurgitates then)

This isn't working hard. And you are competing with the people that are working smart. Such as people having a separate computer/screen to either look up the answer to a problem or ask an LLM to regurgitate some code you can transcribe. It selects for people that are dishonest.

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)

See above. A lot of the problems have nothing to do with real world coding scenarios. Do I need to pull out memoization and know how to work with grammar rules off the top of my head? Or the functionality of quad trees and how it applies to partitioning? No; I've literally never used them in my career and likely never will. What I do need as a software engineer is understanding the high level concepts and when to apply them and refresh myself on the use case when and if appropriate.

begueradj
10 replies
7h42m

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.

pprotas
5 replies
7h5m

Age does not hinder you in solving leetcode problems

vgalin
3 replies
6h26m

But the older you are, the more likely it is that you have built a family and have children and responsibilities outside of work. You cannot necessarily afford to spend time studying (problems untied to the real world) as much as someone younger I guess.

weatherlite
1 replies
4h47m

40 year old here.

I don't think its strictly a time issue, its an energy/motivation issue. 40 minutes of practice a day for a month or two should be sufficient for someone to solve/go over dozens of Leetcode questions. We all, literally all, have that time to spare otherwise we wouldn't touch our phones or ever watch T.V and yet most of us do.

But I don't disagree with you completely. I think the older you get, the more mental resistance you have to do the grind to become good at Leetcode. It just sucks that after 13 years of programming and accomplishing quite a few things I have to do this shit all over again just to get another job that's pretty much the same as I'm doing now - and this knowing that it sucks so bad - that you are reduced to a Leetcode monkey with all your experience, is quite a tough pill to swallow at 40. I am also a bit less inclined to look for a new job in general - I have a kid, have a comfortable job with stable income (well, relatively speaking its stable) etc etc. Sure I can go try chasing FAANG salaries but the reality is for me its psychologically much more comfortable to stay where I am and it may also be sensible when calculating the risk in moving jobs.

ryandrake
0 replies
5m

Yea, the older I get, the less willing I am to jump through hoops, supplicate and prostrate myself in front of a company I want to work for. At 22 years old, I would have thought nothing of studying 2 hours a day, 7 days a week, for 4 weeks to get a job. Now, no way. And I believe this is a common trait among employees my age.

So if a company designs an interview process that involves all this hoop jumping and whiteboard hazing, they are deliberately adding bias against older, more experienced candidates.

dep_b
0 replies
6h12m

The reason I’m faster than younger developers is that I go into the right direction immediately.

If you present me with an unknown problem that requires deep concentration a younger version of me might stand more chance.

I really suck at leetcode when tired.

gorbachev
0 replies
6h1m

The older you are, the more you realize leetcode is like 0.0000001% of what anyone does at an actual software engineering job, and you optimize to ignore that bullshit entirely.

There are exceptions, of course. But for a very large majority of software engineering jobs leetcode is completely useless.

slavapestov
1 replies
5h59m

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?

weatherlite
0 replies
4h52m

Most of us. We're not computer scientists, we're programmers.

JKCalhoun
1 replies
5h56m

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?)

bradlys
0 replies
3h24m

Where are you working that it’s white males?

80% of my colleagues are Chinese and Indian. This is usually the case at most of my jobs that aren’t early stage startups.

pkos98
8 replies
10h32m

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.

resource_waste
6 replies
10h27m

All the talk about diversity, but no diversity of thought. Only LC chasers. I genuinely believe this decreases innovation massively.

Nice belief, but good luck proving it.

I imagine the people grinding LC are harder working/more innovative than people who watched TV instead.

dkdbejwi383
1 replies
5h52m

Why are the two choices LC or TV? What about those who have a family, hobbies, etc?

resource_waste
0 replies
3h54m

The average American spends 3-4 hours per day on TV or Internet entertainment.

Sooo... its not much of a leap.

adamors
1 replies
9h58m

Yes, those are the only two options. I'd rather spend time with my kids than grind for 4 hours a day to get ghosted after the 5th round of interview.

dfadsadsf
0 replies
8h40m

If you spend your free time with kids you are outlier. Average adult in US watches 3 hours/day of TV (stats which frankly amazed me) which if spend more productiveky is more than enough to grind for interview

dsotirovski
0 replies
10h17m

I imagine the people grinding LC are harder working/more innovative than people who watched TV instead.

I suspect the original author of the article that spawned this comment thread prepared for the interview somewhat rather than watching TV instead - and still got sickened of the LT style interview.

drewcoo
0 replies
10h1m

You were on to something with the GP's unprovable assertion.

Then you provided your own false dichotomy and the argument went all wrong.

kristopolous
0 replies
8h51m

They're certainly proxies for other things.

Kichererbsen
7 replies
11h12m

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...

kristopolous
2 replies
10h32m

I'd give a bit of guidance. This can go so many ways. I can see many right but totally different answers.

In any interview, I kind of presume that the interviewer has a "perfect answer" in mind and is playing some game where I basically need to guess what number they're thinking of.

I'd make it clear that anything is ok. Just go some direction

codegladiator
1 replies
10h30m

Oh definitely. I start with very basic syntax level changes. I want to hear the candidate say "switch case or if/else tree" within the next 20 mins at the least (for SDE I).

And the problem can be scaled to any complexity. Distributed/Design/Data Storage

kristopolous
0 replies
10h22m

I'd actually ask under what conditions leaving it exactly as-is is the right decision.

If they give a compelling enough set of answers, I'd just skip the rest of the exercise and be done.

After learning how to do anything, the next 20 years is about learning when not doing anything is the right move.

ptsneves
0 replies
10h30m

Looks great and will give it a try in the future. Refactoring is one of the fun things in our job so making it as part of the interview is great.

When I make interviews I also come with the code, normally a few line snippet and have the person tell me what it does or whether there might be a bug and talk about it.

Reviews are also great. They take away the show-cooking aspect where many people feel nervous and makes it more conversational. It is also very easy to evaluate as well because everybody debugs code at some point.

I personally dislike even fizzbuzz because there are always clever ways to go around it that are totally irrelevant.

I was once asked to implement sort a list in python, so I just took the list and passed them to sort. But no the interviewer wanted me to implement a specific type of sort…this was for a distribution maintainer job and I almost failed it because of that. Fortunately the other stages were actually technology related and I aced them.

throwaway346434
1 replies
10h30m

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.

drewcoo
0 replies
10h15m

something horrible based on timezones, or phone number validation

What? Do you have something against zip codes and email addresses?

I like to ask something to do with strings - English sentences. I tell them it's intractable in the time we have and that I really want to see how they whitebox-test the code they write, so take ~10m timebox to write the code, then write some tests - at least one test that finds a bug.

dvt
5 replies
11h13m

I don’t really have a solution to this problem, I just know it’s a problem.

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.

kidintech
2 replies
10h35m

I am genuinely curious:

I am starting a company, and I need smart people; I do not care how good they are at programming language X, or technology T - all the skills my employees will need can be learned on the job.

I want to optimize the time it takes for an arbitrary hire to become independent, to have learned the basics, and to make meaningful contributions. They would write code at most 20% of the time, and the job has many other nuances.

In your opinion, what would a process that you wouldn't refuse look like? Would a learning interview (I present something that you have not seen before, act as an oracle, provide docs, evaluate how quickly you pick up concepts) be so insulting?

dfadsadsf
1 replies
8h16m

all the skills my employees will need can be learned on the job. > optimize the time it takes for an arbitrary hire to become independent

So you are looking for somebody in top 5% cognitive ability and top 5% independence which is what pretty much every other employer wants.

My advice is if you can pay competitive FAANG salaries (or compensate lower salaries by prestige/saving humanity/bringing people to Mars), just do what everyone else is doing - Leetcode, behavior interview and architecture interview. Innovate on something else, standard interview process will give you smart motivated folks.

If you can’t pay those salaries, you need to be creative and decide what compromises you are ready to make and tailor interview process to them. No one size fits all process here. You are essentially looking for people who failed in standard process while still posses qualities you need. Expect to spend more time on hiring and have more bad hires.

kidintech
0 replies
7h48m

realistically we're looking for much higher (sub 1%) cognitive ability. I understand this is highly sought after, so we incentivize by paying a few times what FAANG does locally.

I was genuinely wondering how OP preferred to be approached vis-a-vis this sort of assessment, since they suggested that they would walk out on conventional approaches. I mentioned cognitive ability and ability to learn as I feel those are harder to extrapolate from one's existing publications/contributions/take-home assessments, compared to in-person discussion(s).

dudul
0 replies
11h8m

And next week we'll read on HN an article explaining how take homes are unfair, racist and biased, same for "private projects".

We've been going in circles for 20 years.

SomeoneFromCA
0 replies
8h41m

I have frankly dealt with some people, who wrote books, had lots of titles, yet were incompenent in the very subject their books are about. So yeah, does not mean much to me. I personally love whiteboard tests; shows your ability to code quickly and reliably.

zabzonk
4 replies
10h34m

happened to me in an interview:

them: implement reversing a linked list

me: your company spends a lot of time reversing linked lists?

blitzar
3 replies
10h25m

them: idk I am just the HR person, I dont know what we actually do here or what a linked list is.

zabzonk
2 replies
10h8m

me interviewing at big 6 accountancy firm as a software developer:

hr: you have do the same tests as the accountants

me: ok, hit me

.....scribble scribble

hr: you have simultaneously managed to get the lowest ever score on the arithmetic tests and 100% on the visual/spacial IQ tests, which no-one has ever done.

says something about me i suppose! and they hired me.

blitzar
1 replies
4h25m

I wonder what the accountants get on the leetcode questions

zabzonk
0 replies
4h22m

that was exactly my question at the time!

yreg
4 replies
8h27m

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.

palata
2 replies
7h40m

because they know what exact technologies they are using and they don't need to measure candidate's ability to learn new tech, etc

Well leetcode interviews do not measure the candidate's ability to learn new tech either, do they?

kamaal
1 replies
4h29m

Leetcode is mostly small time snippets, that tests how intelligently you can write nested for loops and if statements. That's mostly it.

If you are looking to hire people to write < 50 line snippets, it works fine. Pretty much useless for everything else.

Aurornis
0 replies
4h19m

LeetCode is a filter mechanism, not an entire interview system.

The big companies that have LeetCode in their process also have system design, behavioral, resume review, and experience review as part of the process.

I’m sure some bad companies are using LeetCode as the entire interview process, but it’s not how it’s normally used.

hobs
0 replies
6h5m

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.

pjmorris
4 replies
6h4m

Jerry Weinberg used to run a discussion forum for experienced software development consultants, aggregating many years of experience at many companies building significant projects.

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.

CoastalCoder
2 replies
5h48m

That's really interesting.

I'm guessing this works better for consultants than for regular employees, due to employment / tax laws.

pjmorris
1 replies
5h43m

I'm guessing this works better for consultants than for regular employees, due to employment / tax laws.

Yes, if you go as far as treating them with the respect of paying them for their time. However, it can still be done in the many interview processes that take half- or a day's time but that don't pay the interviewee for their time.

CoastalCoder
0 replies
5h38m

I've heard of using Amazon gift cards as a form of payment.

I'm guessing that's illegal in the U.S., but maybe it's such small amount of money that companies aren't worried about the legal exposure.

johnnyanmac
0 replies
5h41m

it seems so straightforward. I'm surprised more companies don't try it. paying, say, 5 promising candidates for a short period on some super reduced pay can't be that much more expensive than 2 months of interviewing a few dozen.

gigatexal
4 replies
10h20m

I don’t think anyone is saying in a traditional SWE role data structures and algorithms aren’t useful things to have some me amount of mastery about (higher levels required for higher levels of seniority maybe)… but it’s just hilarious and also sad that we’ve, as an industry, not been able to move away from these logic puzzles disguised as programming tasks that ostensibly should mimic a typical task but serve only to filter out groups of people.

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?

sethammons
2 replies
10h10m

See: work sample test.

My best received interview question was for a bug/firefighting team. Based on a real bug we had, here is a sanitized repo (perl or python, our languages at the time) with some sql and data. We gave them three made up support tickets about some settings values being incorrect causing $issue. Dig into the utility script, find bugs, fix the data.

Even folks who didn't pass complemented the task

gigatexal
1 replies
9h36m

That kind of out of the box thinking is where I think the industry should go. But would it scale to the Google's of the world? Probably not. They'll continue filtering people through the sieve that is the leet-code style interview.

kristopolous
0 replies
8h58m

Sure it would. The problem described above can be manufactured.

Every team of every job you enter does things in their own snowflakey way. If that's new or foreign to you, good luck.

You can permute some base instance in many ways. Filter out the comments in the code or change the variables and function names to be terse and cryptic.

surfingdino
0 replies
9h49m

Our industry doesn't value experience. I have 20+ years of experience but every time I apply for a new role I am being treated like a 19-year old. I was once give a travelling salesman problem by a company that needed a bunch of APIs implemented in Flask. I am a contractor so mostly do 12-month engagements with different clients and I'd say I have more practical experience designing and delivering software, but it doesn't matter to the potential clients, because they cannot judge experience from the past work history. So everyone gets the same treatment and you have software written by recent graduates (or drop-outs) with no industry experience.

mihaitodor
3 replies
5h59m

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.

[1] https://www.linkedin.com/in/mtodor

[2] https://github.com/mihaitodor

CoastalCoder
1 replies
4h16m

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.

mihaitodor
0 replies
3h16m

I can't say this will work for everyone given the scarcity of jobs. I can afford to miss out on certain opportunities and I'm perfectly happy to invest longer stretches of time in networking and doing whatever homeworks if the assignment makes sense and it's something I am interested in. Let me put it this way: I'd very much rather change professions than go through another Leetcode-style interview again. So far it hasn't come to that, thankfully. There are enough opportunities out there once you spend some time building a portfolio and people in the open source space get to know you.

PS: What this approach gives me is piece of mind since I know I won't get a surprise-Leetcode if I go through an interview. It has happened to me in the past, where the recruiter wasn't really aware what the process is and I haven't told them up front what I'm not OK with. Once I'm there in front of people, it's very awkward and frustrating for me to have to get up and walk out and I'd very much rather avoid that situation. Also, it's a waste of my time.

6510
0 replies
1h5m

Seems like seeking devs could collectively hammer out a TOS. HR could then familiarize themselves with it and reconsider their ways.

alexey-salmin
3 replies
11h4m

Hot take: I like leetcode-style interviews and I've spent a lot of time in them on both sides of the fence (tens of hours as a candidate, hundreds as an interviewer).

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.

radicalbyte
1 replies
10h53m

I like giving SWEs small coding problems but it's more of a filter against:

a) The 90% of applicants who literally cannot code. Although I filter out 99.9% of those by screening CVs and a short telephone interview.

b) They can be a point for more discussion.

It's silly to give someone, in an interview setting, an exam question style problem and to make that a key factor in the interview. It's up there with giving someone tasks which could potentially take them an evening just for an interview.

I've tried everything and I've had the best results by talking, digging into the details. Not only do you get a better idea of the person but it's really easy to rat out those who are less capable (especially those who've studied hard for exam questions but fail at everything else).

alexey-salmin
0 replies
10h18m

I've tried everything and I've had the best results by talking, digging into the details.

That's always the second interview I do: "tell me about your favorite project", then asking questions about details, possible alternatives and pros/cons, fundamental limitations, anticipated issues, real production issues, etc etc, going as deep as possible. This works really well and filters out people who do leetcode but don't pay attention to details in their work or have no real experience (if you're looking for one).

However, the couple of times I hired people who nailed this part but failed the coding, they also failed at coding at work. So both interviews are necessary in my opinion.

cherryteastain
0 replies
10h7m

As an interviewer, what you do seems to make sense and I do similar interviews. Removing the pressure of memorizing leetcode question algorithms (yes almost everyone has to memorize for leetcode hard to solve <1hr, most will need to memorize for medium) puts both sides in a better mood.

I also observed starting a process with easier questions still filters out the bad candidates (80%+). Once a candidate 3-4 rounds more open ended questions seem to be much more discriminative anyway.

FL33TW00D
3 replies
11h5m

Another interesting point about Leetcode-style interviews I've not seen raised: it's a form of intellectual hazing.

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
2 replies
10h29m

The problem is that losers cannot pass the test, but winners can.

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.

waciki
0 replies
8h10m

The problem is that losers cannot pass the test, but winners can.

Citation needed

FL33TW00D
0 replies
10h24m

Did I say I don't think leetcode-style interviews have value? I was merely commenting on how this is another useful aspect for companies.

CSMastermind
3 replies
10h58m

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.

kristopolous
0 replies
9h10m

There's a bunch of better ones that are readily accessible.

Ask the candidate to build a known quantity like say, a calculator, calendar, whatever or give them a bunch of code and have them modify it in some way or discover a bug.

Something closer to building software. Leet code is too far away from it and the performance on it too poorly correlated with actual suitability.

drewcoo
0 replies
10h11m

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.

They say As hire Bs and Bs hire Cs . . . and to combat that we've added more leetcode to the interview process.

Tao3300
0 replies
6h17m

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.

It follows that better leetcode scoring is a good indicator of who can be replaced with LLM.

surfingdino
2 replies
10h1m

"they don’t reflect the actual responsibilities of a software engineering of a job."

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?

AnimalMuppet
1 replies
5h50m

This. Why have an interview filter that isn't based on what you actually need to hire? (And then, probably, complain that you can't find enough good candidates...)

surfingdino
0 replies
5h1m

The most frustrating thing once you pass those hoops and get onboarded is the look at the repo, outdated "design" docs in Confluence, and a history of trying things out without any plan. But, yeah... solve me a puzzle.

osy
2 replies
11h11m

It's true that nobody is expected to balance a binary tree as part of the job but the point of these questions is to see how you approach the problem and how you communicate your solution. Given that you can't perfectly predict how someone will do at the job, employers use leetcode problems as a proxy. Even those who memorize leetcode solutions must also memorize how it works and understand the solution. Given that the problem is random and you're likely given multiple interviews, it's unlikely you've memorized the exact problem and solution without cheating. If you've memorized enough solutions that it's likely you've seen the problem before and you can understand the solution enough to present it, then you're in the 0.1% and deserve to pass.

maccard
1 replies
11h7m

the point of these questions is to see how you approach the problem and how you communicate your solution

I disagree. It’s supposed to be that, but the reality of the interview is that there isn’t any time to problem solve so you need to learn the problems and just regurgitate the solution.

That doesn’t put you in the top 0.1%, it ensures you’ve spent dozens of hours practicing questions.

danparsonson
0 replies
10h44m

Right - the number one skill demonstrated by Leetcode-style interviews is the willingness to grind Leetcode.

clarionbell
2 replies
9h42m

Leetcode test would be fine, if they were formalized with automated scoring and nobody giving you hints/silent treatment. Unfortunately, proponents of "normal" interview process will tell you that it's necessary to observe engineer working on a problem to know how good they are.

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.

iLoveOncall
0 replies
9h32m

Leetcode test would be fine, if they were formalized with automated scoring

You understand how this goes completely against the very purpose of the interview which is to evaluate how they think about the problem rather than about the final outcome, right?

I couldn't care less about whether your code compiles or not if you were able to figure out the perfect solution, walk me through it, explain why it is the best, and looked like you had some experience writing code when it came to that part.

TrackerFF
0 replies
5h42m

That sounds like the exact opposite of what one wants, form the interviewer standpoint.

The goal of coding interviews is to probe the candidate, have them explain their thought process, and see how they interact with you. Are they able to formulate the problem? Gather specs? Are they able to consider constraints?

The last thing I want is some automated system where you have no idea how the applicant came to their answer, what their thought process was, etc.

If that was the goal, then just bring back brain teasers, or better yet, just use thinly veiled IQ tests.

upmind
1 replies
8h5m

Leetcode style interviews are not great, but I much prefer them to take homes. However, some FAANG+ companies have a nice system (for internship), where they give a very small codebase (~100ish lines) to work on with some errors / possible improvements and you go through those in the interview.

AnimalMuppet
0 replies
5h41m

Take homes for me are "just no". No, I won't spend six hours working on some throwaway project, in order to have you spend five minutes looking at it and then decide you don't want to hire me.

The problem with this (and with grinding leetcode) is that it's not symmetric. If I'm in an interview, and you're wasting my time, you're also wasting your own. So the employer has some incentive not to waste my time. With a take home, though, they can feel free to waste my time, because it doesn't waste any of theirs. (And leetcode is the same. Yes, asking it in the interview takes their time as well. But all the time I spend grinding in preparation, they do not spend.)

For one special job that I really wanted to get, sure, I'd do a take home. For your average job for average pay? No. Your job isn't worth it. Don't waste my time.

underdeserver
1 replies
10h15m

What exactly about Leetcode interviews can you Google, except the actual solution to the actual question (which you can probably Google for non-leetcode interview questions too)?

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.

swuecho
1 replies
11h6m

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).

johnnyanmac
0 replies
4h45m

I asked them they told me the position is closed

How generous. One job I asked for an update a few days after my assumedly last interview, 1 week afterwards, and then 3 week afterwards (right before the holidays)... even by the last response the recruiter simply said "we are still evaluating the best project to put you on" or something to that effect.

That was 8 months ago now. Going through 5 rounds of interviews into a rejection sucks, but at least be straight with me.

spacecadet
1 replies
7h40m

Well give how well the FAANGS all turned out, evil-money generating society destroying hell holes... I imagine it actually goes like this:

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.

spacecadet
0 replies
7h38m

LC says, "we have no clue what we are building but need people who can build anything, maybe", its a hiring strategy when you have no company strategy.

slavapestov
1 replies
6h9m

Basic coding problems involving data structures and algorithms are table stakes for a programmer. This whole thread is embarrassing.

TrackerFF
0 replies
5h54m

I would not call LeetCode hard questions "basic coding problems".

Furthermore, asking (senior) engineers arbitrary and esoteric CS questions that

A) They may have never seen before

B) They will likely never encounter

Seems like a good way to lose out on competent candidates

If I hire an experienced electrical engineering project manager, I don't ask them to analyze convoluted circuits or random differential equations on the whiteboard.

rckt
1 replies
9h24m

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.

alentred
0 replies
8h50m

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.

perrygeo
1 replies
6h14m

The key point for me is - what does the company value? Don't forget that you are interviewing the company too.

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.

JKCalhoun
0 replies
6h6m

Yep, use leetcode to hire, don't be surprised when you have teams of leetcoders.

palata
1 replies
7h36m

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...

6510
0 replies
45m

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.

mrbombastic
1 replies
5h13m

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.

DEADMINCE
0 replies
4h32m

Most people doing the interviews are not qualified to do interviews. At least most of the time in my experience.

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.

kentrado
1 replies
11h16m

I have a friend who stopped being a dev and went into management because of this practice.

Makes sense, he is older and has two daughters.

I even considered leaving the field myself.

Seattle3503
0 replies
9h35m

I guess that is one way to bake agism in.

kbar13
1 replies
11h15m

it sucks, but honestly having a very clear metric for success is significantly better than the wishy-washy interviews that predated this. i'd much rather grind and be prepared to just regurgitate some algo/code and explain it than deal with the color of the sky being wrong, interviewer woke up on wrong side of bed, i was coerced into doing a "project" that equated to just unpaid work, etc.

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

yieldcrv
0 replies
11h8m

so you’re an apologist for leetcode because of an uninspired false dilemma of another flawed interview style

jakubmazanec
1 replies
6h52m

The solution is simple: since past behavior is the best predictor of future behavior, just let the few top candidates do the (paid) work for a few day/week/months and then keep only the best candidate.

kragen
0 replies
6h44m

adverse selection

jWhick
1 replies
8h30m

I've found most of ukranians as well as russians love this style of interviews. I've also found them to be bad contributors to teams I've worked in.

racional
0 replies
4h13m

If there's an inference to be drawn here -- it's probably that fans of LeetCode-style interviewing tend to be not such great teammates for a variety of reasons; not persons from a certain countries.

guardian5x
1 replies
11h12m

I wonder if its just to see how someone handles stress.

dsotirovski
0 replies
10h27m

likely not as there are other, more efficient ways to roughly gauge that. It does however test one's conformity to arbitrary processes to some extent albeit in not the most efficient manner as well...

graynk
1 replies
11h13m

And I am so sick of „I am so sick of leetcode-style interviews“-style posts. Yet here we are. How much more can this dead horse be beaten? Aren’t you tired of discussing this topic with the same arguments each time?

zem
0 replies
9h22m

it's clearly not a dead horse as long as the leetcode interviews are still ubiquitous in the industry, and as long as people agree it is a problem. the posts are trying to convert a critical mass of people into realising the problem exists, and that they might be able to be part of the solution.

fzeroracer
1 replies
11h14m

Leetcode interviews are in general just incredibly poor signal-to-ratio; especially with the advent of LLMs making it easier than ever to just cheat on the problem. I would just generally assume that any company with that as an initial barrier isn't actually looking to hire anyone at all, but for the sake of 'appearing' to have employee growth.

yieldcrv
0 replies
4h18m

I’ve seen many companies try to do something more relevant in the technical interview, it still suffers from “which data structure manipulation method happens to be available in this framework and have you seen it recently”

Regarding “cheating” with an LLM, there is not unanimous consensus on that either. I’ve been in technical interviews where the collaborative coding tool had an LLM built right in, and I was encouraged to use it. If thats what I’m going to do at the company then demonstrating problem solving that way is useful.

ThinkBeat
1 replies
5h45m

I have so far not done a full Leetcode myself and I dont consider it an especially good approach.

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.

Aurornis
0 replies
5h30m

then studying it, while time consuming is not that hard.

I’m in a mentoring group that includes a lot of people looking for jobs and studying LeetCode. Two themes that come up over and over again:

1. People overestimate the difficulty of practicing LeetCode. Reddit and other sites make it sound like you need to take 3 months off to grind LeetCode full time, but most people can do 1-2 problems per day in their spare time, lunch break, or other small window of time. You don’t need to do rote memorization of every problem on some list found on the internet.

2. Actual LeetCode interviews are rarely as hard as people expect. People think they’re going to get LeetCode Hard problems that require obscure tricks, but the vast majority are Easy and Medium.

SSchick
1 replies
11h18m

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.

stavros
0 replies
10h57m

The entire point of memoizing is to only ever do the interview once.

CSDude
1 replies
11h4m

I agree it's not a great way but a good compromise. When you think of Leetcode you can be thinking of hard questions. But this is not the case for many of us.

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.

KeplerBoy
0 replies
10h54m

There's a spectrum to this. Testing easy questions seems fair and appropriate.

AYBABTME
1 replies
6h17m

It's weird to me because I haven't had a single person ask me Leetcode questions, and I never opened Leetcode once in my life. And yet I interviewed plenty and got job offers aplenty. Who asks these questions? I'm I somehow simply self-selecting out of these types of companies via some proxy feature I'm unaware of? Or maybe they stop asking these questions when you're more senior and not fresh out of school anymore?

beezlebroxxxxxx
0 replies
5h50m

simply self-selecting out of these types of companies via some proxy feature I'm unaware of?

Probably. Most LC interviews are in the early to early-mid career stages and are often at large headcount shops where problems are often solved by throwing man-numbers at a problem. As a result, the shops think: "Why don't we hire more really intelligent people to throw at these problems?" They have lots of postings and then get a lot of applicants. LC then serves them 2 main purposes; 1) a proxy for "intelligent people" that can solve these kind of extremely generalist problems, and 2) a way to cull the herd.

Once you actually need specificity in your hiring, then LC style questions are effectively useless outside of some very unique contexts. That they are so endemic is reflective of how bad almost all companies are at hiring.

451mov
1 replies
11h22m

here here

moffkalast
0 replies
11h15m

the eyes have it

414owen
1 replies
11h17m

Word.

ge96
0 replies
11h14m

Libre Office

zhvihti
0 replies
10h52m

LC questions are a shitty way to qualify 3 traits that employers very much look for (and have proven to be correlated):

* 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.

weatherlite
0 replies
10h22m

What you're tired of solving algorithmic riddles that have very little to do with what you've been doing the last decade, all this under pressure with a shared screen in front of two bored interviewers? I don't understand how you can get tired of it its so much fun!

wantedtoask
0 replies
8h53m

Small feature request based interview?

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'.

treprinum
0 replies
10h42m

That would be OK for top-end jobs where one makes $1M but nowadays everybody is subjecting devs to this torture even if they offer $40k just because the big boys are doing it.

the_black_hand
0 replies
9h47m

Don't hate the player, hate the game.

the_black_hand
0 replies
9h47m

Don't hate the payer, hate the game

surgical_fire
0 replies
7h22m

I am oddly fine with leetcode interviews. Mostly because they are predictable, and you can study them over time.

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.

sensanaty
0 replies
7h21m

The best interview I ever had was with GitLab, where they make a realistic PR/MR (but one that is obviously not actual code they'd use for anything, for the ones worried about doing free work for them) and you have to review it. It's exactly what I do at the actual job at least 50% of the time, and I'm sure from their side it gives them a lot of room to look into how the candidate works/communicates.

They then ruined it by still having a leetcode style interview afterwards which I found monumentally stupid, but oh well.

rascul
0 replies
5h13m

I've only heard of this crazy stuff with weeks of unpaid interviews and tests for programming jobs. Is this common in any other fields?

radres
0 replies
11h21m

If I am interviewing someone and if they ask me if they can google X, if it is easily googlable, I would just tell them what it is. Or let them google it. But I do not expect them to spend minutes googling it.

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.

racketprogram
0 replies
11h11m

I am still not sick for this. (╥‸╥)

praptak
0 replies
10h44m

Joel Spolsky, whose influential articles started the Leetcode-style interviewing, agrees we need something better:

"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

poisonborz
0 replies
10h50m

I think the "algo genius" type of developer is a harmful myth of the industry. In most of the SE jobs you simply need dedicated, motivated persons who love the product and are able to organically grow to what the team needs. Places idolizing leetcode are in the stressed underorganised "scale to the moon" phase, where there is a need for individuals(!) to solve whatever is thrown at them at speed.

physicsguy
0 replies
10h13m

My biggest concern about Leetcode is that it’s not actually that relevent to the day to day job of being a software engineer and has more to do with being a computer scientist which is an adjacent but different set of skills.

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.

peter_l_downs
0 replies
5h38m

I agree. Thankfully, you don’t have to take them and you don’t have to give them!

paulus_magnus2
0 replies
9h7m

How does this look outside coding? Do we know of any other professions where there are whiteboard / leetcode style interviews?

nikolayasdf123
0 replies
10h30m

there are plenty of people who would nail leetcode. but they are not even allowed for interview due to visa/immigration restrictions.

nikolayasdf123
0 replies
10h31m

leetcode is ok. I am so sick of visa/immigration restrictions

nh23423fefe
0 replies
1h12m

This person doesn't even spell check their writing. Imagine the code reviews six months out.

Kuberentes
mxsjoberg
0 replies
10h34m

the solution is to start your own company and not do them

be the change and so on

moomin
0 replies
10h19m

I am good at leetcode interviews. So are a lot of people reading this. For the most part, this is for the same reason: at some point we sat down and practiced until we were good at them. It’s a useful skill to have and I recommend to people on job searches that they learn it.

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.

mbravorus
0 replies
2h9m

My frustration at this type of interviews is more philosophical. In broad strokes, for some reason the employers desire and require a significant amount of effort and training from potential employees so that those could (in theory) then solve complex problems for the company; but at the same time, employer's management _usually_ absolutely refuses to invest any noticeable resource in researching, designing and maintaining the processes they should be accountable for, including the recruitment.

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".

makerofthings
0 replies
6h43m

I quite like them. You know what sort of question you’re getting and they’re really not that hard. Practice. Get good at walking trees. Answer too slow? Sort the list first, use two pointers, use a hashmap, max heap…

m0llusk
0 replies
8h10m

Managed to solve this problem by going into business for myself. Have applied to some potentially interesting positions, but got batted away as not good enough at coding quiz questions. If I ever feel the need to be treated disrespectfully by people with two or three decades less experience then maybe I'll put my resume out there again. Probably not, though. Kind of interesting that I know many like me who have decades of proven experience but little interest in modern interview games and end up going different ways. Lots of value being left on the table, but there it is.

lordnacho
0 replies
5h7m

He's right to be sick of it. There's no sense in them.

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.

kiney
0 replies
4h57m

When I read posts like this I'm always surprised and confused. I've had quite a few interviews for software jobs in my life but not a single one was leetcode style or with a whiteboard... Is this just a cultural difference between countries? (I live in germany) or was I just lucky?

jsnk
0 replies
11h12m

"Leetcode questions are the worst form of interview questions, except for all the others" - Churchill

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.

js8
0 replies
7h3m

I think the fundamental problem is that in SW engineering discipline, we judge skill according to knowledge of tools (like programming languages) instead of knowledge of the application domain. There are interesting historical reasons for this, and it is a double-edged sword. But I think it would be healthier for the profession to acknowledge that application domain knowledge can be at least as useful as tools knowledge.

isoprophlex
0 replies
11h19m

The only winning move is not to play.

innocentoldguy
0 replies
11h5m

I hear you!

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.

iLoveOncall
0 replies
10h34m

I see LeetCode as a pure numbers game. Keep applying until you get easy questions and don't get hung up on your failures.

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.

hcrean
0 replies
6h57m

Leetcode is about proving you can give up huge chunks of your time to learn about the current industry fads, useless to life though they may be: This is unfortunately a vital work skill in the software development industry...

gamebak
0 replies
10h41m

I share the exact feeling as you do, it's a lot of bs that has almost no value. None of those problems reflect what business needs to solve; everything today can be Googled and fixed with straightforward code.

Usually, the computing part isn't the part that prevents a business from scaling more (servers are cheap).

forrestthewoods
0 replies
10h38m

Especially since I know for a fact they don’t reflect the actual responsibilities of a software engineering of a job.

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!

fHr
0 replies
9h47m

yeah classic FAANG bs from consultancy leaders who can not solve 1 leetcode problem and don't @ me with they don't need to because they can't make business decisions either even with fancy economy degrees and then layoff half the staff. If your CEO was not a techie the company is doomed anyway. So FAANG pushes leetcoding and everyone does it now, I just learned the 100 most common for interviews by heart and dabbled into 1000 leetcode problem. Absolutely only need to put in work and has 0 skill tbh it reminds me when I had vocabulary tests in school for other languages, just learn it by heart and score high mark. No skill of the daily business life involved at all. Landed a job that way. Improvise, adapt, overcome.

eunos
0 replies
8h35m

I still believe that the Leetcode style interviews are the great equalizer that provides opportunities for folks coming from non-elite Universities to try their luck with FAANG.

eschneider
0 replies
8h46m

Nobody dislikes these sorts of interviews more than me. I'm not sure they're particularly useful for anyone and I _know_ they don't show off what I do well for employers particularly well. That said, prepping for interviews is just one of those things I'm willing to do for money. Is it worth $25K a year to me to spend an hour a day for three months working leetcode problems prior to interviewing? Probably.

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.

ergonaught
0 replies
5h31m

Over the past 25 years, the only thing that has ever reliably identified successful candidates for my hiring was having 2-3 people (at least one "cross-departmental") rate how much they wanted to work with the candidate, leaving it entirely up to them to determine how they arrived at that rating, and only hiring the highest rated people. I still performed superficial screening/filtering of resume/cv but there are very few roles in very few businesses where the "leetcode-style" of interviewing tells you anything relevant whatsoever.

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.

emodendroket
0 replies
11h14m

I'm almost as sick of reading about them.

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.

drones
0 replies
10h18m

Could anyone provide an example of what Leetcode problems are too hard or unrealistic for hiring/interviewing purposes?

dkdbejwi383
0 replies
6h45m

My biggest beef with this style of interview is that someone with commitments (family, sports, hobbies) outside of work, I have no time to study the format, spend months practicing questions, practicing the art of speaking my thoughts in a clear way while actually having time to myself to think and process, understanding the gotchas etc.

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.

dispirited
0 replies
9h40m

I'm maybe more cynical, I believe that these types of interviews don't filter out less smart people, but filter out people who don't object to the processes of Big Tech. I think they mainly serve to pass through people who aren't going to question the system, and won't speak up when during their day to day trenches they're implementing ethically bankrupt software. Intelligence has nothing to do with it, it's about ensuring the capitalism machine keeps going without any revolt.

dicroce
0 replies
6h44m

It seems to me that while passing a leetcode question shows that you might know a thing or two, not passing one doesn't really show the opposite. You could be the smartest / greatest coder ever and you just got a really unlucky question... Or it could be that you're not great when you are nervous, etc...

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.

delegate
0 replies
9h48m

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.

damontal
0 replies
6h17m

Imagine what Franz Kafka could do with the Software Engineer interview process. It practically writes itself.

concordDance
0 replies
10h12m

Interviews are incredibly noisy signals. It is far easier for someone to blag about their AWS experience than for someone to bluster through an unseen leetcode problem.

chmod775
0 replies
7h21m

They're fine to filter fresh university graduates.

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.

caff31ne
0 replies
5h23m

Let me put this straight. You are just lazy and those interviews are intended to filter out lazy engineers. Training for coding interviews is not a problem. You just need to spend 1-2hr daily and solve couple of hundred leetcode tasks total for less than a year. After this you'll not have any problem with this type of interviews at all. Additionally they boost up your coding skills and problems solving skills. You do not realize it yet because you did not train.

bradleyjg
0 replies
7h31m

I don’t really have a solution to this problem, I just know it’s a problem.

Neither does anyone else. Everything else we’ve come up with either has worse issues or is extremely expensive to operate.

bluGill
0 replies
4h55m

There is a lot of academic research on interviews. I'd like to see one of these blogs actually find and reference it sometime. Instead we get a lot of why someone "feels" something works/doesn't work, but no reason to believe they are correct.

bilsbie
0 replies
7h9m

I’d like to know how other professions are hired. Do CPAs get challenged with hard tax problems and no access to reference material? Do plumbers replace a toilet in an interview?

beej71
0 replies
4h43m

This is a place small companies can get an edge, I feel. They don't have a zillion applicants, so they can be more hands-on in the interview process, and the interview process itself isn't clogged with years of cruft. They don't have to rely on "good enough" weedouts like Leetcode.

badgersnake
0 replies
9h51m

They are just bad and it’s an indication of laziness in the team, or that the organisation is hiring centrally and you could end up doing anything. Both of these are negatives imho. Developing a relevant technical interview aligned with what the team does is a project in itself and takes significant time to do and keep up to date. People don’t want to invest the time, but from experience it’s definitely worth it.

andrewstuart
0 replies
10h1m

There is an absolutely vast array of stuff you need to know to write software including networking, hardware, software, database, operating system, multiple languages, mutiple tools, standards, testing, processes, and on and on and on and on. It goes on forever.

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.

alkenes
0 replies
6h40m

All the worst kinds of engineers, the kinds of people that talk big and deliver small and slow, the people I know I’ll need to go and fix code for, they are always the ones that work on leetcode the most. These are the false positives that people pretend don’t get through with leet code interviews, the kind of people that don’t understand how node async actually works but can reverse a tree optimally off the top of their head.

TrackerFF
0 replies
6h9m

My problem with LC-style questions is that it becomes a race to the bottom.

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.

SomeoneFromCA
0 replies
8h38m

Sour grapes;I've never ever had problems with LC style interviews, and much prefer them over behavioral BS PM-style ones,

Pelayu
0 replies
9h33m

Honestly after interviewing lately, I prefer Leetcode-style interviews to doing some takehome project. I’ve failed two assessments now where my project fulfilled the functional requirements set out, but I was rejected because I didn’t use their conventions (which were not specified) or they didn’t like the structure of the code. Not only that, after investing a few hours of my free time to complete said project. I just get vague, hand-wavy reasons as to why I’ve been rejected.

Leetcode-style any day, over that.

NiagaraThistle
0 replies
7h23m

God I hate these interviews.

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.

NalNezumi
0 replies
11h1m

I used to (still kind of) hate Leetcode-style interviews. But now I see it as a lesser evil, like Churchill's description of democracy.

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)

LASR
0 replies
11h14m

I lead tech interviews for E5/6 level engs where I work.

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.

KoftaBob
0 replies
6h31m

In my experience, the best kind of assessment for Software jobs is a reasonable take-home project that involves a private repo that you fork, work on adding a feature or fixing a bug, and then send a PR.

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.

https://www.woventeams.com/

JohnKemeny
0 replies
11h1m

In my experience, there is a strong correlation between good programmers and the people who can solve these types of problems.

It's a kind of audition.

IshKebab
0 replies
5h32m

Especially since I know for a fact they don’t reflect the actual responsibilities of a software engineering of a job.

I had one job working on a compiler that fairly regularly had leetcode-style algorithms problems, even novel ones.

But yeah, most don't.

Crier1002
0 replies
9h56m

I am leaning towards LC style interviews over a take home assignment that is meant to take “no longer than 2 hours” to complete