The study participants were split into two groups. One group solved the problem alone, in silence. The other group was instructed to narrate their thought process out loud to an interviewer who stood over their shoulder (literally, see the photo on page 3) while they solved it.

The flaw in this study is that the two groups weren't really assigned the same task. Solving a problem isn't the same as verbally narrating your solution to a problem. The authors attributed the differences not to the extra work narration work assigned to the second group, but to anxiety levels.

The participants even explained that their difficulty came from having to talk while solving:

> Participants also had difficulty with performing tasks that involved multiple simultaneous actions. Participants felt stressed by having to “talk while trying to write” (P44), “talking while writing” (P25), and “think and talk and do code at the same time” (P39). P41 found it difficult to “constantly speak during solving” and “lost breath at a few places during the task”.

There are other concerns with the study format such as many of a significant number of participants simply giving up well before the clock ran out, in both the private and public interview groups. They were given 30 minutes to solve 3 problems, but some of the participants (including in the private group) were giving up around the 10 minute mark without solving anything at all. This suggests a very high variance of the underlying abilities of their candidates, which necessitates a much larger sample size to draw conclusions.

The last interview sequence I needed to do they put me in front of an online IDE and said "go code." They also said I could use my OWN IDE if I had it set up. One even said "you can finish it later (post-interview) if you want."

The candidates giving up: Some nontrivial percentage of CS students are just ... not capable developers. That's why we use programming tests to begin with.

Programming tests may be the worst possible way to assess candidates, but they also seem to be the only way to assess candidates that doesn't involve paying them for a trial period, which really only works for companies large enough to be able to waste a lot of money. "Democ­ra­cy is the worst form of gov­ern­ment, except for all the oth­ers."

I can't afford to hire developers that can't effectively communicate complex ideas to other developers - something they're often required to do on-the-fly.

It's like asking someone to give an extemporaneous talk on some subject, while translating each sentence into another language as they go. Even native bilingual speakers would have quite some trouble with this. They can generate content, they can speak fluently, and they can translate on the fly, but having to do all three "live" involves too much context switching. Maybe doable for simple or rehearsed topics, but most coding interview questions are non-trivial.

I don't think this is universally true, and to some extent I think it's a practiced skill.

I used to really struggle to problem-solve and communicate at the same time, but then did two years of improv comedy outside of work and suddenly don't have that issue anymore. I think part of it for me was shortening the gap between my thoughts and my communication (to zero) which stops the need to context switch, but introduces a need to think in a way which is clear and structured (because you are going to be verbalising the voice in your brain, rather than thinking and then translating those thoughts to words as a secondary step).

But is it a skill that's even necessary and therefore developed while working as a software engineer?

In almost all cases that i can think of:

  - real time communication might be important for discussing things before and after development, things such as architecture, concerns to pay attention to, or even choices made during development
  - real time communication almost never plays a part during the actual development, unless doing pair programming live from 0 or even mob programming (absolutely unheard of in my current company)
  - most of the time, what happens instead is dropping a detailed question in Slack and the other person responding to it when they have a minute, only escalating to calls if that's not helpful, which almost always only gives rough outlines of things to try next, not changesets to the code
  - actually, most of the communication regarding code happens in merge requests asynchronously, which is better than synchronous communication which wouldn't be explicitly recorded and all of the arguments/outcomes of which would disappear

You can only feel confident in your ability to narrate these solutions when you know what they are or where to start, e.g. after a few hundreds of hours of grinding LeetCode, but at that point it's essentially following a flowchart of algorithms and in my eyes is basically "pretending" to be clever, even if there is something to be said about the ability to memorize solutions to problems (or even groups of solutions) and apply the correct one.

Perhaps it's a bit better in my eyes when you'll be applying these algorithms daily in your work, but so far it's about 90% CRUD development, struggling with the specifics of technologies and doing requirements engineering with clients who don't always know what they want or whether that what they want is technically feasible.

Disclaimer: there are probably cultural aspects to it as well, like how here in North/East Europe we don't really do much small talk with strangers. Or maybe it's just corporate culture, or the people working within the company happening to be more introverted and thus the idea of narrating things real time simply being uncomfortable to them.

It's also useful to 'work a problem' with people sometimes which requires this sort of live communication, however the extent to which teams do this will vary by team. In my experience this is more common in teams that are physically located together in the same room.

Also it's not inherently clear to me that "not used in the job" means it's also bad from an assessment perspective - take defensive driving certifications for example, which require drivers to 'verbalise' what they are noticing, doing, and their decisions while they drive. Do you verbalise when you are driving in reality? No - but it is an established technique for assessment and for learning.

But each to their own. Different strokes for different folks, clearly this works for some people and not others.

