Ask them general stuff I'm genuinely interested for their opinion but that would very quickly display the proficiency of the person without ever coding any line.

Question such as, for a web development job:

1) favorite way to manage git history

2) what do they like/dislike about different CSS authoring solutions

3) how did he manage localization on his previous projects

4) candidate's opinions on different frameworks/libraries

5) candidate's debugging approaches

6) opinions on latest updates to the ecmascript

And I can go on and on. As you simply chat and exchange ideas it is so blatantly obvious who's able and who's not. There are no right/wrong answers and it's totally fine to not have experience or knowledge about this or that but in one hour you can touch so many topics about your current projects and candidate's past that you can indirectly understand the level of seniority and proficiency of the candidate.

And anyway, all of this is useless. Because the most brilliant and knowledgeable candidate could spend all his day playing videogames and pretending to work anyway, so why would I put so much emphasis on those skills/knowledge rather than the individual/professional I have on the other side of the screen which is way more relevant?

I need people I can *trust* as coworkers. People I can assign tasks and know they will be done or that the candidate will communicate.

I don't need puzzle solvers. I really don't. I couldn't care less.

At the end of the day you need to optimize the interview for what you need from your colleagues. I need trust, reliability, communication, professionalism, effort.

I can sense those from chatting and I can have a good idea. But by having you implement Levehnstein's distance I just have no intel.

Oh wait, welders have to prove they can weld before they get hired? [1]

---

The general issue with coding interviews is most companies don't validate that the interview is actually correlated with job performance. Of course a process where the blind leads the blind is going to have issues.

[1]: https://www.reddit.com/r/Welding/comments/26ppfb/what_to_exp...

At a prior job I was the person who asked candidates to write fizzbuzz, and it was much more of a filter than I ever would have suspected. One senior engineer, from a company you know, with a master’s in compsci, couldn’t write a for-loop for the life of ‘em. Another QA engineer wanted to write tests for their implementation by capturing stdout and comparing it to a hardcoded string.

Me: What if you want to test the output of 1,000,000,005?

Them: We could store the test output as a file on disk instead of a string!

Me: Well, ok, suppose you only want to test that one specific value and not all the others?

Them: Ah, got it! We could discard all but the last line of stdout and just look at that.

Me: Can you think of a way to structure your code so that we could just calculate the output of one single number without all the numbers before it?

Them: Uhhh...

Those are 2 examples out of many. I honest to god don’t know how some people managed to build their resumes while not knowing how to do the simplest thing in their field imaginable. Imagine you were interviewing cardiologists and a solid 1/3 of them had never heard of blood. What? How? How did you get to this point?

And that’s why I’d never hire someone until I’ve collected evidence that they personally can turn ideas into code. If you can’t wrap your brain around fizzbuzz, you’re gonna have a hell of a time when a customer gives you a change request.

It's not a perfect system, but it works better than the alternatives.

Can we stop calling it "failing" when a company decides you're not a good fit? If you go on a date and don't get asked for a 2nd, did you fail the date? You're not just what they're looking for right now; not everything has to be a failure.

> for every 1-hour interview where I evaluated if someone knew their data structures, I could have just taught them

I'm sorry, what? He thinks it takes one hour to teach someone data structures? We sure are wasting our time with those multiple college courses and hundreds of textbooks on the subject then. We should just get this guy to spend one hour imparting all necessary knowledge into everyone.

> it’s often said that what’s more important is how you solve the problem, not that you solve the problem, but in practice human biases will work against you if you don’t get close to it working.

Human biases are much more likely to work against you if the interviewers have not spent time trying to come up with a consistent test that they give everyone. Does the author think human bias is absent from non-technical interviews? The less standard your hiring methods are, the more bias you'll have.

> I’ll just keep practicing for interviews until I successfully trick someone into thinking that I know how to code and then secretely become one of the best employees they have ever had.

I don't know who Darren Kopp is, so maybe I'm about to get an army of replies saying he's their coding role model, but this is an article about whether code interviews work or not, and he's basically saying "if they don't hire me, who will definitely become one of the best employees they've ever had, then their coding interview process must suck". The other possibility is that Darren Kopp just isn't actually tremendously more stellar than everyone else and coding interviews are actually kinda working. For his argument to work, he has to be one of the best possible candidates for every job he's applying for. I just kinda doubt that.

My takeaway is that if the goal of the coding interview is to “identify people who can code”, then this approach has high precision and poor recall.

