Technical Interviews Reject the Wrong Engineers

[-]

moreVCAs@reddit

I feel like I need to read this specifically because it’s OC from u/fagnerbrack

[-]

Rokuro142@reddit

It's not original because it was largely LLM written and it's not content because it's basically noise, so I call that into question.

[-]

rtt445@reddit

did not read because of mediums popups

[-]

fagnerbrack@reddit (OP)

I built a public mirror on my read-it-later project to bypass the login wall, I just didn't post it cause it's not the original link. I hope that's useful..

[-]

rtt445@reddit

14 requests 290.72 kB / 197.53 kB transferred Finish: 797 ms DOMContentLoaded: 545 ms load: 703 ms

Good job, medium needs to take note lol.

[-]

fagnerbrack@reddit (OP)

No Frontend frameworks and I didn't spend time to do any optimisation Btw, not even gzip

[-]

rtt445@reddit

Yea the web is insanely bad these days. No one cares about efficiency.

[-]

Ranra100374@reddit

Archive.ph link:
https://archive.ph/85rWG

[-]

rtt445@reddit

Wow what a difference in load time and responsiveness.

medium: 117 requests 7.68 MB / 2.81 MB transferred Finish: 23.31 s DOMContentLoaded: 1 s load: 4.45 s

archive: 16 requests 881.39 kB / 303.29 kB transferred Finish: 2 s DOMContentLoaded: 953 ms load: 1.92 s

[-]

CherryLongjump1989@reddit

Stop using Chrome, switch to Firefox.

[-]

i5-2520M@reddit

What relevance does the browser have?

[-]

CherryLongjump1989@reddit

Maybe nothing, I just don't understand the problem. It's not a paywall or sign-up wall, and it's not actually a pop up.

[-]

rtt445@reddit

It pops up over text and interrupts my flow. I came for the article and expect to start reading right away. Don't immediately interrupt me with this begging ware. Maybe ask at the end.

[-]

DreadStallion@reddit

Chrime doesnt allow full adblocking plugins

[-]

i5-2520M@reddit

Adblocking plugins don't generally block popups like that. And also manifest v3 blockers are good enough especially if you give them access to the pages you visit.

[-]

Technical interviews index on aptitude, which is why they're often arbitrary LeetCode-style DSA challenges that don't represent real-life work. Because it's not meant to, it's just meant to see if you have coding aptitude, and when there's way more unqualified candidates than qualified, you need an an aggressive filter than prioritizes precision over recall.

For a company, the interview process for a given position doesn't need to accept every qualified candidate, it just needs to accept one or two, since only one can take the position in the end.

[-]

Chwasst@reddit

> and turn thoughts into code in real time

I really wonder if I’m simply retarded or y’all have absurd expectations because there’s no way I can spit out code in real time without internalizing and building context of given problem inside my head first. Which takes more than 15-30 minutes that I have during an interview. The only way to circumvent this issue is to grind similar problems beforehand as much as possible so the pattern is still fresh in my memory.

[-]

light24bulbs@reddit

I do this to and I have a way easier time reading the code of people who do this. In my experience, people who have trained to immediately start coding a problem without much forethought often write unmaintainable garbage, but do it quickly.

[-]

catplaps@reddit

This is a weird comparison to make. Whiteboard code isn't a production codebase, it's meant to see if you can describe the shape of a problem using the language of code.

[-]

thezerofire@reddit

unfortunately companies frequently expect multiple correct solutions these days. it was 3 for Meta in 40 minutes in 2024 and when I asked they said that all candidates who went through to the next round solved all of them. this wasn’t out of the ordinary in my experience

[-]

catplaps@reddit

Well, these problems are by nature very low-context. If I said "here's an unsorted array of integers, sort it for me," could you whiteboard that on the spot in your language of choice? Obviously an interview question wouldn't be quite that basic, but I would say they're generally not too much beyond that in terms of required context and setup.

When I was conducting a lot of whiteboard interviews (also Google), I was specifically looking for two things. One: can you actually write code in your language of choice? I mean this on a quite basic level. I want to see that you're fluent enough with the syntax and paradigms of your language that you can, you know, actually write it and not just copy-paste it. Two: how well can you analyze and unpack a problem and reason your way through it? This is a very interactive step and doesn't have to be perfect. It's more about being able to explain your thought process and being able to take hints and feedback and change direction.

