Hacker News Reader

Comment by PragmaticPulp | Hacker News Reader

Consensus seems to lean toward this being satire. However, that’s actually part of the problem with online discussions of interviewing right now: Everyone loves to read and write about how developer interviewing is flawed, but no one wants to go out on a limb and make suggestions about how to improve it. It’s easy to be a critic and it’s fun to be smugly dismissive of those companies who rejected you after long interviews, but it’s hard to actually step into the hiring manager position and find the best candidate without disappointing some people along the way. Writing satire or criticism is an easy way to win clicks and views because you’re not going to alienate people with the tried and true “all interviewing is bad” claim.

Sadly, many of the implied alternatives to coding interviews are becoming a regression toward credentialism: People who have already secured good jobs, impressive internships, or prestigious university degrees would much rather coast on those credentials than be challenged for a few hours during an interview. This feels good if you’ve already made it or you grew up with the right connections, but it’s far from ideal you’re a promising developer who doesn’t yet have the right credentials on your resume to unlock the job. To many people, the coding interviews is a chance to break the traditional mold and land a job that would have been out of reach otherwise.

View on HN

> Everyone loves to read and write about how developer interviewing is flawed, but no one wants to go out on a limb and make suggestions about how to improve it.

I've spend this year writing about hiring[0], both to talk about the problems and provide suggestions on how to improve the process. My suggestions are sometimes high-level, and sometimes very detailed. Some examples:

- Be specific about the requirements [1]

- Tailor the requirements to the role you're hiring for [2]

- The types of non-technical issues that can cause a candidate to perform poorly, and how interviewers should correct for them [3]

- Let people work independently [4]

But above all, my primary thesis is that it comes down to looking for strengths, not trying to discover weaknesses [5]. Having been on the hiring side, this is the specific suggestion that I believe will have the most impact, especially to those who want to land a job that would have been out of reach otherwise.

[0] https://hiringfor.tech

[1] https://hiringfor.tech/2020/03/02/are-you-asking-candidates-...

[2] https://hiringfor.tech/2020/06/22/hiring-for-the-role.html

[3] https://hiringfor.tech/2020/05/25/letting-the-little-things-...

[4] https://hiringfor.tech/2020/08/03/reducing-interview-stress-...

[5] https://hiringfor.tech/2020/02/10/false-positives-and-false-...

> But above all, my primary thesis is that it comes down to looking for strengths, not trying to discover weaknesses [5].

I strongly agree. I think a generation of software engineers has been trained to calibrate their interviews by looking for reasons not to hire someone, instead of looking for reasons they should.

This perpetuates all sorts of biases in the hiring process, and it insidiously serves as a form of self validation as well.

The problem is that you can find a reason to hire almost anyone. Now most companies just need someone to write boring line-of-business applications so maybe that's okay, but if you're working on anything novel hiring the wrong person can be very expensive. I don't think there's any intrinsic negative in keeping a high bar for hiring.

I think most people vastly overestimate the novelty of what they're working on. Most people writing software at Google actually aren't doing more than gluing APIs together on a day to day basis. In that sense it's much more important for them to have a solid understanding of reliable infrastructure and system design than algorithms and data structures. Indeed, this shows in the way they interview for people who aren't new grads.

Looking for strengths isn't the same as lowering the bar. If you have specific requirements, you will maintain those requirements. But, the goal is to push aside weaknesses that don't matter (such as nerves during an interview, or lack of truly unrelated knowledge).

Instead, the goal should be to ensure _qualified_ candidates can demonstrate the strengths they have in meeting your requirements.

So basically, there are two pieces to looking for strengths:

1. Determine which requirements truly matter. Even for highly technical jobs, interview skills are not what makes a successful employee.

2. Find ways for those who meet the bar to demonstrate that fact.

The author has stated that this article was not meant as satire, even though some parts are exaggerated[0].

I do not like much of this advice, even if some of it may be true. For example, I believe that the sum of a team can be greater than its parts, and hiring for talent alone can result in a poorly functioning team.

[0] https://twitter.com/dsafklasdfnas/status/1315699986403786753

I think it is and it isn't. The author definitely believes in testing for people's IQs, so I think the whole section on "identifying talent" is meant to serve as a reductio ad absurdum.

Some of the author's tweets about identifying talent, IQ, and temperament:

· https://share.getcloudapp.com/YEuyyKbE

· https://share.getcloudapp.com/z8uYY5gZ

· https://share.getcloudapp.com/E0urr8B5

And working memory isn't part on an IQ test I score fairly high on IQ but have poor short term memory.

“ People who have already secured good jobs, impressive internships, or prestigious university degrees would much rather coast on those credentials than be challenged for a few hours during an interview. This feels good if you’ve already made it or you grew up with the right connections, but it’s far from ideal you’re a promising developer who doesn’t yet have the right credentials on your resume to unlock the job.”

Perhaps we could interview different people differently?

I don’t know why we have this obsession with subjecting experienced candidates to the same whiteboard gauntlet as a new grad. In fact, after a candidate has a bunch of experience you’d better be screening for other factors, since the role of an experienced developer can/should be dramatically different than someone with a few years of experience.

But no, still with the “challenges”. If you can’t do obscure puzzles with the same fidelity as you could six months out of college, it’s a no-hire!

I can't tell you how many people I've interviewed that were "experienced" developers that were just terrible terrible engineers.

My favorite interviews were when we were trying to hire a senior level engineer, and we were only interviewing people with 10+ years of development experience. We'd ask people to build a priority queue. Items with a higher priority need to be handled before those with a lower priority, but otherwise items should be handled in order.

Can you guess what the most common methodology people chose was?

Did you guess an XML document?

These are people with degrees in comp sci, some claiming 15 years of experience as a developer, trying to get a role at a top 10 bank in New York City.

Of course technical interviews shouldn't be the only test used for hiring, but they absolutely should be included. Maybe it's demeaning that you have to jump through these hoops. Or maybe you're bad at them. Or they're "beneath you" in some sort of way. But don't blame the interviewer, blame the hundreds of other people trying to get a job that they aren't qualified for.

Did you ever actual hire any of those people? Did you ever verify that they actually had the experience they claimed? Did you follow up with their references? Were they able to walk you through projects they worked, or discuss solutions implemented?

Every job gets applicants that aren't qualified. Only software engineering out of every single non-performance based (musicians, actors etc...) industry out there has white board interviews.

Actually, yeah, we did. The hiring manager got tired of waiting for us to find a good candidate, so he just picked one that he had screened and seemed best on paper.

It was an unmitigated disaster. Constantly had to double check his work and redirect him from doing things bad ways (like using mutable objects with changing hash codes as dictionary keys kind of bad).

Eventually I quit the job (for other reasons). On the last day he cornered me in the elevator and offered me $100/hr to do his work for him under the table so that he could claim it was his.

> Did you ever verify that they actually had the experience they claimed?

Employer would only verify employment dates and eligibility for re-hire.

> Did you follow up with their references?

Yeah, but when you ask someone for references they're not likely to give you people who wouldn't speak well of them.

> Were they able to walk you through projects they worked, or discuss solutions implemented?

Yeah. I can walk you through projects that I was involved in as a junior as if I had been the lead because I paid attention during meetings.

So you had one bad experience with one person who didn't do a whiteboard?

How many bad experiences have you had with someone who did? I've had enough that I've lost count.

>like using mutable objects with changing hash codes as dictionary keys kind of bad

I don't think a leet code question would necessarily have screened stuff like that out at all.

>Yeah, but when you ask someone for references they're not likely to give you people who wouldn't speak well of them.

Did you actually talk with these references about what it was like to work with him?

>On the last day he cornered me in the elevator and offered me $100/hr to do his work for him under the table so that he could claim it was his.

That's $200k a year. I find it pretty hard to believe that he was serious.

> So you had one bad experience with one person who didn't do a whiteboard?

It was a bad experience with someone who utterly failed a whiteboard.

> How many bad experiences have you had with someone who did? I've had enough that I've lost count.

> I don't think a leet code question would necessarily have screened stuff like that out at all.

I'm sure I have too, but I never advocated for only whiteboard interviewing. There should be a spread covering all sorts of aspects of their abilities.

> Did you actually talk with these references about what it was like to work with him?

Of course. I have a wide variety of coworkers with a wide variety of opinions of my skill-set. I'd select the ones that I think would resonate best with you. Barring that I have half a dozen friends that would tell you whatever I want them to. I fail to see how references are any sort of magic bullet.