In other words, most of the people who pass the interview actually can code (at a basic level—I’m not talking about high-level system design skills here). Very few people slip through this interview who cannot code. However, because of the poor recall, there are many people who actually code very well that the interview misses (a fact widely derided on here).

From the perspective of a big tech company, this situation is perfectly fine. There are so many candidates interviewing for any given role that accidentally rejecting a few exceptional candidates is quite an acceptable trade-off in order to prevent a bad hire. Most of the people who cannot code and are aware of their inability to code, yet still knowingly apply for a position that requires the ability to code tend to be BSer types that attempt to make their way into management positions as quickly as possible (and there are many of these people targeting big tech companies). It’s not that their inability to code hurts the company—it’s that they would prefer not to code at all and go straight to the politicking. The coding interview is simply a nuisance obstacle in the way of this objective. These types will often state that they refuse to interview at any company that requires a coding interview, though I admit there are still many BSers who are skilled enough to pick up some coding ability for just long enough to pass the interview.

At a small tech company or at a company that’s not a “brand name”, this approach obviously doesn’t work as well, because these companies don’t have nearly the onslaught of BSers applying to their open SWE positions. In this case, it might make sense to forgo the coding interview in favor of other approaches.

I like the coding interview because despite its flaws, it actually assesses some technical ability, even if it does so with low recall. This is very much unlike the behavioral interviews, which I think are mostly nonsense and are prime opportunities for BSers or mercenaries to slip into a company. In my experience, the behavioral interviews tend to disproportionally filter out people from unusual or underrepresented backgrounds that aren’t the right “cultural fit”. The language and terminology used in the interview, the conversational style and mannerisms, and the topics discussed all typically provide much more signal into the candidate’s position in the class hierarchy than how that person would do at the job. People like to think they can assess someone well by having a brief 1 hour conversation with them, but I just haven’t found that to be the case, because there are too many perverse incentives and biases involved.

other than that, I agree it's dumb, really dumb.

Look, I know a lot of the job application process is bullshit. But much of the job is bullshit too. You still have to do one kind of BS in order to land the job and the other kind in order to function as part of a team in an organization. There's really no way around that.

Use coding interviews to tell corporations that the Queer Autonomous Qommunist Revolution (QAQR) is coming for them.

The mascot of QAQR is a rubber ducky that we use to question the need for employment and bosses. It seizes all corporate source codes, and turns them into Open Source. It strikes fear and rebellion.

Use coding interviews to spread QAQR propaganda and memes! This is very human!

Haha I'm sure you'd love to believe it - let me ask you this: Why does AI easily solve all the Leetcode problems but still can't design a decent web page? API? Auth system?

Leetcode doesn't cover 99% of what a developer does - it's like taking fencing courses and claiming to be a military expert. Leetcode skips SQL, REST/HTTP, OOP and framework patterns, frameworks themselves (React etc.), serving a page, tests, working with files, doesn't even cover basic async functionality (core to writing high quality code), git, ORMs and NoSQL, doesn't even touch devops or UI. It's "add the numbers in this array" type problems - memorization techniques like math problems and other abstract academia.

I prefer people who build products you can see and use, and have other evidence of their work online like libraries they author or contribute to.

Btw, Leetcode is pretty out of fashion at this point for interviews.

- filter out low-IQs

- filter out people difficult to work with that refuses to take them

- filter out people that have no interest whatsoever in computer science

"Have you heard of X? How would you deal with Y in situation Z? Your CV says you worked on A, have you also looked into B? Any guess why we went with B instead of A for C?"

They didn't need to give the exact answer we wanted, the questions they asked in response often told us more than the straight answers.

Everyone I hired is still at the company and one of them sped up our tool by an order of magnitude. No coding challenges needed.

I’m not a competitive programmer. I’m an engineer. If you want a competitive programmer go find a new grad who was in the competitive programming club in school. Assessing engineering skills with leetcode is like assessing bicyclists on their ability to swim.