I code as part of the process of thinking things through. Seeing how bits will fit together. It's like how an author writes to organize their thoughts, instead of the other way around. How ridiculous would it be to interview an author based on their ability to write a short article on a whiteboard in real-time, while talking through their writing process!

I myself found it asinine when I was asked to talk while writing code... I just cannot focus in the problem at hand while coding. Maybe I am stupid or low IQ, but I need to concentrate in the problem and put 100% of my attention on it.

From interviewing several hundred people so far, I've seen that most of them breathe a sigh of relief once I told them that rule (along with the rule of being able to search for whatever they want as part of the challenge).

The image of a developer constantly speaking while coding on their day to day brings me a chcukle.

So at work, every time your programmers are assigned a JIRA ticket they speak in loud voices every line of code they are writing/deleting/editing???

Sounds like a horrible way of managing a team.

>>I can't afford to hire developers that can't effectively communicate complex ideas to other developers - something they're often required to do on-the-fly.

This goes beyond I imagined. Once the JIRA is assigned they literally scream at each other what they are thinking?

I have had situations where people complain about noisy clicky keyboards, let alone people loudly repeating their ideas on other peoples faces.

How does all this work for your team?

If you're on the team assigned to develop the UI for the turbine monitoring of a hydroelectric power generating station, at some point you're going to need to be in a room with a bunch of other developers and engineers, and start working through some technical issues or begin planning how you're going to approach the problem. That will involve working through code while getting input, which will obviously involve speaking to the other humans in the room.

I know there's a tendency on HN to think that all developers are just like you, but a lot of developers aren't working on simple nonsense like the next to-do app or note-taking tool. Many developers are working on complex, real-time systems that require the coordination of dozens of teams of specialists over years. If you can't manage to communicate your approach to solving a particular problem to a room full of engineers and other developers, you're just not going to do well in that kind of environment.

That's not what is being discussed here. As a matter of fact anything as complicated as what you describe here, can't be explained in one cycle. It will require several takes to arrive at something good. And it definitely doesn't involve repeating their deepest thoughts at their colleagues faces.

If anything your interview method feels more like an audition for an acting role than problem solving.

Where one person needs to describe clearly what code needs to be written so the other can type it. Actually pair programming requires more effort in that regard, since describing what you're doing is easier than describing exactly how to write it.

I don't do 100% pair programming gigs, but I know they exist, and I've used pair programming in short bursts as a tool for knowledge transfer.

Having to explain something non-trivial happens. But literally always there are hours between solution and explaining it. In pretty much any real situation, I have quite a lot of time to think about how to explain.

Let him go after only a couple of months--but that was several months of pay that produced literally no positive results. And I was running a small development house at that point; dumping two months of salary down the drain was not a good thing for the bottom line.

So yeah, totally agree. Paying everyone who "seems good on paper but who just can't pass the programming test" really doesn't work, despite wishful thinking to the contrary.

Some schools have great signal to noise ratio, and you can be pretty confident when hiring. It's not just reputation. Some school (Poly in Montreal is a good example - but other do it as well) requires all student to complete a paid internship in their field of study to graduate. So you know if you hire someone from there that they are able to code professionally.

MIT moreso, no one is skating under the radar at MIT

Funny you should say that.

A past CEO I worked with was a CS grad from MIT. He would laugh about the fact that "he could code, but no one would want to use the code he wrote."

I've also heard another anecdote about an MIT grad who had excellent grades but who somehow couldn't get any work done on a relatively straightforward project.

So yeah, even MIT graduates CS students who aren't the best at code. CS being "Computer Science" means they need to understand the theory, but even an MIT grad isn't guaranteed to be capable and talented in writing code in practice.

If there were a "software engineering" major (or certification?) which, among other things, required the student to write nontrivial code, and it was judged by experts, including using subjective design criteria, then maybe we could start using that degree or certification to prove that, at least at the time of the tests, that person could code. But the devil is in the details even then...

Paying someone else the equivalent of a (low) full-time salary to take your courses for you? Probably.

> Standford

If you can't even spell it... I don't think you should assume anything about Stanford...

My comment wasn't so much assumptions as it was my reinforced opinion over the last decade talking to students and faculty

I'd probably want to see something more open ended, like a system arch/design if possible

Because everyone keeps paying so much tuition. Why does _everyone_ can afford to pay so much is another question worth exploring.

That idea definitely makes sense to me. And I think some devs do definitely underperform in interviews.

Though I'm not sure if there's great alternatives. As an interviewer I feel that seeing someone work through a problem and debug issues gives useful information. I don't know if there's a better, less anxiety-producing way of testing those things.

I do think take homes can be really useful, but those have their own problems. Maybe leaving someone alone onsite to complete the problem would be an option. But I think leaving the discussion to the end would give less info about the candidate's communication skills.

This unwillingness to experiment with the existing interview format, the intransigence to consider any alternatives, is simply maddening.