My opinion after doing well over a hundred of these was that the whiteboard coding part was absolutely necessary. So many people, SO MANY, talked a great game and had an impressive resume and made it all the way to an in-person technical interview, and literally could not write the most basic lines of code in their preferred language. I'm not talking "solve the riddle of the Sphinx" here, I'm talking, pass a parameter or write a for loop. Those are the people I was there to screen out.

What do you think, is this an absurd expectation?

[-]

lilpig_boy@reddit

i think the days where it doesn't have to be perfect are long gone. at least within machine learning. if i make a mistake, am unclear, anything, i'm done in that pipeline. i see the same thing on the hiring side.

[-]

Chwasst@reddit

Like you said those problems are often not THAT simple, you also need to account for increased stress during an interview. So in most cases there’s no way I’m delivering you a complete working solution during short interview - which often times is expected. Disclaimer - I’m not talking about big tech companies, I’ve never tried to get into them. Just my general experience.

Don’t get me wrong. I 100% agree with your stance on testing the reasoning, how a candidate thinks about abstract stuff, walk through the entire process. This is actually a good practice. I will gladly flood you with my stream of consciousness and tell you how I’d tackle the problem at hand. But please don’t expect that I will deliver the code at the same time. That area of my skill set is simply not available to me until I finish the pattern recognition & problem solving part inside my head and I entered calm flow state.

[-]

hibikir_40k@reddit

There is such thing as not having to grind, and being just that good at coding. That's the people who this whole idea was looking for anyway: Not very many. It just happens that you cannot keep your interviews secret, so most people grind. And as more grinders came in, the problem difficulty levels had to spike, because otherwise too many bad people passed.

There's places doing debugging interviews, and they are often divisive because that's the same kind of thing as those early leetcode attempts. You are handed an unknown, large-ish codebase, and a broken test that fails for subtle reasons. Do you have the reading and navigation skills to just find it and fix it in time? You see people that just don't have it, and would take a day. Then you have some candidate that looks at the other test cases, realizes more or less where the problems might lie, and just nails it in 10 minutes, having never seen the project in their lives. But you cannot reuse a test like just like you cannot reuse a leetcode, as if it leaks, you lost all your signal.

[-]

Chwasst@reddit

The kind of person you’re talking about is literally top1% of developers out there. The issue is that in current market EVERY company wants just that and nothing less.

I am not that good and I won’t ever be. I’m fine with it. Just please let’s stop pretending like we need top tier devs for every CRUD dashboard app that exists out there.

Then another issue might be those top1% individuals can have rather big ego. This might or might not hurt your team long term. There’s much more to software development than just coding.

[-]

Murky-Relation481@reddit

Yep, not to toot my own horn but I am one of those idiots (and I say that self lovingly). It's a lot harder to work on a team because I will move much faster and the mental constructs in my head take longer to translate to instructions for a team vs. me just blasting it out.

This is not an endorsement of that behavior. It very quickly leads to burn out and long hours.

[-]

wavefunctionp@reddit

It’s really an intelligence test in an era where intelligence tests are largely illegal.

[-]

Chwasst@reddit

Please explain me what blitz coding has in common with intelligence? I may be not the best/fastest coder but I’m definitely not stupid and I know my worth based on stuff I built throughout my life.

[-]

Full-Spectral@reddit

And if you really spit out code like that, you'd likely be fired within weeks because it would all be bad. And anyone claiming they can do it are either hallucinating, working on trivial software, or repeatedly doing the same thing over and over so no thought is required.

[-]

Emperor_Abyssinia@reddit

What do you think of letting candidates use ai in the interview?

[-]

dmpetersson@reddit

Spot on, matches my experience as well (but then again I’m also an ex L6 SWE)

I’d like to add one thing; performance under pressure is critical. When stuff is burning or project pressure is high you need to be able to perform. Whiteboard interviews tests this! (And you think you don’t need this then you misunderstand the nature of the SWE role at G)

[-]

rask17@reddit

This comment is indicative of the whole problem with software interviewing like this.

"Whiteboard interviews tests this!" But do they? Based on what? What studies if any actually back this statement?

These sorts of statements are almost always based on vibes. You can claim its from experience but:

* How many times have you actually hired "unqualified candidates" who struggled specifically on whiteboard tests and then went on to fail because of project pressure?
* Were confounding variables taken into account?
* Was it a statistically significant sample size?

The answer to the above questions are always no if the person is being honest.

[-]

spcbeck@reddit

Insane, I've worked on high pressure engineering team, including on-call shifts where I've been woken up at 3am to debug and fix issues as soon as I can. I'm very good at that (which usually involves sifting through logs to find an error, which you then fix). Leetcode and algorithmic interviews do not test your abilities to handle those situations.

[-]

dmpetersson@reddit

Congrats.

Again. If you think I’m looking for leetcode answers then you have no idea of what a technical interview is.

I ask hard concrete questions to test your ability to solve technical problems with code.

If I get a leetcode answer back then I asked a bad question. Ofc you need have a reasonable solution to the problem but the reasonable range is pretty wide.

[-]

ArtOfWarfare@reddit

I (Senior SWE who has conducted dozens of interviews and hired a few) have heard this idea before, and my counter is that if we just want to figure out how a candidate handles being under pressure, we should set it up more like an episode of Hot One’s and just make candidates eat increasingly spicy chicken wings during the interview.

Is it not equally viable while being easier to conduct and more entertaining?

I’m only somewhat serious - mostly I’m not because I’d fail if this were actually an interview process.

[-]

dmpetersson@reddit

That sounds horrible. I’ve got an interview count well beyond 150…

It is a high stress situation. You try as hard as you can to make it as easy as it can be. Anything else would be evil… (and we didn’t do evil)

[-]

UloPe@reddit

JFC how for up your own ass do you have to be to think that handling being evaluated in an interview situation (that could potentially have serious long term consequences for your career) is in any way related to dealing with high pressure work situations?

[-]

dmpetersson@reddit

Stress is stress; no matter where it originates from.

Also. You have no idea how I conduct interviews. So don’t assume I try to make it any worse then it already is.

[-]

UloPe@reddit

You have any scientific literature to back up that claim?

[-]

TomWithTime@reddit

They must have a very active LinkedIn profile

[-]

ankercrank@reddit

> Precision over recall

Memorizing graphing and sorting algorithms is the definition of “recall”.

[-]

CircumspectCapybara@reddit

I'm talking about precision vs recall in the ML sense of the words.

Basically when a data set is heavily unbalanced and has many orders of magnitude more negatives (unqualified applicants) than positives, and you really don't want to make a bad hire, you want extremely high precision, i.e., extremely low false positive rate.

Meanwhile, when hiring for a given position, if there are 1000 qualified applicants you'd be equally happy with, it's usually the case you don't need to identify all 1000 of them, if you only identified like 1 or 2 of them (at the expense of rejecting 99.8-99.9% of the qualified), that's all the same as if you identified every single one of them, because in the end you can only extend a couple offers and only one can end up taking the position.

[-]

jmickeyd@reddit

They mean precision and recall in the formal statistics definition.

Precision = true positives / ( true positives + false positives )

Recall = true positives / ( true positives + false negatives )

Thus they're emphasizing that hiring a unqualified candidate is worse that not hiring a qualified one.

[-]

ankercrank@reddit

"precision over recall" what a weird expression.

[-]

jmickeyd@reddit

Oh sure, I'm not making any comment on the correctness of the opinion, I just wanted to point out that they didn't mean "recall" as in memory.

"precision over recall" what a weird expression.

I'd put money on them being an machine learning engineer. Those terms are extremely common in that space.

[-]

ankercrank@reddit

They did say they work at Google... what else are they working on these days? :p

[-]

shockputs@reddit

Didn't Google shoot themselves in the foot with that when assembling the Android systems team? Didn't they have to completely ditch that whole system because the best Linux kernel developers were just hackers and were completely unfamiliar with CS theory and DSA challenges found in leetcode? There's an article about that somewhere...

You're not wrong about many unqualified applicants needing to be vetted out through some form of automation...

[-]

metaphorm@reddit

the problem is about false negatives though. if the interview process is eliminating people who are qualified, and might be better candidates on other measures, then there's something flawed in the process.

you might except that as a trade-off. everything has trade-offs. but it's still likely the hiring process is biasing towards a more narrow range of qualified than would be ideal.