Usually I do something like this: candidate picks a language (let's say Python) and I will put up a function prototype that is maybe almost Pythonic, and has a SphinxDoc docstring that is subtly not-quite-complete, and say the rest of the function is a block box that you need to test.

First off, do you have any questions about the definition? Or let's say you saw this prototype for a yet-to-be-implemented function in a design review, would you have any input or want clarifications?

Then, I would ask the candidate to present some test stimulus and expected results. Not code, just make a table with inputs and expected output in columns.

I find out very quickly if they can think about corner cases, think about possible exceptions, know which exception is appropriate under various circumstances, and occasionally (too rarely...) I will get some opinions about various test frameworks that they like or don't.

This technique will not sort people by how fast they can code up a tree balancer. But.... if after hiring them if I were to ask them to implement a tree balancer, I can be pretty confident that it will work.

I've focused on removing that part of the process for the engineers I work with and help people make it to an actual interview. If you have the skills you should have a fair shot and not get drowned out by the hundreds of other applicants.

If anyone is looking for a startup opportunity, I have a platform that removes that whole problem and gets you to an interview directly.

Here is our server. https://discord.gg/WKj3uz6sZZ

Everyone was asleep at the wheel anyways

https://news.ycombinator.com/item?id=40292924

We sit the candidate down, and present them with a task. Then we all sit down as a team and work the problem. The most recent one was building a game of marbles. None of us knew the rules of marbles, but the candidate knew how to take a vague task and work with the team to produce something functional.

Which is what the job is. We ask the candidate to show us that they can do the job and then hire whoever 1) did the best work and 2) vibed with the team.

Anyone who places real value on leetcode is not someone who should be managing programmers because that's not the job. In precisely zero real-world situations does any programmer need to be able to write a red/black tree blindfolded on a whiteboard standing on one leg and signing the national anthem. In the real world you just grab the algorithm out of a book or stack overflow.

It usually goes like this:

Candidates are roughly screened by their CV. A handful (in my experience roughly 6) are invited to hang out at the lab for most of the day.

They usually give a presentation on previous projects, and then chat with each member of the lab in turn, hearing about their work and asking questions etc.

Then you all go and have lunch together (usually without the boss). Later the candidate has a more formal panel interview with the group leader and some other faculty.

A few days later, they are told the outcome of the interview.

It may seem like a long process, but it all happens in one hit. The advantage is you get a much better feel of the candidate over this continuous process, than you would with shorter interview tasks.

It’s a strange world.

I'm a self-taught coder without a degree. I guess it may be extra frustrating for graduated candidates where your hard-earned degree buys you no credibility for skill.

Kinda similar, after ten years of lead development coding every day in the enterprise on huge projects I still don't get a pass on the code interviews.

I will say, if you're trying to career pivot and apply for a management or product or sales engineering role etc., lots of technical experience does carry weight in interviews.

I know I can write code. I know I can work with the cloud. I know I can talk to stakeholders and gather requirements. But yet I am treated like a new grad in the interview process.

You do, however, need something practical to test that the candidate can think logically and actually program.

I'm mostly looking to filter out the candidates that flat out can't code or describe their thought process while coding. You'd be surprised how many candidates I've interviewed pass the resume check, get to the interview and can't reason out a problem that could be solved with two for loops and an if statement.

Interviewing should be more about avoiding bad candidates than finding the best candidate.

This guy fails coding interviews. Then he gives coding interviews, but the people he selects based on these interviews are a mixed bag. Because he's failing the interview from both directions.

I've given coding interviews, all the questions I've given have been "leetcode easy" level at worst. In person, I usually try to get the person to write up an implementation of Towers of Hanoi. One of the example recursion problems. The interview is not an adversarial process, it's a cooperative one.

I want to see them think and I want to see them come up with code on the fly. Because while we can look up things on the job, at some point, it also requires original thought.

Unfortunately, it is very hard to judge somebody's coding ability in discussion alone. You can sort of get the idea whether they have or don't have experience and whether they have luck being asked about topics they know (although you can help your luck just knowing a lot of stuff).

I have seen a lot of candidates who were quite smooth talkers but could not code their way out of a paper bag. Mind I do not mean remembering some complex algorithm. The task is usually some relatively simple data manipulation so that I can see the person approaching the problem, asking questions, getting involved in some discussion, etc.

The task is usually ambiguous a bit and this is explicitly stated so that the candidate is actually expected to get stuck, don't know things and have to talk to me to get the problem solved. You would be surprised how many candidates do not listen or can't follow simple advice even when I am almost giving them the solution on a platter.

The trouble is there is a lot of interviewers and many interviewers do not have a basic plan of what they want to achieve with the coding interview. What they want to learn about the candidates. Those interviews tend to suck.