I think this kind of context change would be tremendously empowering for candidates such as myself who get very anxious about situations in which they feel people are "testing" them but who actually love working with people. It would also be nice as a way to see what people are like to work with, from both the perspectives of the candidates and the interviewers.

PvE interviews instead of PvP interviews.

(disclaimer: Am male but still cannot talk and hack at the same time)

That's an extremely broad assumption

This is why I built myself a tool to practice talking and narrating my thoughts! https://enumerable.co

The real flaw is that the title doesn't follow from the research. "Tech sector job interviews assess anxiety, not software skills." That's saying that you're really measuring level of anxiety, not skill. So skill is irrelevant and you're just measuring how anxious people are.

But the study didn't show that at all. It just showed that on average, people perform better when they're not anxious. Not exactly a surprising result!

Of course people are going to be more anxious in an interview. But if it affects everyone equally who cares? Just make your questions easier.

Then the question is whether or not the anxiety will become a problem in the workplace. I can see arguments for both sides.

i think it’s reasonable to think that this study is relevant and that there is truth in it.

there is also the issue that every interviewer i encountered assumes lying and incompetence and will conduct the interview in such a way that the result is what they want to see - the candidate failing to write the code within a few minutes. they are not capable of letting a candidate do the interview without biasing the interview and results.

this also comes from the automatic assumption that because they work in a FAANG they are a fucking genius and are the only ones who can write software. i can see this happening as they are so brainwashed and lost all touch with reality and how the rest of the industry works.

meanwhile there are some marketing execs at that FAANG with a compensation package far above what they will ever get paid.

My reaction is to plan my exit from the industry whenever this job comes to an end. I'll end up going back to school in my thirties, despite being qualified, because of self-imposed constraints by this industry that have little if anything to do with the tasks I'll be given or planning day to day.

> A few weeks of drilling of common data structures and algorithms would put you at parity with college grads.

I don't know where one gets this kind of idea. I also stated fairly clearly that I have no trouble negotiating algorithms and data structures, the problem is when they're timeboxed and involve an interviewers participation.

I think my main objection is to even doing these kinds of interviews. When, in the world, would one need to write out binary search and would have only 30 minutes to do so? Knowing the properties of different algorithms and data structures is important, imo, but implementing them in a timeboxed manner with abstract problems seems like an odd activity to demonstrate qualification.

> Could it be you just don’t like the industry and project that onto some kind of academic bias or something?

Academic Bias may play less of a role than my perception makes it out to be, but I'd at least say it's significant in this industry. The way I think it gets in is subtle, catering questions and problems that one might find in an academic setting is one. My company also heavily hires interns, which again facilitates an academic bias in hiring, but there is no program for people who don't come from a prestigious university. The lingo used usually points to an academic background as well; I've learned "top talent" usually refers to prestigious companies (that primarily hire from academia) or prestigious universities.

I started getting back into electronics in the last 5 years, and have been really enjoying it. I think EE is maybe one of the hardest engineering fields, but can also be the most rewarding I think when you do something cool.

It's also wide ranging from RF to Electrical Grid to VLSI.

So good luck. I wish you well.

If interviewing is your only worry, just get a single undergrad textbook on DS/algo. Interviews do not by any stretch cover the full academic breadth of a cs degree.

An example of an extremely common question: “Write a function to check if a binary tree is a binary search tree.”

Yes you can memorize an answer here, and the implementation of a binary tree - I think most people just do that. Knowing the inns and outs of a binary tree is probably useful if you're writing a database, or a compression format. If they're hiring someone with the capability to write a database, or compression format, this question makes plenty of sense. It also makes sense if your criteria for hiring is "did they study and understand an algorithms course?". It doesn't make much sense if they're looking for someone who can do the actual job, in my opinion.

FAANG (& similar) have more applicants who can do the job than they have positions, so instead of checking for that and calling it a day, they filter for some combination of IQ and how bad you want it—willing to do a ton of otherwise-low-value prep work & practice, and to go through the painful interview process itself, likely several times at different companies, even for successful candidates.

The reputation of their interviews also means they likely don't get a ton of candidates who can't do the job. So they could likely just start randomly selecting from their candidate pool and do damn near as well as they do with all the interview effort—except as soon as that become known, they wouldn't be able to do that anymore. Plus they'd lose the hazing factor, which likely helps build company in-group identity. Having a lot of your employees feel like they only have their job because the finally got "lucky" in an interview may also help with retention, especially when everyone else who pays as much interviews in similar ways.

In a sense, being a huge, unpleasant waste of time is the whole point of their interview processes.