[-]

TheESportsGuy@reddit

The ones that pass would all be fine hires.

Nonsense. Your false positive rate is not 0. You may be doing it the best way possible (doubt it, since your company is massive), but your false positive rate is > 0.

[-]

agent00F@reddit

The problem is hiring is just about the most important thing, which is contradictory to "easily administered test". The most important aspect in an engineering company is ability to engineer, so it's unfortunate how many technicians still get hired because that's what straight leetcode q&a filter for.

[-]

you-get-an-upvote@reddit

Exactly, which is why it’s baffling this blog claims that an issue with technical interviews is that they are trying to find good candidates, not reject bad candidates.

Literally nobody is arguing that interviews have zero a false negatives.

The author’s alternative (which is only given in the last two paragraphs…) seems reasonable (give business problems your team actually has) until she has to claim (to avoid running afoul of her own criticism) that the interviewer giver is just as blind as the candidate.

This is hopelessly impractical! Is someone else on your team going to come up with a novel problem that your interviewer has never seen before for every candidate?!

[-]

Full-Spectral@reddit

But, that's not required. All you have to do is ask the candidate about a problem he's worked on, and probe him for details. At the level these silly leetcode interviews are filtering for, any good developer should be able to figure out if someone knows what they are talking about pretty quickly like that, and get a lot better feel for them than the leetcode problems would provide.

[-]

East_Lettuce7143@reddit

FAANGs are like women on the apps.

[-]

fcman256@reddit

You’re making the assumption that interviewers ask the same kinds of questions and evaluate technical interviews the same way you do. In my experience FAANG does a pretty good job of asking complex questions that can be reasoned through, however there are a lot of companies out there who ask questions that have very specific tricks or require certain algorithms for the correct solution. I think that’s where a lot of people have gripes.

[-]

k_dubious@reddit

A genuine expert gives a sparse answer, not because they lack depth, but because their cognition doesn’t work through explicit rule-following. The interviewer marks this as shallow thinking. It is the opposite.

This is all well and good, but in the real world saying “trust me bro” doesn’t get you very far in design discussions and code reviews. If you can’t work backwards from your intuitive solution to convince other people why it’s right, you’re bad at your job.

[-]

TimmyC@reddit

They are not indexed on rejecting the good engineers, they are indexed on not hiring the bad engineers

[-]

red_planet_smasher@reddit

I nominate this for “least surprising post title of the day”

[-]

psyyduck@reddit

lol keep reading the comments here. It’s really not obvious to a LOT of people.

[-]

BeautifulCuriousLiar@reddit

it’s either this or clickbait titles 😭

[-]

ExecutiveFingerblast@reddit

The interview approach these days is derived from contrived metrics and idea from MBAs and business consultants not recognizing there's a difference between talent pipelines and learning in the job versus just being placed to be immediate contribution.

[-]

Serious-Regular@reddit

How many whiny "I got rejected by FAANG and I'm great so FAANG is doing it wrong" blog posts do you think there are out there? 1000? 10,000? My favorite part of this genre of self-help is none of these people can reconcile their theories with the fact that clearly the process is working.

[-]

R2_SWE2@reddit

The problem with these takes is precisely because people consider the perspective of people getting rejected from jobs and not the companies doing the hiring. Companies are optimizing to eliminate false positives, not false negatives. They’re more than happy to lose out on great candidates so long as they have the smallest possible chance of hiring a bad candidate, because bad employees are expensive.

[-]

Serious-Regular@reddit

That's as bingo!

[-]

CherryLongjump1989@reddit

That's not what the blog post is talking about, though, is it? I see nothing about the author getting rejected from FAANG.

[-]

Freedom_33@reddit

That’s not what this article seems to be about for the most part. It covers stuff like anxiety at whiteboards, etc. from the article:

“This post is about what the research says, where the common tools break down, and a framework I built to measure interview quality itself”

[-]

CollaredParachute@reddit

Google has a near limitless supply of talented devs applying. Why should they seek people who have whiteboard anxiety?

[-]

TribeWars@reddit

Also, if you aren't able to deal with whiteboard anxiety, what are the odds that there isn't some other stressful situation you aren't equipped to deal with on the job?

[-]

oneHOTbanana4busines@reddit