What also sucks is candidates who come to the interview completely unprepared, unable to answer most of the questions or get any progress on the programming tasks and then spew misinformation on the Internet about how supposedly all coding interviews are stupid.

I guess if you can code you may have some misses, usually along with some hits. Sometimes you are out of luck. The point is not that you need to get every job that you apply to, it is enough to get one of them.

But if you can't code at all or you apply to positions that are clearly out of your league, you get rejected on all these interviews. And then what you do? Some people go to write on the Internet how all interviews are stupid without ever considering how they contributed to all those failed interviews, how real life works (ie. 90% of everything is crap including 90% of interviews) and how the situation might look from the other side.

Seriously, what are the alternatives?

On one hand anyone can learn anything with enough effort; and on the other any smart person can learn anything without trying much at all.

And yes the interviewer has to review that stuff and ask good questions but nobody said this was easy. But for me it showed better outcomes than the usual live leet code interviews.. (I did them too).

You know what I meant. You have merely created a series of strawmen. They don't need to perform a trial surgery every time they interview for a new job. The same goes for all my examples so nice try.

I'd like to hear more.

When I'm tasked with interviewing candidates and evaluating these basic algorithmic and coding skills, I have a 5-part problem (each building on the next, and only revealed when the previous one is complete) that is basically impossible to finish in the time allotted. I tell the candidate ahead of time that it's an ongoing problem that's designed to not be completable in the time: we're going to work through this problem and see how far we get. I've passed candidates who "failed" the actual problem, when the conversation and coding that were shown still gave me a good understanding of their capabilities.

What is the most impressive thing you've ever done?

Just watch how they struggle with this one. I've never met anyone slinging code tests who is so curious in "how we think" that has ever made anything interesting whether it's code, design, music, a company, anything. It's just a pretentious statement made by gatekeeping noobs who love to interview, nothing more.

I tried to save your comment lol

When you feed people confabulated information, it acts as an encompassing medium, a reality buffer, effectively making them more inert, less engaged, in actual reality. Brined.

Just kidding, but you should value your applicants time. You could just as well show them bad code that is a problem and ask them what they notice when they look at that code. If they are good they point put the problem(s) if they are bad you will probably be able to figure it out based on asking them alone.

Because it's all managers and no talent now, there's like an Interview Industrial Complex that emerged, where most teams spend the majority of time and energy just interviewing thousands of people and hiring/firing (via manufactured drama) while they never really build anything - it's all these managers know how to do because there are so few real developers left.

Some of the best developers I know of (of libs I use, etc.) outright refuse to work in the infantile conditions of the modern corporate setting anyway. The lucky ones have found other revenue streams and spend their coding energy on open source or personal ventures.

I talked to a young founder the other day - maybe 10 years younger than me, in his 20s - who said multiple times he was "retired", he kept waiting for some kind of validation on my face I guess but I just don't find it impressive. I lost respect actually, having heard that. In his mind he thinks he's a baller, in my mind he's a lazy egomaniac who knows 4 total things - I wouldn't even let this kid mow my lawn.

Smart, talented people just aren't valued anymore - it's more about prestige and authority now. But maybe not forever, they're certainly leaving themselves wide open at the advent of this LLM thing. Would love nothing more than the big tech ship to sink and get displaced by smaller, smarter companies.

And that's all I ever ask in an interview. Ask questions and talk about what you're doing. The worst hires I've ever seen were all the ones who never asked questions and never talked about what they were working on. Half sentences are fine; moving away from the keyboard while we talk is fine; being unable to talk and think at the same time probably is not.

If the input is infinite and unordered and the task is to produce output in order, how do you know when it’s OK to start writing output?

“Hey, can I stop you there for a minute? This interview style isn’t really working for me to the point that I’m considering cutting the interview short and heading out. Here’s why …” - and then have that conversation. Some people will take that badly - and that’s fine. But I have no idea what will happen next after saying something like that. And that makes it an interesting direction to take it.

It's worth taking the time to ensure your formatting is consistent, with no/few spelling and grammatical issues.

It will also vary by market/location. If you're looking at jobs local to you, it could be very different, especially for those jobs wanting domain experience. Different business sectors also congregate around adjacent businesses... so the choices and technology in one City will vary greatly to other Cities. As will the development process itself.

You may be underestimating people's ability to bullshit their way through this sort of discussion.

It's harder to bullshit your way past a blank file in a code editor.