If you are talking about a self-balancing binary search tree, then, yeah, most people will have to memorize the implementation, as it would take much more than an hour to implement correctly. But if you are talking about plan binary trees, most good engineers will be able to write a simple enough implementation for the interview in a couple of minutes. And it won't be from memory, it will come from _understanding_ of how the binary tree is structured. The beauty here is that there is no need to memorize the implementation, as it is much easier to remember the definition of a tree and then write an implementation based on that.

What precisely makes you're more expert at the OP's experience then the OP?

The people you are competing with study leet code for 3 months and get really good at solving coding puzzles within 45 minutes. Study the basic data structures (nothing fancy needed beyond binary trees) and solve leet code an hour a day for 3 months. That's all you need to do.

You can keep competing with the B and C players if you want but don't give that advice to others.

Can't tell you how many companies I interviewed with that simply take their entire process from others. We interview like X, we group teams/squads like Y, we do our agile process like Z. I don't want to work for your wannabe something else organization, get a clue.

This advice worked for me and several of my long term colleagues across decades of career experience. We’re all introverts so this is a big deal for us.

I suspect you are giving up too easily.

Modern whiteboard interviews are not decades old. I never had any issue until the last 5 years or so. Tech interviews are testing for presentation skills and brainstorming skills, and placing a lot of weight on those alone. If that is what the job is like then I don't want it.

If your idea of best practices is copying (as best you can) someone else then I'm not a good fit for your company. In my view, its your loss and not mine - you missed an opportunity because you are not creative enough to see any other workable process.

I passed the last crap whiteboard interview I went to, even the question that no one else had gotten right previously (so they say). Didn't get the job, over-qualified - they wanted someone cheaper really. It is not about giving up too soon, its about doing something I dislike, and that has nothing to do with the day-to-day work, over-and-over.

That's why I still encourage people to pursue a Bachelors degree over bootcamp if they have minimal programming experience prior to going to school. If I'd taken only the "intro to ds" and only "intro to algos" courses to get my degree I would've been poorly equipped to start my first job, since that was the first time I'd seen those concepts.

I feel like I have PTSD from Google and Amazon interviews early in my career.

If you're interviewing someone like that, try to give them a little breathing space, and maybe even tell them that you are noticing the nervousness and that it is ok. If you're being interviewed, I think it is ok to say you are a little bit nervous, take a few deep breaths to calm yourself down, etc.

1) you don't have to know everything, only the topics they happen to ask. You are rolling the dice, but part of the time you'll be lucky. Besides, after reviewing for a few months (also did 4 yr degree in CS) I felt really strong in the algo topics. That said, I started half of my recent Google interviews thinking "how the fuck do I solve this? is this where I fail?"

2) Aside from the topics, you can absolutely drill the process. Drill a basic flow like understand/clarify the question, do examples, mention a brute-force, etc. when you do LC problems.

Good interviewers want you to pass, and aren't just giving you a test of arbitrary programming trivia.

Lip service is certainly paid to 'everyone has to look things up', and doing a quick search won't necessarily count against you, but, IME, the hesitation and doubt that caused you to look things up will. With so little material with which to evaluate a candidate, absolutely everything that doesn't impress them is going to count against you.

This is certainly Google’s philosophy, but our industry doesn’t think with one mind on this.

And as for having so little material - to me this is a sign of a badly designed interview. Almost everyone is weak in one area or another. If your interview only assesses candidates in one way (eg via a coding challenge, or based on a single whiteboard problem) then you are making a decision with insufficient signal. Multifaceted interviews are good interviews.

Plenty of otherwise strong candidates are weak in at least one section of any assessment. And plenty of bad hires will still, for example, know trivia about data structures even though they don’t actually know how to program. Making a hiring decision based on a single metric leaves way too much to chance.

(Source: I’ve done over 400 technical interviews)

> "I'd Google the exact algorithm for X"

This is a fail in the interviewer's book. Read: "Could not produce an algorithm with less than O(n)" or "lacks familiarity with fundamental data structures"

1. HackerRank (or similar) challenges are pretty close to what you'd find in a lot of technical interviews.

2. Searching online for "<technology> interview questions" for a few of the technologies that you're likely going to be asked about. Make sure you have good answers for the questions that pop up a lot. This helps a lot with remembering Stuff You Should Know that kind of slipped your mind (ie., angular digest cycle) because you maybe haven't seen it in a bit.

3. Write up a summary of your previous accomplishments and be sure you can call them out on the spot.

A lot of what the interviewer is looking for is confidence. And preparation begets confidence.

If you drill enough of the Coding questions, they all start to run into similar buckets, and the way you approach them improves too. Buy a whiteboard off amazon, solve them legit out loud explaining what you're doing to yourself. You will get better.

The other stuff is great advice too, always try to have a summary (in your mind or on paper) of recent projects etc.

And of course.. Doing interviews helps to :D

Interviewers should be looking for competence, not confidence.