> That's $200k a year. I find it pretty hard to believe that he was serious.

I was another senior engineer on the project, so I definitely could have covered the work. I had deeper experience, and given his quality I could have churned things out more quickly. I suspect he wasn't offering me $100 / hour at 40 hours per week. The job had a lot of paperwork and bureaucracy involved. I suspect if I was just doing the coding parts I could have covered it at about 10 hours per week, which is a lot more feasible.

Obviously I turned this down for ethical reasons.

>Of course. I have a wide variety of coworkers with a wide variety of opinions of my skill-set. I'd select the ones that I think would resonate best with you.

Could it be that you have people who will give you good references because you're a good developer?

>Barring that I have half a dozen friends that would tell you whatever I want them to.

So if I pull those friends up on linked in, they're developers too, and you'll have some plausible overlapping work history?

> I fail to see how references are any sort of magic bullet.

It's not a magic bullet. But faking 10 years of development work history and multiple decent quality references is a fairly high bar. It's not going to catch everyone but neither is whiteboarding. The goal shouldn't be to catch everyone.

Sometimes you make a bad hire. Despite every test you put someone through, you'll get false positives. The problem is that if you ratchet your test up to far to avoid false positives, you end up turning off good engineers, or failing good engineers.

I think the problem is that the company wasn't willing to just admit they made a mistake and fire the guy, not that he was hired in the first place. America (assuming you're in the US) has nearly unrestricted at will employment. Why are you so afraid of hiring one bad employee? If you can't identify bad employees after a few weeks of working with, you have zero chance identifying them before you hire them.

Maybe instead of spending months trying to find the perfect candidate, just do what literally every other industry does and hire experienced candidates based on reputation, resume, talking to them about the job and past projects, and fire them if it turns out they were completely lying to you.

Is building a priority queue a common task that senior engineers would be required to do if they got the job?

Literally came out of our work queue. Couldn't find a satisfactory off-the-shelf component for it, needed one built. Afterwards we liked it as a technical interview question.

I can almost guarantee that the person who implemented it as part of their job brushed up on priority queues before they built it.

I remember how to build one from a binary heap, but I wouldn't launch right into the code without reading a bit first.

It was me. I can't remember how I built it.

If I was doing it today I'd use some sort of balanced tree using the priority to navigate the nodes. Each node would have pointers to the head and tail of a singly linked list. Insert when the priority isn't in the tree is a simple tree insert with head and tail pointing to a new single-element linked list, insert when the priority is in there is adding it to the tail of the right node and moving the tail pointer, removing is finding the right-most node, taking the head and advancing the head pointer by one element. If the list is now empty then delete the node.

But none of it matters. I don't care if someone would build it the way I would. I would never expect that. I don't even want an optimal or semi-optimal answer. I'd have accepted a singly linked list with O(n) insertion time and O(1) pop time. Or a plain list where new items are added to the end and a pop is an O(n) seek through the list.

What I care about is whether the developer come up with any solution, describe the tradeoffs that they are making, why they are making them, and what research they would do if any to find a better solution. If i could have this conversation that we're having right here, right now with them then they'd probably pass my hiring bar.

A binary heap has some advantages over using a balanced tree that could have significant performance impacts (and vice versa). Particularly in a situation where you need to roll your own priority queue.

That's why I said it's likely the person who built it would done a bit of research. When hiring someone I care that they remember enough to realize that and are capable of doing the research, more than that they remember exactly how to implement some data structure.

>If I could have this conversation that we're having right here, right now with them then they'd probably pass my hiring bar.

I think that's a totally reasonable. My problem is that this isn't what people are complaining about when complaining about white board interviews.

99% of the time the interviewer is asking for the answer to a very specific problem that is highly biased towards new grads who would have just seen it on a test.

And even if they say you don't care about the optimal solution they will always hire the person who gets the optimal solution in 15 minutes b/c they memorized it versus the person takes 30 min to bang out something that kind of works.

Here's my approach:

I ask someone else on my team to come up with an interview problem, so I haven't seen it before hand. Then I work with the candidate on hashing out a solution.

Conceptually I know what a priority queue is and how it works but I haven't built one, though I've used many. How satisfied would you be if an interviewee implementated it in pseudo code?