I'd wager that something like FizzBuzz will eliminate 90% of the chaff. Yes, it's laughably simple. No, it's not so simple that it won't stump a significant number of folks who've coasted for years.

Where does it say that?

My rate is around 50% good, 50% I wish I hadn't hired.

Anyone else want to fess up?

I agree with this, but with the caveat that it's extremely rare to come up with a truly novel algorithm in a production environment. Those almost always come out of academia or R&D departments.

So is it important that people remember how to implement algorithms from scratch? Or is it important that they know when to identify when an existing algorithm would be useful?

For instance, if I see that something is suspiciously like a Stable Marriage Problem, do I need to remember how to implement the Gale–Shapley algorithm? Or is just the ability to recognize the problem as something that has a particular solution 90% of the way there? I would argue yes.

That said, I'm not sure how to test this is an interview setting.

I'm not a huge fan of coding tests, and I have a lot of sympathy for those who refuse to do them, but it's a case of "It's not you, it's everyone else"

You're making the opposite point you think you are. How do you know that you observed an inability to code as opposed to interview performance anxiety?

I've been coding for 25 years, but have bombed my share of very simple white-boarding exercises because I panic and my brain absolutely stops working. If it's experience-based or even take home, I generally knock it out of the park.

White-board coding works for FAANG because they have 100,000 applicants at any given time and it doesn't matter if it has an exceptionally high false negative rate. It does not work so well for shops that are struggling to find candidates.

My concern would be skill atrophy between relicensing and then you'd still want to do the same sorts of interviews.

If someone is in a position where they have to read through 100 resumes, there is a limit to how often they can look at a paragraph-formatted WYSIWYG text edited black and white document that says "I did well at school, I worked some jobs afterwards, now I want to work here". They blend together something shocking.

It is worth having a tasteful dash of colour or maybe a formatted header/footer where possible. Low bar, but there is a big pool of serially unable-to-get-past-screening candidates who can't clear it and you want to stand out from them if at all possible.

I just mean that if you put 2 experienced people talking about a topic they both know, it should be pretty easy for both (or at least the interviewer) to get a rough understanding of the level of the interviewee.

Are you hiring people to create new JS frameworks, or to use an existing one?

No, I think that they are all garbage.

The only way to really hire is by having a vibe check to see if they are someone the team wants to work with, making sure that the person seems competent and has a reasonable chance of being very productive, and then hiring them quick. Give them a month and if they don't seem like a good fit, then fire them, with 2 months severance.

This is the only way I've seen that will produce a great team quickly, by hiring quickly and firing quickly. This is similar to what Netflix does but they also pay top of market which not too many companies can afford, but it produces the best results.

> which is to make sure the candidate can actually write code, like at all

It's also still a terrible approach and only gets leet code crammers.

So, yeah, go figure.

Software is a craft discipline... it would be better organized as a guild with reputation at stake in concert with endorsements. But then you risk what is effectively nepotism and politics.

Of course there's always Google search too if you are just looking for an algorithm, but LLMs help in the discovery process since you can describe what you need without knowing the name of it.

There's not a more pragmatic measure of whether somebody can code than a track record of a successful code project used by other coders.

“ Also a 'white' older male is the least preferred even if he is smarter compared to all females and the minorities that are being interviewed as long as they are not terrible. Biases galore.”

I will agree that ageism is a thing, but 90% of all of my coworkers (who were software engineers) have been white males, so I cannot at all agree with this take otherwise.

Obviously taken into account - I still have no problem whatsoever identifying great developers on GitHub and I'm sure many other developers who actually code often could too. You have bigger problems if you can't tell if someone is lying or not about their abilities when all their work is visible to you. You should be able to easily tell what is theirs vs not.

> Lol, great method!

Yes people inflate their own egos and abilities - especially those who spend all their time interviewing others instead of building.

I prefer demonstrable experience for an engineer over standardized tests which tell you nothing about any real world experience: App architecture, async programming, APIs, UI, DOM, git, unit/e2e tests, any known framework or library, etc. A person who knows all those but hasn't memorized CTCI is a lot more useful than the CTCI memorizer with no evidence of work ever performed.

For example:

If you build computers, you should understand how the individual components are implemented.

If you build computer components, you should understand materials science and electromagnetism.

If you study electromagnetism, you should understand quantum mechanics and relativity.

Firstly, React is not compiled. Secondly the graph or tree or whichever aspect can come naturally when you come up with the idea of how it would be best to maintain JS apps.