It's not easy either. If I mess up once while giving advice on a place where the candidate is stuck, I can really confuse the candidate. Plus the time cost of reviewing a person's resume to determine what questions are appropriate for them. Lastly, I can't be expected to know all the tech on someone's resume at a level that I can gauge their capabilities, I use other means to determine if what a COBOL person is telling me is accurate.

So you have to kind of plan that interviewers take shortcuts (like judging confidence) and take advantage of that fact. If someone asks what are some benefits or drawbacks to a tech stack you use, have at the ready a good story about a shitty/hilarious/intersting experience you had while developing it. The experience doesn't need to be a 1-to-1 mapping either, it's a-okay to kind of nudge a question towards an answer you prepared.

This is better advice than you're really appreciating. If you feel like you are doing this, but still am having trouble, it's likely that you need work in some other non-obvious aspect of interviewing. I highly suggest finding a coach or someone who can take you through mock interviews and help you find out exactly what you can do to improve your chances!

LC problems are not always well written and a lot of times you just have to hope someone took the time to write out a good solution. A lot of times they just paste their code and expect you to get it.

For me personally, my brain goes completely blank at the problem statement, pretty much in the dark without a flashlight, and I have to work everything out by hand and hope that my code actually ends up being correct and reasonable. It's scary but I've ended up doing well.

I made it to the onsite the second time and failed that, but it mattered less since the money, while still significant, was no longer life-changing.

You've probably heard it before, but.... yeah. Practice. All the failures you accumulate do eventually add up to knowledge and some successes.

Unfortunately, the failures seem to come at great cost to my physical and mental health. But the money is good.

Details of our interview and assessment process is at the bottom of each job listing: https://www.level12.io/careers/

I clicked the first job listing and didn't find anything about the interview or assessment.

They do have a weird note about the company's "Biblical principles" though:

> Level 12 was founded on biblical principles and has biblically informed Values.

Can you please write out your process here instead of making us search for it on your website?

> We exist to serve our customers, our employees, our partners, and our community in a way that brings them genuine benefit, honors Jesus Christ, and advances the Kingdom of God.

Well, that's not what I expected from a software development website. And I can't speak for others, but this alone would be a reason I wouldn't even apply.

I don't hide my faith or the biblical foundations for my worldview, as my posts here on HN will show.

But, I can say I've received way more discriminatory remarks and hassle because I don't hide those views than I've ever given out. I've also had people express a lot of surprise at the fact that I'm in software and have such a worldview. I don't want anyone to be surprised by it so I let it be known. If people think it's inappropriate or decide they don't want to work with us because of it, I can't help their attitude. But I'm not the one being biased.

Yeah, thought the "12" might be a bit of that, but didn't want to assume.

Church IT is supprisingly complex these days. Apparently churches use all kinds of demographic and social media data to identify and contact people who are crisis and recruit them into their flock.

See the bottom of: https://www.level12.io/about/

Honestly I thought this is just another Level N technology company.

Pasted verbatim without taking time to format:

The Rest of the Process

Our application process is outlined roughly below.

But, before you get there, we want to apologize in advance if this process seems...imposing. We have put considerable thought and refinement into each one of these steps in an effort to make sure our hiring process is as well crafted as our software. And just like software, hiring is a lot more complex than it might seem on the surface. Our hiring process is far from perfect (like our software), we are still learning and tweaking, but we want to assure you that each of these steps gives us crucial information regarding you and your development abilities that is essential for helping us to determine if this is a good match.

Consider this: our entire process is less than a week's worth of effort to make sure that where you spend the next 1-5 years of your life is a good fit. Isn't that worth it? Keep in mind that we have deliberately structured our process so that the earlier stages require less effort. Our hope is that if you make it to the later stages of our process, where the time commitment increases, you will have had a chance to get to know us a bit better so you can decide if the time investment on your part is worth it. We care about your time (and ours) and do our best not to waste it! Application Steps

    Evaluate resume and initial email correspondence
    Technical skills questionnaire
    Skills evaluation: 60-90 minute work simulation exercise
    Zoom interview(s): 45-90 minutes in one or two interviews to get to know you & your technical abilities
    Skills tests - phase I: three real-world programming challenges, no trick questions here (paid)
    Skills tests - phase II: project-based skills test: we give you a small project description and you build the best app you can (paid)
    Skills tests review interview: 2-3 hours on a Zoom meeting with our dev leadership team to get to know you and review your skills test results
    Collaborative work day:
        As close to a typical work day as we can get. We just want to see what it's like to work with each other.
        We'll assign you work based on a previous real-world project we performed This is a sample project, we're not using candidates for free or cheap labor.
        We will be available via Slack or Zoom throughout the day to talk through the work and assist you as needed.

If you are timing limiting candidates, your process is not evidence based and I question how serious you are about making efforts to mitigate or limit the effects of anxiety on applicants.