Thrilled. Probably a strong hire. I don't expect anyone to know what one is off the top of their head, but if I explain the goal to you I expect you to figure out roughly how to accomplish it without using XPath.

Now someone is going to use “Implement a priority queue using XSLT/XPATH given this XML data” as an interview question for a new hire... filtering for people willing to take the job even after being asked to do that!

Most arguments I've seen claiming the incompetence of senior engineers are circular.

A: We need programming quizzes even for senior engineers, because many turn out of be incompetent.

B: How do you know they're incompetent?

A: They failed our programming quizzes!

The reality is that you're testing for stage fright, not programming skills. An audition is not a good criterion for choosing people who aren't stage performers.

https://news.ncsu.edu/2020/07/tech-job-interviews-anxiety/

Stage fright does not lead a senior level engineer to build a priority queue using XML.

Assume good faith: let’s presume he knows some candidates get stage fright and has ways to help mitigate it. Or that despite stage fright, such tests are still a good signal (e.g. the signal is so strong the false negatives are a worthwhile cost, or stage fright might be highly correlated with poor performance, or stage performance could be highly correlated with talent!)

> Assume good faith

That's an interesting defense of an interview process that specifically does not assume good faith of the candidates.

> has ways to help mitigate it

I'm not sure this understands the nature of true stage fright. There aren't any good ways to mitigate it.

“Assume good faith” is an hn guideline for comments, not interviews. https://news.ycombinator.com/newsguidelines.html

Re mitigation: already answered with previous “or” clause.

But "has ways to help mitigate" stage fright has nothing to do with assuming good faith. You'd have to assume magical powers.

It's like if someone has a fear of spiders, and you bring out spiders during an interview but claim "we have ways of mitigating this fear."

To me your thread feels like nitpicking.

I think that the idea is to optimise for preventing false positives (bad hires), at the cost of a higher rate of false negatives (good hires incorrectly weeded out). Interviews are imperfect: candidates can fail for a vast range of reasons that are completely unfair.

Also an applicant could train to avoid stage fright, just as they might train to learn algorithms if applying to Google. AFAIK many real actors have all the symptoms of stage fright, but they have learned to deal with it to be successful.

Disclaimer: I am not an interviewer.

It's not nitpicking. I want to draw attention to the fact that the so-called "false negatives" that everyone claims are acceptable casualties of the system are not just random false negatives. Audition-style coding interviews systematically discriminate against people who tend to experience extreme nervousness during auditions but otherwise perform normally on the job.

Note that this thread started with "Everyone loves to read and write about how developer interviewing is flawed, but no one wants to go out on a limb and make suggestions about how to improve it." Now you're saying applicants can train for this, applicants can train for that, but what happened to the original point about how to improve the process instead of making candidates take difficult steps to adapt to the flawed process?

I know I am being oppositional, but your style of argument comes across to me as deep diving on points where you can be correct, or changing the subject. I am trying to argue against your original thesis which I will paraphrase as “a quiz detecting incompetence is actually detecting stage fright” https://news.ycombinator.com/item?id=24758092

Anyone who thinks XML is a valid solution to a priority queue is incompetent (even if they were prompted by the recruiter as said in sibling comment). https://news.ycombinator.com/item?id=24758234

Stage fright is real, and it is unavoidable in an interview i.e. even if coding quizzes were removed then the problem still exists, so arguing just against quizzes is silly IMHO.

> everyone claims are acceptable casualties of the system

I would say instead that casualties are unavoidable - interviews must be imperfect because time is limited (regardless of how much we may try to improve interviews.)

> systematically discriminate against people who tend to experience extreme nervousness during auditions but otherwise perform normally on the job.

Interviews are by definition systematically discriminatory: one is trying to select one person. The data is dirty, and if you make interviews more inclusive on one dimension you are discriminating against others on that dimension. They must be systematic as per anti-discrimination regulations, or else you will get sued to your cost.

How to improve interviews to reduce false negatives is hard, but I think you are oversimplifying it down to “quizzes are bad”, which is at odds with many smart professionals who say they are good for detecting incompetent developers. You have not suggested any improvement that detects incompetence.

> Note that this thread started with "Everyone loves to read and write about how developer interviewing is flawed, but no one wants to go out on a limb and make suggestions about how to improve it."