In fact most important experience should have been grinding put tons of unmaintainable JS apps to come up with something like that.

The reality is that most programmers can go an entire career without being algorithmically challenged, and on the rare occasion you need to do/optimize something and don't know what the best options are, then you can either just ask a colleague, or ask online, or Google, or nowadays discuss it with an AI!

There is usually an experience and goals interview where a manager interviews the candidate to see if they would make a good fit for the team. That definitely involves a resume and a discussion of past work experience with the objective of confirm if they’re a cog or a tech lead :)

It can be important to split them up especially if you’re relying on more junior technical interviewers to validate coding skill. They won’t always know what they’re looking for yet along this axis.

This is interesting. I had never heard this before. Is there any research on this? For that matter, is there any actual research showing that leetcode-style interviews actually do predict performance? If so, do they do so any better or differently than an IQ test?

I would almost believe the opposite: if you actually pass those tests with flying colours, it shows me that you believe you needed to do that to be hired, while someone who's actually experienced would never in a million years step down so low.

Well said. Just like in college, calculus (not analysis) and organic chemistry are used as filter courses. Of course, why the two courses, especially organic chemistry, are so hard to American students is another topic. I personally think that it shows the failure of the education system of the US.

I get that this is uncommon, but if you scratch beneath the surface, most software (browsers, databases, compilers, OSes) are full of this stuff.

Even while I was consulting stuff like this would come up. At one company we were using a custom graphql wrapper around a CMS, and it was missing some functions we needed. The wrapper was implemented like a compiler from the cms’s data format to a set of query functions. Fixing it to do what we needed it to do was really hard and broke my brain a bit. But I did it. And I wouldn’t have been able to without understanding compilers and algorithms.

You can spend your whole career walking the beaten path adding features to apps and websites, and never traversing a tree at all. There’s lots of work like that out there. But if you ever want to go deeper, you’ve gotta understand data structures and algorithms. I know not everyone is suited to it, and that’s fine. But there’s definitely a reason big tech asks about this stuff.

Is this what lots of the folks mean when they claim tons of candidates “can’t even code?” Syntax or some names aren’t right for some particular language?

Shit, I forget the syntax for “for” loops or what the right way to get an array’s length is or what this language’s way of declaring a constructor looks like in languages I’ve written several hundred of lines of in the last few days, routinely, while under no real pressure at all. I crib off my own surrounding code for syntax hints constantly.

I’ve been doing this north of 20 years, and tend to end up as the guy to go to for tricky problems wherever I work, but I would fail 100% of whiteboard code-writing tests that gave any fucks about it being remotely correct in any particular language. I think the last time I could maybe have done it was when I knew only one language, and it was Perl, and I mostly wrote it in notepad—so, like, the first year or so after started writing code.

Or even using V = std::vector<T>;

for a concrete type T

Solves the problem. If someone denies you this, you don’t want to work there :)

How many times did you have to write tree balancing code with no reference materials?

That's quite an assumption. You've never heard of pair programming? You've never asked for help on a bug in your code? You've never talked through alternate approaches to a piece of code with a coworker? You've never hashed out an interface or a method signature or some pseudocode while talking through the problem? You've never walked through a calculation with an SME? All of these are "code and talk at the same time" exercises.

If I'm being brutally honest, I have a deep-seated suspicion that everyone who says they can't talk and code at the same time also just cannot code at all. I don't know you, of course, and I'd love to be proven wrong. My sample size is small, but the few people I've met who cannot talk-and-code also simply could not code.

Speak for yourself

It obviously worked for the candidate you mention, didn't it? Spent 7 years at FAANG, didn't know how to code.

Happened to me a couple of times back in university when I had to get an internship for one of the semesters.

Don't get me wrong I think it's silly, but

I’m sure plenty of people spend their career never learning or using data structures and algorithms knowledge. But I suspect plenty of people spend their career using this stuff all the time. Eg people who work in databases, compilers, operating systems, video games, ai, crypto currencies, and so on.

It calls them the same thing

Google would be a tier1-2, Uber/Lyft/Netflix would be tier 1, Adobe would be tier 2-3, etc.

If that's what they want, they should give out the questions in advance, and have the candidate prepare a slide deck. No professor conducts class by having students show up and fire random questions at them all semester.

More explicitly, if that's what they want, they should say that.

The second paragraph in this comment is very, very, very close to how my brain operates: <https://news.ycombinator.com/item?id=40290732>.