You can't give someone an unlimited amount of time to take an assessment and still expect to meaningfully be able to compare results. One person does a good job in 1 hour another person does a good job but it takes them 10 hours. Time limitations are a fact of life. Interviewees are only willing to give so much time to the application/hiring process and we have similar constraints. The time constraints are reasonable for the tasks given.

We are working to mitigate anxiety in our process, I don't think we can ever completely eliminate it.

What changed?

And they all still do (except that the weed and some of the psychedelics may be legal now). It may just be zeitgeisty, now.

Then again, I'm not sure coverage of it is even greater now than it was in past decades. Future Shock was published in, what, the 70s? Or Affluenza? Bowling Alone's not new, though that treats of more than just anxiety. Direct associations between first The City and anxiety were so common they got really tropey in the first part of the 20th century, and later (starting in the 1940s and '50s) the suburban middle class and their (alienating, unfulfilling, and sometimes nearly or entirely useless, as in Graeber's Bullshit Jobs, the core observations of which were made by others all the way back at the start of the modern postwar economy) office jobs got similar treatment, which has continued ever since.

If there's a difference, I expect it's because people are using anxiety to cover more states of mind than it used to. It does seem to have become a blanket term for "mentally ill-at-ease, but maybe not full-on mentally ill" in some usage.

Or maybe it's just that Future Shock was right, in which case we'd expect that kind of thing to get worse over time, until something about the pace of change itself changes.

Even the idea of anxiety was extremely stigmatized, especially in the workplace, and still is but is now less so. What you're seeing is a growth of people talking about it as the stigma lessens.

Now it just adds unnecessary stress and impedes our functioning 99.8% of the time. We no longer live in a situation where a tiger lurking in the bushes is likely, but our brains haven't evolved to compensate for that.

The Internet is amazing!*

*As long as there is a ban on discussing people , once you start discussing (and most importantly) advertising people on the internet , it's over.

Endless comparison ensues and anxiety skyrockets for everybody.

Humans were never made to be aware of being 1 unit in an 8B sample. The person sitting for an interview has high anxiety because they know they can be replaced easily

That said, I don't think anyone ever thought interviews were anxiety free.

Ah, the convenience sample problem.

IANAL, but my understanding is that discriminating is allowed if it's relevant for the job. Requiring programmers to deadlift 150b (which probably discriminates against women) would run afoul of anti-discrimination laws because it's not relevant to the job, but requiring that from construction workers is probably legal.

https://en.wikipedia.org/wiki/Bona_fide_occupational_qualifi...

The ability to code is less than half the battle. The other half is actually making sure the idea you have is even a good idea. Any moron can write garbage in a room alone.

The premise of the test is whether or not a person can write code that solves a problem. Which is literally the lowest bar possible for a coding interview.

How about the thought process it takes to derive a optimal solution? Maybe interviewers want to test someone who can actually collaborate with them, explain their reasoning, and logically come up with a solution? Maybe that's more akin to real life than being in a cubicle coding all day alone with 0 human contact? Hmmm...

I don't think that that's a sufficiently generous consideration of how differently people think. Not everyone narrates all of the steps that are needed to solve their problems in a linear way of fully coherent arguments and needing to do so might slow them down, similarly to how some people don't have an inner monologue at all.

Instead, consider that some might have "checkpoints" in the problem solving process that they can formulate after a bit of discovery and trying some things out: "Okay, so i felt that X might work because of Y, but it didn't because of Z and now i probably should try something else..."

Having 5 to 10 minutes of silence between such sentences would be awkward in probably every single real time interview, thus people are forced into a mode of thinking that they won't do in practice, unless pair programming with someone else live.

I don't know about you, but most of the communication with my colleagues happens either before or after development, mostly asking questions about specifics in Slack when needed, or rarely escalating to calls for non-trivial situations/questions (even though i fail to recall the last time when i called someone about a particular bit of code, yet have often explained things to others).

So, as opposed to calling said people morons or claiming that every single thought needs to be representable to others, maybe it's useful to consider that the way people think might play a part in it, that there are also preferences people have for synchronous vs asynchronous communication (which doesn't imply NO communication) and that there might even be cultural differences?

I've actually been passed over fot jobs because I wasn't confident enough. Well, stick me in a room full of MIT Ph.D.s who ask me to solve hard AI-related problems and what do you expect? Do you want to hire a programmer or Gilderoy fucking Lockhart?

"Yeah tech interviews are bad... If you don't know how to do em! Everyone's an idiot except me, because I always do them right!"

and

"Well if you can't reverse a binary tree by taking "a day" to study [by having memorized every question rather than thinking through and actually solving a problem] then I guess you're not a real engineer. If you make a syntax error, you're not a real engineer. Nobody would make that problem on a test. You're just making up excuses."