I can also cherry pick a quote further up-thread: “To many people, the coding interviews is a chance to break the traditional mold and land a job that would have been out of reach otherwise.”

> your style of argument comes across to me as deep diving on points where you can be correct, or changing the subject.

There's only so much that can be said in a HN comment. I'm trying to avoid writing a whole treatise.

> Stage fright is real, and it is unavoidable in an interview i.e. even if coding quizzes were removed then the problem still exists, so arguing just against quizzes is silly IMHO.

The conclusion doesn't follow. The problem still exists, yes, but I think everyone would acknowledge that casual chatting is easier than coding quizzes? Thus, if you tend to experience performance anxiety, then tasks that are more difficult to perform are more strongly negatively affected by performance anxiety. Compare with other issues that affect performance, e.g., drunkenness. Being drunk will affect your speech, but it severely affects your ability to more complex tasks such as driving a car.

> Interviews are by definition systematically discriminatory: one is trying to select one person.

That's not what systematic discrimination means. It means discriminating against a certain class of people who all share the same characteristic. Some examples are gender, race, and age, but that's not an exhaustive list.

> You have not suggested any improvement that detects incompetence.

I fundamentally disagree that this should be the main purpose and focus of hiring and interviews. I think rampant, exaggerated paranoia is one of the reasons that tech hiring is so messed up. The irrational fear of the "bad hire". Few other industries are so afraid of this. The reality is that it's impossible to avoid bad hires, and trying to be perfect in this respect will distort the whole process. Professional sports spend vastly more time and money on talent evaluation and acquisition than tech, but still they make "bad hires" all the time. Wasted #1 draft picks. Multi-million-dollar contracts for busts. It's just expected, a cost of doing business. They shrug it off and move on, and keep making mistakes too, because perfection is unattainable.

"How can we drop coding tests... while still being ultra-paranoid?" is not a question I can answer. My answer is to not be so paranoid, and just accept the inevitable mistakes, a more relaxed process which also allows you to find the "diamonds in the rough".

> I can also cherry pick a quote further up-thread: “To many people, the coding interviews is a chance to break the traditional mold and land a job that would have been out of reach otherwise.”

I don't know why it's cherry picking to restate the original context into which I first replied in this thread. In any case, I already replied to that quote too.

I am really struggling to follow your threads of thought.

I am going to throw in a patio11 spanner instead: ‘In a way, every scaling startup is an experiment in empirical microeconomics research on “What parts of the typical corporate form are necessary and which are pageantry which we only keep around due to anchoring, the sunk cost fallacy, and tradition?” Every time a startup bites the bullet and hires a VP of Sales, a lifecycle email copywriter, a retirements benefits administrator, or a cook, count that as a published result saying “Yep, we found this to be necessary.”’. https://www.kalzumeus.com/2020/10/09/four-years-at-stripe/

Failing an interview is embarrassing and leads to stage fright. I've seen no evidence that stage fright is a significant factor ruling out good candidates. If you are fluent at coding then a coding interview is just like any other interview, if that scares you then a normal interview would hurt you just as much.

If you aren't fluent at coding then why are you applying to a coding job? Would you apply to an English writing job without being fluent in English? If you just have a few years of English from school doing an interview in English would be extremely stressful and likely lead to stage fright. That doesn't mean that making interviews in English is a problem, the problem is that the person isn't fluent in English.

I remember that English fluency was a big barrier when I originally applied for jobs. Just speaking took a lot of mental power and the interviews were very stressful, but now that I'm fluent it no longer takes any effort. I went through the same stages in programming as well. I did a technical interview with a few months of coding experience and it was very stressful, now I don't even have to think.

> I've seen no evidence that stage fright is a significant factor ruling out good candidates.

I'm just going to link again to a scientific study on the subject.

https://news.ncsu.edu/2020/07/tech-job-interviews-anxiety/

When you talk to someone you waste maybe 50% of your time/energy talking about what you do, meaning you effectively have 20 minutes instead of 40. Doubling the time you have available will make more people pass, yes, that isn't evidence of anxiety being a major factor.

Edit: Also looking at the data people spent more time on the problem in the private setting than the public. Their stats could therefore be as simple as the students not caring about the result and therefore they quit earlier in the more uncomfortable environment instead of doing it properly and checking their solution. This wouldn't be a thing in real interviews since there a lot is at stake so people wouldn't quit early, at least in my experience not a single candidate I've interviewed quit early.