Anecdotally, I’m bad at whiteboard interviews but good at whiteboarding in plenty of other scenarios. I’m also fine being on call and regular job pressures don’t bother me at all.

I’m generally a high performer based on metrics improvements when I’m dropped into a new team but a terrible interviewer because of my anxiety disorder. It’s a super cool spot to be in.

[-]

yerfatma@reddit

Huh? Everybody who uses the whiteboard approach runs a company where there are going to be stressful situations comparable to standing in front of a group of strangers and being quizzed on an arbitrary problem you may never need to solve at that job?

When I interview at a place, I am actively interviewing them to make sure they aren't a stressful tire fire. A bad deploy that requires a page and waking up in the middle of the night and trying to debug is one thing. Optimizing for people who can/ want/ need to do that feels like a recipe for winding up with a place that does it all the time. They people I have truly learned from in my career tended to seem slow or even ponderous, but that's because they were actually thinking about the questions I asked.

"Slow is smooth and smooth is fast."

[-]

Freedom_33@reddit

I think my comment was that the article was not about FAANG interviewing techniques

From the article one of the studies they pointed to showed that in one study woman were disproportionately negatively affected by the whiteboard test compared to paper test as opposed to men.

Not my opinion or study, would be in article. My question was if comments should be about article contents or guesses based on title of article.

Did you read the parts of the article that talked about the whiteboard anxiety?

[-]

Freedom_33@reddit

I think my comment was that the article was not about FAANG interviewing techniques

From the article one of the studies they pointed to showed that in one study woman were disproportionately negatively affected by the whiteboard test compared to paper test as opposed to men.

Not my opinion or study, would be in article. My question was if comments should be about article contents or guesses based on title of article.

Did you read the parts of the article that talked about the whiteboard anxiety?

[-]

fuddlesworth@reddit

I knew someone who got into faang only because he's good at leetcode style puzzles. He was a trash software engineer though.

[-]

Downtown_Isopod_9287@reddit

How much of those profits are a business process versus a technical one?

What opportunity cost (if anything) are we paying by allowing tech companies to be the most profitable firms in the economy?

[-]

Miserable_Ad7246@reddit

You want answers to this question and hiring process? Don't look at FAANG, look at HFT. Where is no product, no market fit, no customers, just code and models. It will give you clear answer.

[-]

Downtown_Isopod_9287@reddit

HFT is… literally nothing BUT business process, it’s in the name. Don’t confuse focus or narrowness of application with technological innovation.

[-]

Miserable_Ad7246@reddit

?? HFT and quant trading is literally algorithms and code bases vs algorithms and code bases. Where is no marketing, no market fit, no advertising, no clients.

Its as pure as it gets. Either your code and models are better (faster/smarter) or they are not. That it.

There is no business in a usual sense here. You enter the competition and you take part of the prize pool.

If you are wining that competition its only and only because you have better solution, and if you have the best solution it means you hire and structure your internal culture in the most efficient fashion. By definition you are correct in your desisions.

Also if you think FAANG interviews are "incorrect" wait until you try HFT, its even more brutal.

[-]

Schmittfried@reddit

The latter is not really a problem for Google‘s hiring team to solve though.

[-]

Wonderful-Citron-678@reddit

We know objectively innovation slows in these companies, typically new products come from acquisitions. Not to say there is zero but some examples are egregious, like Meta appears to be a dumpster fire to me. The few people I know there only have horror stories.

[-]

East_Lettuce7143@reddit

How many whiny "I got rejected by FAANG and I'm great so FAANG is doing it wrong" blog posts do you think there are out there? 1000? 10,000?

At least this one and mine from 10 years ago when I was a cocky and salty junior dev who go rejected from Google lol.

[-]

yerfatma@reddit

clearly the process is working ie FAANG

Is this a serious response? I've been doing this for 25 years on both sides of the table (FWIW, including places like though not as famous as the ones you name check) and so much of this is true. In the last 5 years or so, what I have perceived as ageism feels like something I run into, but I think it can also be how I talk about a problem or solve it probably sounds hand-wavy to people with a lot less experience. I also am impatient with questions with a trick to them, questions where the team is looking for a single specific answer and, worst of all, the TLA quiz. Had an interview last year with a "start up founder" right out of college who only cared how many AWS acronyms I knew. Who cares? Some days I can barely tell you how to lowercase or strip a string in a language I've worked in for more than a decade. Those kinds of things are problems for Intellisense, Google, the dear-departed Stack Overflow and now Claude.