Maybe some of you do an OK job and reading between the lines and seeing if someone is a good developer (something I have literally never seen or heard of in practice), but it sounds like you're just interviewing people who are naturally good at test taking / memorizing academic questions and then auto-failing everybody else and just not talking about it here. I guess those fall into the assumed category "fake leaches who do nothing for a living" / "other" category you summarized in 1 word, even if they have a decade of experience.

"Oh, no that's not true. The interview process is bad, but _I_ know what I'M doing so I'M not the problem. It's everybody else that's wrong."

I could've told you all of this ;)

> [...] all of the women who took the public interview failed, while all of the women who took the private interview passed

there's other underrepresented minorities that also underperform in these interviews

Nothing will change for the foreseeable future

Makes me wonder if remote interviews will help or hinder this situation.

So, at least IME, it's not helpful.

I'm just exceptionally sensitive to rejection and evaluation, and over the years, the interview process has become more traumatic for me, rather than less. Even decent technical interviews (ie - complete the task 100%, don't flub, don't blank out) can take me days to recover from - my physical/emotional reaction is often very far from where my rational mind perceives the situation. I was once deeply distressed by an interview where I ultimately received an job offer.

It's a common aspect of ADD (rejection sensitive dysphoria), but it only really becomes a disruptive issue for me during job searches. However, as I develop as a coder, and apply for more senior positions, the gap between my performance in interviews and my perception of my abilities and value as a coder gets wider, and so does my distress.

I've considered avoiding proctored and timed interviews entirely, but the cost of this not small: the more in demand a job opening is, the more motivated the hiring personnel are to streamline the process and to be comfortable with low-value methods to pick and choose between candidates - they have so many more candidates to eliminate. So, in the past, I feel I've taken jobs that I did not feel entirely excited about and ended in toxic work situations, that I was hesitant to leave, due to the trauma involved in hiring.

I've probably disclosed more than is wise, given that I'm actively looking for work right now, but I'm kind of exhausted of hiding myself, and any hiring manager whose snooping my HN account is sure to find even better reasons not to hire me :)

I did eventually find success. But that took years of not just grinding LC, but so many failed interviews. And nearly $1k on mock interviews and books.

It's clear these companies are selecting for a very particular type of person, even if other types are just as capable of actually meeting/exceeding expectations once they've secured the job.

But I can't argue with the money so I put my body through hell to get there.