Edit Edit: For example, their very impressive "All women in private completed it, all women in public failed" stat can also be described as "Women in private spent on average 16 minutes on the problem, women in public spent on average 7 minutes on the problem". Maybe if they had more at stake and therefore more stress they would have spent the entire 30 minutes and therefore done just as well?

Anyway, my point is that just because the abstract says they have clear evidence that stress is hurting performance these studies are still mostly garbage. Don't take it as proof just because there is a study.

> Don't take it as proof just because there is a study.

I don't. I take my lived experience as proof that this is real.

You seem to be in denial of a common psychological experience.

Common sense is often wrong. I have very bad stage fright, I have went mute in front of class several times. I still don't believe it is a significant factor filtering out good candidates. It might unfairly filter out some mediocre ones though.

Lots and lots of people have severe, physical, visceral responses to anxiety that can often be not only distracting but downright awful, feel-like-you’re-dying kind of feelings. This kind of anxiety response is entirely independent from day-to-day ability.

Being asked to perform a complex task while someone else is both watching and judging you is way different from just talking through a non-technical interview. It’s an entirely different experience. Speaking a foreign language is hard, especially under pressure, but it’s absolutely nothing like trying to solve a brain teaser while the clock is ticking.

I don't think stage fright explains an XML document as a solution to a priority queue.

I'm betting it was something like this though: https://www.chegg.com/homework-help/questions-and-answers/pr...

You would lose your bet! See OP’s comment: https://news.ycombinator.com/item?id=24758234

> Most arguments I've seen claiming the incompetence of senior engineers are circular.

Exactly!

If someone has been implementing and delivering products for years/decades and they "fail" a whiteboard puzzle, which is more likely?

A: The whiteboard puzzle doesn't actually measure anything correlated to delivering products.

B: They can't actually develop anything, despite having repeatedly done so.

I want to hire the people who can develop and deliver products, not the whiteboard puzzle specialists because I've never been at a company where solving whiteboard puzzles is something we do as part of the business.

> Can you guess what the most common methodology people chose was?

> Did you guess an XML document?

If that is your most common experience with asking that question, maybe it is time you consider whether you are communicating what you want properly to your candidates.

The real WTF was probably the hiring agency that the hiring manager insisted we go through. I'm pretty sure they were coaching their candidates, but we couldn't break away from that agency for some reason (cough kickbacks cough). The answers were suspiciously similar.

But I don't know how much better I could have described what I wanted:

"I want a class for holding a queue of items in memory. The queue will only need to hold a few thousand items, and you don't need to worry about persisting it in case of a power failure or anything. The only wrinkle is that when an item is added to a queue it has a priority. Higher priority items need to come out of the queue before lower priority items, but items with the same priority should come out in the order they were inserted."

I don't get it either. How did they suggest using an XML document to act as a priority queue? I actually would have found that highly amusing!

My naive contribution: A linked list with pointers to the tails of various priorities. The grabber just points to the head and pops things off the top as it goes.

> How did they suggest using an XML document to act as a priority queue? I actually would have found that highly amusing!

I tried. It got tiring. Sometimes people would loop through all possible priorities plugging them into an XPath query and pop the first element of the highest priority that matched. Some would do two XPath queries, one across all nodes to get the max priority and a second to query the first element (ignoring the lack of a need to run the query a second time at all). Some would insist that XPath has some function that would let you select a node with an attribute that has the maximum numeric value.

I'd have been fine with your solution.

As someone who has worked at a few of the "top 10 banks in NYC" for most of my career (and still am...albeit trying to desperately get out), I have to say that the quality of much of the engineering talent at these firms, and the typical candidates that would apply there, are pretty low. Yes, I realize that the above statement can be construed as spitting on my own face in a way. So I am not surprised.

There may be a few small niches that attract good quality talent, but otherwise I don't know why anyone would opt to work as a technologist at a bank as opposed to say, a bonafide real tech company (all the banks are eager to say they are "tech companies" nowadays), or even a hedge fund.

Implementing a queue in XML why on earth would you do that

Also lots of questions emerge when one is trying to be constructive.