It is my theory tech (at most places; I've been at 2 or 3 that managed to avoid it) hiring has a fatal flaw within it: given time, every dev team will evolve an interview process they would not pass. Your dream candidate is always going to be someone that can drop right in, do everything your team already does and see further, so why bother hiring someone that just seems "average".

How many stories do you need to hear from Google engineers, etc about how you can no longer advance by improving things, but rather by redoing them? killedbygoogle.com exists; is that a list a result of a process that is working?

[-]

TheChildOfSkyrim@reddit

I could add that some skilled candidates are rejected for personal and communication skills, or even for the lack of "chemistry" with the rest of the team.

Especially at FAANG-size companies, team work is everything. You spend more than half of the time in discussions, meetings, messaging, etc. It's like with multi-threading: more workers == more communication. Small startups work perfectly fine with solo players who don't say a word all day, big companies don't.

[-]

who_am_i_to_say_so@reddit

Frankly I’m just so sick of the same 5-6 companies being talked about.

[-]

Nullberri@reddit

It doesn’t mean the process isn’t broken. It just means software companies haven’t figured out a system that is meaningfully better. Google has written several articles how their hiring process is just so so. They said there was very little correlation between performance and how well you did in the interview. Obviously we can only grade those who past but still. The process seems to filter plenty of otherwise competent engineers along with the incompetent.

[-]

Markavian@reddit

https://www.plannedman.com/the-means/work/jordan-peterson-looks-into-your-soul-predicts-your-career-success/

There are simple jobs and complex jobs. That’s the first thing that’s worth knowing. And it’s a continuum really, but a simple job is one where once you’re trained, you just repeat what you’re doing. So, so factory line work would be what would be an example of that or. Or checking out people at a grocery store, restocking, grocery shelves or, or jobs like that.

The best predictors for success in those jobs is conscientiousness. Trait, conscientiousness, and conscientious people are orderly and industrious. And we don’t exactly know why they are. It seems like it’s associated oddly enough, with such things as disgust sensitivity. So maybe people are conscientious because they get disgusted with themselves if they’re not useful and they get guilty if they’re not engaging in productive enterprise; maybe that’s a marker for a kind of complex social responsibility

...

Uncontroversially, selecting candidates based on IQ is not terribly common. My hot take is; technical interviews are a rough approximation for IQ attributes... but the HR/management discipline is so entrenched that the wider market is unlikely to change that process even when presented with the data. We'd have to retrain an entire management class.

[-]

IanisVasilev@reddit

Just because the whiny posts are annoying doesn't mean that the interviewing process isn't broken. If we go over a list of what makes money, I'm sure at some point you'd agree that profits are quite an artificial may to measure success. Prioritizing profits requires sacrifices that lots of us don't like doing.

Rich companies naturally attract good programmers, however they also hire a lot of questionable ones. I've encountered people that are not only useless, but also drag others down.

Consult this recent post about Microsoft for a more concrete example. I'm sure you've heard/experienced fun stories about AWS and GitHub lately.

At some point your bad decisions start firing back at you and "we made profits last year" becomes meaningless.

[-]

Schmittfried@reddit

I don’t think that’s an accurate proxy for hiring quality. To quote a Google engineer, „Nobody knows what they’re doing and it’s somehow raining money regardless, so we just keep working on cool stuff“.

That’s not to say I disagree. I think some of Google‘s hiring criteria are very solid and their process generally tries to eliminate personal biases and judge people by their actual ability. Leetcode might not be the best proxy for a typical software engineering role and in theory they are rejecting many false negatives from roles where they couldn’t do much harm to begin with, but they gotta filter somehow and they have to do it efficiently. Leetcode at least tests for a minimum problem solving ability and the follow-up questions tackle more practical concerns like testing and your thought process. It’s a good enough proxy to warrant rejecting some good people.

[-]

seriousnotshirley@reddit

If a candidate didn’t understand that the process is designed for the company and not the candidate I don’t want to hire them.

The cost of a false positive far far outweighs the cost of a false negative for most companies.

[-]

matthieum@reddit

If your Technical Interview is about the destination -- the "solution", the "code" -- you're doing them wrong.

An interview is first and foremost an opportunity to talk to the candidate, and learn how they work their way through a problem. It's about the journey:

Can they tease what's missing from the problem description?
How good are they at formulating questions to clarify said problem description?
How good are they at communicating their ideas to the interviewer?
How good are they at articulating the trade-offs of their ideas?
How good are they at recognizing when they took a wrong turn?
How well do they accept the idea that they took a wrong turn?
...

Sure, on the way you'll get to see whether they pick things up quickly, rebound, know a handful of tricks... but those are a tiny part of the picture, and rely too much on luck, to really give a good picture of the candidate.

The Technical Interview is there to answer the question: would I like to work with this candidate?

Examples of red flags:

A candidate who cites random irrelevant facts to show off their knowledge. I want to work with a problem-solver, not a parrot.
A candidate who never admits their idea is bad, or they made an error.
...

Of course, the interview is a two-way street, so the candidate should likewise think whether they'd like to work with the interviewer. The same red flags apply...

[-]

CherryLongjump1989@reddit

The blog post feels like 3 unrelated and contradictory essays stabled together. The author appears to want to say three things simultaneously: 1) interviews matter enormously because bad hires are catastrophic, 2) interviews don't work because bias and Dreyfus mismatch corrupt them, and 3) author's own framework to make interviews work, even though it doesn't have anything to do with solving either essay 1 or 2.