lol - truth. Sadly - my wife became my ex-wife over it. She wanted the $3m house but without the husband having to grind for it. :( (Of course - she didn't work)

Naa don't worry about it, that's very unlikely. And if someone disqualifies you for what you wrote here I don't think you wanna work for them anyway.

I've nearly passed out in whiteboard interviews. I've had my BP spike to 150. I've nearly completely shut down. This doesn't happen even most of the time - I've also run multiple high profile launches for companies you know of and I react to emergencies extremely cool and collected. But I have a background that includes severe childhood trauma. Just to help your imagination!

I underperform severely from trying to keep it together during that time, and the perfect scenarios/answers always come to me minutes after the interview is over!

At the same time, if I ask you a question and your eyes roll into the back of your head because you can't handle the pressure of coming up with an answer at a time where the result of getting it wrong is literally the status quo... then you probably aren't going to be the person I want in the long-run anyway. I'm hiring you to be an employee, not a cog.

This may sound logical and like common sense, but it is flat out wrong. Pressure in interviews is not the same as pressure in a job. I've been the one to fix something in 5 minutes during a global outage with 10 people watching behind me, when the previous solution would have taken hours. I've been the lead on calls with 20 partner companies across 5 countries as the largest spike of traffic per year hits us. I can handle pressure.

I've also had panic attacks in interviews. I've shut down completely. I've had my heart rate jump to 150. Not every time, but enough for interviewing to be a really big problem for me.

Whats the difference? For me, it's the perception of conflict or adversary. Some interviewers LOVE to put it out, like they're some shining knight protecting their company from the slithering fake programmers. They're looking for reasons for you to fail. They're looking for whether you're a "cog", as you use the word, and more often than not when looking for that you find it. When I'm on a team who all has the same goal, I shine plenty bright. I would ask that you reevaluate your biases.

You having an adversarial perception of a normal question and answer session says far more about you than it does the interviewer.

While interviews might not be inherently adversarial, they are at least inherently confrontational, there is a power asymmetry. One is being evaluated. The fail state of rejection is present and the other party is willing to use it against you if you fail their expectations. Whereas at most companies with non-toxic cultures, your coworkers do not consider doing that to you. As such, interviews are always inherently different social environments from day to day work.

There's no inherent power asymmetry in interviews outside of your own employer. They have a job to offer. You want the job they're offering. They either offer you the job or don't, you either accept the offer or don't. You are determining whether the employer is a fit for YOU and what YOU want out of your career just as much as they are deciding whether you are a fit for them. It takes two to agree. At the end of the day, you owe each other nothing but the courtesy one would normally have for someone you are about to spend an hour or more with. On either side of the desk, I interview for jobs much better than most because I always keep that in mind. Most people claim to understand that on a conceptual level but they don't actually process it.

As the interviewer, I'm mostly interested in gauging the talent level of the individual and their interest in the problem domain that we are trying to solve for. As the interviewee, I understand that the worst anyone can do to me is waste my time because either our values don't align, the project isn't interesting, my skills aren't a fit, or there are simply better candidates out there. These are all okay.

When I took my first job after being the sole developer at a company for a decade, it was going to be the first time I worked with a team of devs. The first time I worked with a version control system in a professional setting. The first time when I was not going to be the main point of contact for any flaws or failure in the system. The first time that I wasn't going to be the main designer of the system's components or front end. The first time I would ever work with Angular. I told them all of this.

Know what got me the job?

I could tell you every technical detail about everything I had ever done, but also fully admit where I was lacking. I left no grey area and offered to elaborate where necessary. Either I did something and was confident that I could reproduce it (or explain the business / design decisions behind it), or I had no on-the-job experience but expressed confidence that (a) I could learn, and (b) that I was enthusiastic about learning about the problem domain. And I got along with everybody I talked to because my aim was to be a part of a team and not some weird data processing oracle.

Managers want a combination of talent, technical expertise, interest, and team fit. This shit isn't rocket science. You are totally within your rights to cancel an interview if someone tries to make you be a whiteboard monkey and regurgitate data structures that you will either never use or have widely-used open source libraries that are available, or if the interviewer is disrespectful to you, or if they aren't respectful of your time.

As a matter of fact, I recommend it. But at the end of the day, if they don't hire you, you've lost nothing of value but the time it took to interview.

There's also the matter that a rejection could mean you're deprived of a potential livelihood. That's high stakes since it's connected to your survival. This might be an exaggerated stress, but the connection to motivation is there.

And as in all situations where one is being judged, one's ego is also being tested. To many, an interview rejection might not mean anything. To others, it could call into question their skills, their status as an engineer, their very person into being. Again, that is an exaggeration, but it is valid. Software has become a very competitive industry, and the corporate rhetoric that floats around ("doing the best job of your career", "make your job your life"), can have a very totalizing effect on people's self-perceptions.

Even on a mundane level, because software interviews are notoriously opaque and most places don't provide feedback, candidates are left guessing what they did wrong afterwards. It's not necessarily a big puzzle, but having the uncertainty of knowing what one's flaws are is an inherently anxious feeling.

You seem to have a very strong opinion of your experiences, of your capability as an interviewer, and your organization's interviewing process. That's great! Bully for you. But you absolutely cannot extrapolate your own experiences for the entire industry. If all interviewers were as anxiety-reducing as you say, then this discussion thread wouldn't even exist. You are not the industry.

Fortunately not every company is like that. I’d suggest finding the good ones.

I think you've found the core idea.

Some profession include situations with actual stress and mortal danger. Doing good programming should be more like solving high school math problems in solitude than a high pressure social interaction.

Or: if your development environment has high stress interaction get a consultant to settle the issue, you likely have multiple issues that need to be dealt with.

Performance anxiety is real though. One mark of a good interviewer is how well they can get a candidate to relax and perform at their best. I’ve done over 400 interviews and I still worry I don’t quite have that skill down.

You don't understand the problem, and are doubling down on the solution. Sadly common.

Like how? Honestly. What answer are you immediately looking for if there's a bug? You're looking for a fix, not an answer. And it takes time, a bug fix for a non trivial production system is almost always 10+ minutes unless it's some silly html/css bug.

So they weren't studying real interviews. They were studying fake interviews as performed by a bunch of PhD students at NC State. And it turns out those fake interviews weren't good at assessing software skills.

This just doesn't seem like a meaningful study. Interviewing is a skill; you can't just assume that a random PhD student is just as good an interviewer as an experienced, professional software engineer. Heck, many PhD students won't be able to pass a typical tech interview themselves.

It's psychology research what did you expect.

Also, it's social science research with a small sample size, which means that few to no conclusions should be drawn from it (see: replication crisis).

It's at least an attempt to apply some scientific methodology to examining the current interview process, and even if this individual research is flawed then it simply means more studies should be done with better sampling.

I think those places are screwing up, since they usually can't match FAANG comp and anyone who is great at those kinds of interviews will just go to FAANG instead, but whatever.

Stop pretending that only FAANG are doing these.

Tech sector job interviews assess anxiety, not software skills: study - https://news.ycombinator.com/item?id=23848039 - July 2020 (1141 comments)