Hiring is meant to have fidelity. Fidelity to what? To the extent there are company values, nobody explicitly “tests” for them in hiring. Certainly when I worked at US Engineering, which had an explicit values statement, I don’t recall being interviewed for how I “exhibit integrity in everything we do” or “ensure a safe working environment.” I doubt Amazon is like “so let’s talk customer obsession. when is the last time that you stalked a customer and got obsessed with making their life easy?” (I mean you can question the value as well, but to the extent that Amazon tells you its core values, are they a part of hiring?)

How much fidelity are we talking? Use the “nines” metaphor. Do you want five nines, one bad hire in a hundred thousand? Probably you need a month-long “interview” process then, you’re basically at the question of “let us contract some work out to you for a month and if we like you we will hire you.” But, consider: are more nines even better? If we have BS metrics that do not properly reflect our interests then we only find out about them by hiring people we would not have rationally hired. Maybe you only want one nine, or more radically even half a nine (that is 68%, if you have never heard of it), of fidelity. What if you baked that fidelity in? What if a unilateral consensus to not hire still generated a 10% chance of hiring and a unilateral consensus to hire still generated only a 90% chance of hiring, so that interviewers had to know getting into this that absolute sureness was not a goal?

That brings up an even better question, which is: can you have a good hiring process without a good firing process? How do you give yourself the one-nine process and then make sure that people who were retroactively not a good fit get a decent severance but are done away with?

I have mentioned elsewhere that Bayes’s theorem suggests that evidence should be measured more or less in decibels; this is covered explicitly in Jaynes’ Probability Theory ch. 4. But consider [1] where researchers found that they did not see substantially more correlation between different interviewers evaluating the same candidate for 20 minutes, and other interviewers watching videos of those interviews over only the first 20 seconds (the initial greetings of the video). So can we actually trust interviewers to give us, say, +10dB of evidence that this person is a good fit? Or if we get 5 interviewers do we get a range from “meh, pass” to “hire immediately for twice what they’re asking” as much as if we had done job interview “speed dating”?

Constructive advice is hard. One wants to instead force the hiring committee to watch talk after talk by Alan Kay until the roughly-every-other-talk discourse Alan gives about how “we live in a pink world and then we have a deviant thought but then we kersplat it until one day in the shower we have a kerpow that launches us into a new blue plane of existence—but that idea like most is more likely to be mediocre or terrible, so we have to then come back to it with something like science so that we can discard terrible ideas” becomes somehow ingrained in the hiring committee and they start trading their “kerpows” and evaluating them and coming to a better process than this “pink world” we see with our rose-colored glasses.

Because without that sort of systematic re-invention, aren’t we just guessing?

[1] https://www.researchgate.net/publication/313878823_The_impor... . Side note: in tracking this study back down I got to see a lot of interesting takes on it but the most common consensus is that “we make our first impressions in that first 20s and then do not budge from them” which I do not think is warranted given the data. That is, while a significant correlation coefficient is observed and it is comparable to the correlation between different long-form interviewers, at no point is that correlation coefficient, like, 0.9 or 0.99 or anything like that, suppressing interpretations that these first 20 seconds determine the interview. For that matter if that was your goal you would want as a control any other 20 seconds in the interview—you would want to prove that it was the first 20 seconds that determined the overall interview impression, not that people were judging based on some je-ne-sais-quoi demeanor that is visible throughout the interview.

> but no one wants to go out on a limb and make suggestions about how to improve it.

That's not really true, plenty of suggestions on how to improve it. Many of those based on experience doing it for the long haul.

Personally I always advocate for a technical discussion of their experience. Read the resume in detail. Talk about it. Pick some past project to go deep. Also let them pick a favorite past project to go deep in detail. It means the interviewer needs enough technical depth to follow along. This works. I've never said "yes" to a hire and later thought that was a mistake, in ~25 years of doing interviews.

Just the other day here someone was saying they received over 50 resumes for a role so they had to interview over 50 people. No. Don't do that. You can't go deep, so it just leads to meaningless puzzles. Read the resumes, pick the top 5 or so, interview them personally. Hire the best of those. Done, move on with getting work done.

> This feels good if you’ve already made it or you grew up with the right connections, but it’s far from ideal you’re a promising developer who doesn’t yet have the right credentials on your resume to unlock the job.