I honestly can't follow the logic.

[-]

aanzeijar@reddit

I’ve spent over 15 years observing and researching technical interviews.

Nah, c'mon Fayner, we know you sit on Reddit most of the time posting stuff.

[-]

KandevDev@reddit

the article isnt wrong but its framing is tired. the actual finding from a decade of interview research is that any single-channel filter rejects 70%+ of qualified candidates including the loudest one used in tech, the timed coding screen. the fix isnt 'better interviews', its multiple uncorrelated signals run in parallel. nobody does this because its expensive.

[-]

CherryLongjump1989@reddit

I don't know anyone who doesn't do multiple rounds of different kinds of interviews.

[-]

zactral@reddit

They might but they will usually reject immediately after one doesn't pass and if this screen is the first one the only candidates who will ever see other interviews are the ones who are already able to clear it.

[-]

african_or_european@reddit

One major concern I have always had when considering a borderline hire is the effect being wrong would have on the employee's life. If they are unemployed and it's a remote job, it's not really an issue, but "back in my day" when I was hiring it was in person and and not infrequently relocation was involved. Together that made me much more conservative when choosing people to move forward through the process. I didn't much care about the impact to the company (they were big companies and, well, not my money).

But I'm not sure I would have been able to sleep at night knowing that I recommended despite what the typical processes would have had me do, only to end up being wrong and having to fire someone 6 months after they quit their job and uprooted their life to relocate.

That isn't to say I didn't do it occasionally, but I had to be damn sure I was right.

[-]

sasik520@reddit

This article is an eye opener.

One of the most surprising discoveries is how little all the hr I ever met knew about the recruitment process and how much more knowledge could they (iif they knew it) teach the technical reviewers.

What a potty I haven't read it 2 weeks ago.

And, btw., the r= d= factors in the article pop out of nowhere. What do they mean?

[-]

helpprogram2@reddit

My companies technical interview is me asking you to write a little code and then talking about it. All I ask is you understand concurrency in Java. We only hire sr engineers. Still none of you lazy fuckers ever pass

[-]

popcapdogeater@reddit

I worked in an IT department once where we hired a guy for a very basic helpdesk role who was a bartender and played in a band, the key thing that stood out in the interview was he was having some computer problem and he found it required making a registry change and something else and then it worked, it's been a long time so I can't remember all the specifics but the way he articulated the his troubleshooting process is a good deal of what got him the job. Specifically to me the way I could tell he was reliving the annoyance of the moment, the same annoyance I get when I'm fixing novel problems.

We had him doing AD management and writing batch scripts after a year.

And of course I've worked places where we've hired very technically trained people but they just don't seem to live up to the expectations we had.

This is a soap box of mine obv but for most entry roles I would take untrained people who can somehow convey to me they have a drive to fix problems over anythign else.

[-]