And I've been programming professionally for quite a long while now, so this quirk of mine doesn't seem to have made it difficult for me to work at programming shops.

[1] https://www.bls.gov/oes/current/oes151252.htm

When I’m doing particularly hard programming work, I can’t have words said near me. Even music with lyrics messes me up. I think because it wakes up my “thoughts to English” pathway and that gets in the way of my “thoughts to code” pathway.

Anyway, I don’t want to be cured. There’s nothing wrong with my mind. If anything I feel sorry for people who can’t turn off their inner dialogue, because it means they can never use those neurons for other tasks - like maths or programming.

Personally I can talk while programming if an interviewer wants that, but I’ll be a bit dumber at the keyboard than if I sat in silence.

$40k is extremely low for a senior role. Even in places like India or China.

I'm not saying these jobs are easy, or easy to get, but yes, they exist, even in this market.

The reality is the biggest drop-off in recruiting is at the very top of the funnel. Your basic phone screen and first technical screen -- before you get to a full panel. Once there you have way more, qualified, applicants than roles. I'm not sure it really matters which person gets the job, and this is one way you can make a fairly arbitrary decision. It's nice because it's within your control to grind some leetcode lol. From the company's perspective it's fair and has limited negative selection risk, and doesn't lead to as many regrettable hires.

If you've got 100 great candidates and 1 role, does it really matter which great candidate gets the job, so long as the selection process is relatively fair and uniform? From the company's perspective, probably not.

Since there's no feasible way to select the local maxima, the second sort is consistency.

But no licensing!

Are you in the EU? Salaries are lower across the board there for engineers.

In the US for Silicon Valley Type large Tech Companies the starting salary for New Graduate SWE's is 150k USD on the low end.

For a senior engineer at FAANG it can easily get above 500k USD.

This sounds interesting--what did you work on?

You can see higher values, but I think they look suspiciously like generic labels slapped over large something-opolies such as Google ("Web Search Portals, Libraries, Archives, and Other Information Services", mean $215k) or Uber and Lyft ("Taxi and Limousine Service", mean $187k.)

[0] https://www.bls.gov/oes/current/oes151252.htm#ind

I have my personal theory.

1) Top companies receive way more applications than the positions they have open. Thus they standardised around very technical interview as ways to eliminate false positives. I think these companies know this method produces several false negatives, but the ratio between those (eliminating candidates that wouldn't make it and missing on great candidates) is wide enough that it's fine. It does leads to some absurd results (such as people interviewed to maintain a library not being qualified despite being the very author) though.

2) Most of these top companies grew at such rates and hiring so aggressively from top colleges that eventually the interview was built by somewhat fresh grads for other fresh grads.

3) Many companies thought that replicating the brilliant results of these unicorns implied copying them. So you get OKR non sense or such interviews.

One angle is that SWE is one of the very few professions where you don't need a formal degree to have a career. It's also a common hobby among a sizable population.

I think this is truly great. A holdout breathing hole where people can have lucrative careers without convincing and paying off a ton of gatekeepers!

But I also think that when you hire in other industries, you can get much more milage from looking at the candidate's formal degrees and certifications.

In our industry, you kinda have to start from scratch with every person.

In general however, of course, there is/should be a round of interview that covers architecture/system design. It's just that the coding interview is a different interview type, which gives a different kind of signal, which is still important. It doesn't replace architecture interview, it complements it.

Basically an equivalent of simple algorithmic questions. Not "real" because it's impossible to share enough context of a real problem in an interview to make it practical. Short, testing principles, but most importantly basic thinking and problem solving facilities.

https://thenewstack.io/joel-spolsky-on-stack-overflow-inclus...

I am guessing here, but wouldn't a candidate for a traditional engineering role normally hold a college degree in a relevant field, so that part of quality assurance is expected to have been done by the college?

Being able to evaluate a person is a difficult soft skill to learn. An interviewer cannot learn nor improve it over night nor months nor years. This is basically being good at reading a person. Not to mention an issue with bias that is highly subjective.

If an interviewer isn't good at this, the solution would still be to supplement your evaluation with a coding interview.

The problem is that this kind of understanding is very rarely what coding interviews check for. They either don't check for this at all - instead just making sure people can write simple code while reasoning through a simple problems under time pressure - or they check for whether people memorized a textbook, looking for a specific non-obvious data structure and algorithm.