I've never understood why these two different groups, long experienced developers and unproven newcomers, are competing for the same jobs. That's the insanity of the system.

I suspect the answer is that many people believe (mistakenly IMO) that experience doesn't really matter, and "raw talent" overrides everything else.

Part of it is the conveyor belt of new frameworks and technologies, and binary litmus tests from first-line recruiters.

Someone who could very well have invented javascript yet doesnt know ExpressReactVue[*]JS or framework du jour cannot get past first-line recruiters who are searching on Linked In keywords. Thus, both groups are in the same bucket.

I wouldnt be surprised if some recruiters turn down python 3.6 candidates because they dont have python 3.7.

My prediction: Somebody with a realistic chance of inventing whatever the next javascript will be will do fine. Recruiters who screen them out are hurting their company not that candidate.

I agree, i was exaggerating a bit but there is a spectrum between, say, Brendan Eich (on one extreme) and an average code camp graduate (on the other extreme). Think about those in the 75 to 50% region.

I don't know, almost every day I regret the invention of JavaScript...

They are and they aren't competing.

The problem is that "long experienced developers" are often worse than "unproven newcomers". They aren't any better and instead of being a "lob of clay", they are "molded steel" and all the bad habits will never go away.

True senior engineers from reputable companies are of course different than newcomers and they are interviewed quite differently at big companies. But the problem is that what candidates understand as "senior" and what FANNG companies understand as "senior", often have little to do with each other. And the reason is simply that most people who apply for a senior role, wouldn't even pass the entry level interview at a FANNG company. It's just the sad reality. And this does not mean the entry level interview is wrong. It just means that these "senior" candidates were instead just junior developers who never developed beyond that from a skill perspective (except in their own heads).

And at FANNG companies, to even be considered for a senior position interview, you MUST have the credentials on your CV to prove it. However, a lot of candidates will never be interviewed for a senior position, even if their CV is "ten pages" long, because its apparent that this experience will be unlikely to have prepared you for a senior position at a FANNG company.

Being a senior engineer at a FANNG company is demanding and difficult on many more levels than just raw coding. You could be the best coder in the world, but that won't make you a senior engineer. It will make you a top mid-level engineer and you will never get beyond that without acquiring non-technical skills. Most people simply won't be able to do this job, no matter how long they stay in the industry. And I can assure you that there is little similarity in how interviews are conducted for these positions vs. college grads.

A senior engineer is essentially a developer who wants to still code, while also being a manager and a leader.

I would add that many of the "senior" engineers in SV received that title because they joined a startup 6-months before the company secured major funding and massively scaled. Seniority/familiarity with the startup's stack != senior.

- "but it’s hard to actually step into the hiring manager position and find the best candidate without disappointing some people along the way"

Hear me out: the quality of (hiring) managers in tech is ridiculously bad for the money they make. Little quality, poor ideas, and little personality. Mostly, they are of the nerdy type, like the vast majority of people working in tech, so by inclination and culture are not leaders, but followers or the aloof type, and they much prefer to work on their own than in teams. It pays off to go with the flow in corporate.

Source: I had managers (including Directors and VPs) at some of the tech companies everybody talks about that were they to take any decision in which life and livelihood of people are at stake, it would be one of those dreams after which you wake up drenched in sweat and you make the sign of the cross you are just working in a tech company.

I am trying to understand what your saying - that managers would not make decisions.

Let me clarify. Most managers I have seen in tech are sub-par. So, it might be that it is not that the hiring problem is a process problem, or a market problem, but a manager-quality problem. Of course, I can present only anecdotes from my own experience; but I can confidently say that, before getting into tech, I was expecting the quality of managers and decision-makers to be much higher, especially considering the money they make. Instead, I have noticed the usual skewed distribution: a bunch of brilliant decision-makers that move the company in the hopefully right direction, and a ton of minor managerial figures who are surprisingly terrible at being managers, when not total frauds.

I hope it is clearer now.

> Consensus seems to lean toward this being satire.

I think "How to interview engineers" is a set of actual Slava Akhmechet's recommendations about hiring, sprincled with occasional satire about hiring games.

there's plenty of suggestions and there are companies / teams that adapt those suggestions. Just big companies and startups, and clueless management refuse to. I can't control how my company hires people but I can control how I interview internal candidates.

Reply on news.ycombinator.com