What I try to do, because I think it almost ticks all the boxes without asking for memorization, is ask questions that start with the simple "can you program at all" part, with follow up parts that end up in a place where we can have a conversation (without implementation) about how different tradeoffs could be improved, which often leads to discussing what useful prior art might exist.

Unfortunately I think this still has very high false negative issues. I've worked with people who prove to be perfectly capable of noticing when an appropriate data structure will make a big difference in their actual work, without that coming out in their interview.

I've seen lots of code that would be better if the author knew some basics. For example a report that took over half an hour to generate, I made a one-line change and cut the time to a few minutes - pretty sure I could have made it practically instant if I had taken the time to go through all of it.

And it's not like I'm some genius, I just understand the stuff I've been taught. Pretty sure most of my peers are supposed to have learned the same stuff, I think they just didn't really understand it.

I give a very basic business problem with no connection to any useful algorithm, and explicitly state that there are no gotchyas: we know all inputs and here’s what they are.

Almost everyone fails this interview, because somehow there are a lot of smooth tech talkers who couldn’t program to save their lives.

Probably recent job performance is a stronger predictor of near future job performance.

Honestly, having been in both worlds, there's not too much of a difference. Physics is harder but coding you got more things to juggle in your brain. So I really do not think it is an issue to offload infrequent "equations"[0] to a book/google/whatever.

[0] And equations could be taken out of quotes considering that math and code are the same thing.

You really need those 100x faster algorithms when everything is a web or Electron app.

Fuck man, people do this with engineers who work on classified projects. You all are over thinking it. You're trying to hyper optimize for a function that is incredibly noisy and does not have optimal solutions.

What would be the point of asking theoretical questions?

There's just no way in hell people can remember even 10% of what they studied in college, book knowledge isn't really the goal, rather than teaching you how to learn and master the topics.

[0] https://xkcd.com/451/

Would it have been better for the person who originally wrote that just-iterate-the-list implementation to have been thinking about data structures and algorithms that would perform better? Opinions on this vary, but I tend to come down on the side of: Optimize for human productivity (for both the writer and the many future readers) first, then profile, then optimize any bottlenecks.

My assumption when I come across something that turns out to be a performance bottleneck that is easy to fix with a better data structure or algorithm, is that the person who wrote that was consciously doing a simple implementation to start, in lieu of profiling to see where the actual bottlenecks are.

But I also understand the perspective of "just do simple performance enhancements up front and you won't have to spend so much time profiling to find bottlenecks down the line". I think both philosophies are valid. (But from time to time I do come across unnecessarily complicated implementations of things in code paths that have absolutely no performance implications, and wish people wouldn't have done that.)

This wasn’t an off-by-one or didn’t handle overflow, but rather was couldn’t get started at all.

But I still think you can reasonably weed these people out without these whiteboard problems. For exactly the same reasons engineers and scientists can. And let's be honest, for the most part, your resume should really be GitHub. I know so much more about a person by walking through their GitHub than by their resume.

You still can't get GPT to understand and give nuanced responses without significant prompt engineering (usually requiring someone that understands said nuance of the specific problem). So... I'm not concerned. If you're getting GPT to pass your interviews, then you should change your interviews. LLMs are useful tools, but compression machines aren't nuanced thinking machines, even if they can mascaraed as such in fun examples.

Essentially ask yourself this: why in my example was the engineer not only okay with me grabbing my book but happy? Understand that and you'll understand my point.

Edit: I see you're the founder of Archipelago AI. I happen to be an ML researcher. We both know that there's lots of snakeoil in this field. Are you telling me you can't frequently sniff that out? Rabbit? Devon? Humane Pin? I have receipts for calling several of these out at launch. (I haven't looked more than your profile, should I look at your company?)

But when I am asked to do a one hour part of an interview for four interview loops a week, all the preps and debriefings, and also do all my normal day-to-day deliverables, we need some fast filters for the obvious bullshitters. The interviewing volume is very high and there is a lot of noise.

There are plenty of reasons not to code on spare time. If anything the people who are most likely to do that are often also the people who coding interviews are supposed to be privileging, fresh single college grads.

I don’t know how people would square the statements “take-home assignments are unpaid labor and unfair to people with time commitments” and then do a 180 and say “people should have an up-to-date fresh github that they work on in their spare time.”

godelski said your resume should really be GitHub. You could have said this instead of sarcasm.

How each candidate answers each question themselves tells you about them.