I know why rejection emails suck – I write them | Hacker News Reader

I know why rejection emails suck – I write them

triplebyte.com

365 pointsnosseo407 comments

I believe that the article is fundamentally wrong.

The bulk of the article is true. But companies are not lying when they say that legal risk is a reason not to send feedback.

Triplebyte is in the unusual position of being able to say, "Everyone who has enough technical skill gets through the interview." And that fact is sufficient to defuse their risk. But real companies don't have the luxury of ignoring non-technical aspects of the job.

Here are real reasons why I've seen people denied a job. "Nobody could understand his accent." "Accidental personal referenced summed him up as, 'Loves to make things crash and burn in production to see the pretty fireworks.'" "Nobody could believe the argument he got into at lunch."

In my books those are all valid reasons to not want to work with someone. However the first opens you up for an accusation of racism, the second would break a personal confidence, and the third had demonstrated sufficient irrationality that tiptoeing away was a great idea.

And you can't give feedback on technical issues, and not on the rest, because that amounts to a tacit acknowledgement that there was something non-technical. Leave the non-technical to your imagination and guess what happens?

On the point of legal risk, I’m concerned by the authors naïveté in believing that as long as you’re not actually discriminating based on race/sex/religion, you won’t be accused of it.

The more data you put out there, the more likely that someone will crunch it and find some statistical patterns that they will label “racism” or "sexism". Even if you’re innocent, you will get dragged through the mud in the press and maybe even in court. Not worth it. No matter what, you lose. And what’s the upside? You gave some random guy some feedback.

This is the world we live in, unfortunately.

The upside is that you've treated a human being with decency. People you treat decently in rejection help you with later hires. If you're going to argue the fantastical downside, you should at least acknowledge the possible upside (which my company, and apparently TripleByt, have both experienced).

That’s why I said it’s unfortunate. I intended to capture the logic of why things are what they are.

And as much as it’s great to help someone out with some feedback, it’s not so great to risk the livelihood of your employees—you know, the people who actually depend on you to provide for their families—and the survival of your company for it. Sometimes doing the right thing requires you to have some perspective and be cold. This is one of those situations.

I think you're way overblowing this, but it's possible you know more than I do. What makes you think "either willfully or accidentally mis-interpreting rejection feedback" is a meaningful threat to any company? Have there been cases where companies were wrongfully sued for such a thing that I'm not aware of? And have they gone out of business as a result?

I've read an awful lot of employment case coverage and don't remember seeing anything like that. What I do recall seeing are people getting hammered for flippant comments _during_ an interview, but that's an entirely different thing.

Given how few companies give interview feedback, I would predicted very little in the way of lawsuits involving that. People can't "willfully or accidentally mis-interpret" what you don't say.

The real question is, "If people gave interview feedback, would they get sued for it?" I think so. Doubly so if the feedback was at odds with the candidate's self-image or if it is written. (It is a lot easier to file a lawsuit based on what was written to you than your memory of what was said.)

More importantly HR departments universally say so. And as long as HR departments say so, managers will follow their advice and not give interview feedback.

HR departments say so because if no one ever gives interview feedback, no one will ever get sued for giving the "wrong" feedback. They are like the legal department in that they will never look to help a company actively gain a competitive advantage, and certainly never to do the decent thing by people outside the company's management.

Then it's correct to never give feedback. Company getting sued is not a competitive advantage.

>the more likely that someone will crunch it and find some statistical patterns that they will label “racism” or "sexism". Even if you’re innocent

The existence of that pattern by itself might be enough for a company to be guilty of discrimination. If a policy disproportionately harms a specific protected class and they can't show a legitimate business reason for that policy, it is illegal regardless of intent. It is called disparate impact.

No. Any data exhibits random patterns, especially if you try too hard.

If you check for 10 patterns, each at the 95% significance level (p<0.05), there's a 40% chance of getting at least one false positive. Look for 20 patterns and that goes up to 60%.

That's why science requires you to formulate a hypothesis before running the experiment. And why finding a pattern through data analysis does not warrant a witch hunt.

I don't know what to tell you. It isn't my opinion. It is the law. [1] You can't just saw "No." and be done with it.

It also isn't about setting up a witch hunt. It is about protecting people from discriminatory practices even when the discrimination is neither overt or even intentional.

[1] - https://en.wikipedia.org/wiki/Disparate_impact

simsla is giving a reason why that's a bad law – they're not disagreeing that this law exists. A law can have been well-intentioned by legislators yet get abused in practice.

And here you're forgetting about the significance of the patterns themselves.

95% significance of the fact that no women or ex convicts were hired for the job? Seems significant enough that a newspaper would write about it.

95% significance of not hiring a guy who looking too much of a hipster and has too many tattoos? Not sure, to be honest - I can see how society (and newspaper writers) would easily dismiss that as bs.

Don't try to abstract it away as otherwise it just seems you're justifying something absolutely ridiculous.

Good point about the disparate impact doctrine. More reason to say as little as possible about your hiring decisions. Why would anyone willingly subject themselves to that kind of scrutiny?

My friend works for a large consulting company (you've heard of them). They were hired by a client who needed to reduce their labor costs by 10-15% (read: fire people) because they were hemorrhaging money. The team of consultants asked to NOT be given any performance data - and recommended that the consulting team handle the layoffs and fire randomly - this immunized the client from any discrimination lawsuits and was, according to the senior consultant, the most cost effective way to handle a layoff, once the cost of litigation was factored. The client signed off on the plan and the consultants executed it. The client was a big (>10k employees) tech company.

This is the world we live in, unfortunately.

The team of consultants asked to NOT be given any performance data

I call shenanigans, because people are not made redundant, positions are. Who gets laid off is related to their job not existing anymore, nothing to do with them as an individual person.

I'm not quite sure I understand. Calling "shenanigans" generally means disagreement but your second sentence is entirely consistent with what I wrote - the company had overscaled and needed to eliminate redundant positions, regardless of whether those that held them were high performers or low performers. If you are disbelieving my claim, what evidence could I provide to convince you that it's true?

I think this is a misunderstanding. If I understood correctly, you are saying the company needs to reduce its size and therefore randomly eliminate people at some positions (say, need to reduce engineering by 10%), while the other commenter was challenging the fact that the company needs, as a whole and independently of the position to reduce its staff by x%.

Both are possible.

>You gave some random guy some feedback

I've noticed you've used "guy" 185 times in the past 5 years, but only used "girl" 58 times. This is a statistically significant difference. You will hear from my lawyers.

Most engineering interviewees fail to advance because of cultural/personality/communication issues and not technical competence. The amount of people I've washed out of the interview process because they've gone on some rant about windows vs linux, political ideology or just came off as unable to communicate in general.

This is also the hardest to communicate as it is something inherent to the candidate. It's not personal, but it gets personal at this point.

> Most engineering interviewees fail to advance because of cultural/personality/communication issues and not technical competence.

Not my experience. At least when hiring for programming positions, the typical fatal issue is that the candidate's coding is weak.

In my first role as a hiring manager, I didn't stress coding tests for candidates with long work history on their resume. Since then, I learned better.

I've seen candidates with anything between 1 and 15 years of full time coding work on their resumes fail to answer basic fizz-buzz level coding questions.

At least for the candidates I've seen, the biggest single reason why they get rejected is failure to perform the one main function their job requires: coding.

”I've seen candidates with anything between 1 and 15 years of full time coding work on their resumes fail to answer basic fizz-buzz level coding questions.”

I haven’t seen this. I have, however, seen lots of junior interviewers ask idiotic questions and wash candidates out for bad reasons, and then turn around and claim the candidate ”failed at fizzbuzz”, just to cover their own ass (or because they think TopCoder medium questions are “fizzbuzz”. Equally stupid.)

Me personally? I’ve never interviewed a senior person who couldn’t code at all. Not after the phone screen, anyway.

> I have, however, seen lots of junior interviewers ask idiotic questions and wash candidates out for bad reasons

Why are "juniors" interviewing candidates? Let alone juniors asking "idiotic questions", and having decision-making capacity?

> then turn around and claim the candidate ”failed at fizzbuzz”, just to cover their own ass

Coding questions are among the most quantifiable and objective questions there are. If you know of something even more objective, let me know because I'd love to try it.

They are repeatable and have well-defined success criteria. Ideally you have two interviewers in the same room, and it's very clear if the candidate did or did not solve the problem. You can't really fudge it, even as a single interviewer, unless you're willing to outright lie that the candidate didn't write a working solution when he did.

> I’ve never interviewed a senior person who couldn’t code at all. Not after the phone screen, anyway.

Yes, if you do a coding phone screen, then obviously you're screening out those who can't code. I'm sure you saw some impressive resumes fail that screen, though.

”Why are "juniors" interviewing candidates?”

I don’t know if you’ve noticed this, but the average age of programmers these days is just slightly above “right out of undergrad”.

If you wait for the senior people to interview everyone, you’re going to be waiting a while.

”Coding questions are among the most quantifiable and objective questions there are.”

Bullshit. Coding questions feel objective, and programmers love to pretend they’re objective, but like any other human evaluation process, they’re subjective. It’s not like you automatically get the job if you get the answer right.

Unless you’re verifying that your team is generating consistent, reproducible outcomes, I can pretty much guarantee that they’re not.

OK, I suppose lack of seniors is a legitimate constraint.

Still, interviewing is so important, that I typically give it a high priority. Even when I had only one other senior engineer, I made sure each candidate spent a long time with each of us.

Typically, I'd go in with a junior developer, and he'd go in with some other junior developer. I'd even see the same candidate twice rather than have two juniors interview him.

I've been on the other side of that kind of interview and I know how badly it can get messed up.

> Coding questions feel objective, and programmers love to pretend they’re objective, but like any other human evaluation process, they’re subjective.

I don't see a reason to swear, as this is a friendly discussion. Either way, we'll have to agree to disagree.

Coding questions ideally yield an answer that can compile and run and return correct output for at least some valid sets of input. That's about as objective as it gets.

> Coding questions ideally yield an answer that can compile and run and return correct output for at least some valid sets of input. That's about as objective as it gets.

Except for coding style (incl. naming convention), code organisation, test coverage, arch style, level of abstraction..plus a myriad of other things. I don't know anybody who treat the code in a coding question as a black box. It gets about as subjective as you can get when reviewing, with the (objectively) correct answer weighted the least.

Shit code that gets the right answer rates worse than code which ticks all the above subjective boxes but gets the answer wrong.

> Coding questions feel objective, and programmers love to pretend they’re objective, but like any other human evaluation process, they’re subjective. It’s not like you automatically get the job if you get the answer right.

> Unless you’re verifying that your team is generating consistent, reproducible outcomes, I can pretty much guarantee that they’re not.

It seems as though there are a fair number of things like this, where people sort-of play act science but don’t bother with the rigor. I guess it’s a type of cargo culting.

This topic was pretty lively last time I commented about my interviewing practices. Coding is a creative effort -- yes. It's not objective.

But I see no other way to test if the person is competent than sitting them down with a problem to solve -- if only to have them explain what they do and don't understand, and what their process is.

This is a key point. I see a lot of criticism of the coding interview. But what's the viable alternative?

My goal is to figure out the candidate can do their job - write software - and that myself and the rest of my team would enjoy working closely with them on their daily tasks.

How else do I figure that out, if not by a coding exercise?

I’m not saying that you shouldn’t do a coding exercise. I’m saying that coding exercises are overrated and far too difficult.

Programmers today think that TopCoder questions are “FizzBuzz” tests. That’s idiotic. Joel Sposky wrote that blog post to say that you should do an absolutely minimal check that someone can write code, then move on to more important things. It’s just bizarre how people have twisted that over the years.

But to answer your question: focus on what matters. Communication, writing skill, the ability to read code (this is easily 10x more important than algorithmic wizardry IRL), good habits (e.g. “does this person insist on putting all of their code in a single file?” - an actual thing I have seen!!), opinions that match your team, etc.

All of these things can be answered in interviews, but nobody cares to try.

Communication is obviously being tested in both phone screens and onsites. It's not like a candidate in a coding interview can simply start coding silently, finish, and then pass to the next stage because their code works. A big part of a coding interview is working with the candidate.

> the ability to read code

How do you test for that in isolation?

There are exercises that do that: you show the candidate a piece of code, and ask them to find the bug. They have all the worst issues that folks here are complaining about, amplified: stressful, awkward, etc. In my experience these types of exercises are also more random: i.e. depend more on luck. Sometimes great candidates fail them, and poor candidates get them right on a fluke. So they are overall less indicative.

Ultimately, though, it's back to the first point: how do I test if the candidate can do their job, i.e. code?

A candidate may communicate really well, say all the right things in best-practice questions like the one you mentioned, write well in English, but still unable to code their way out of a matchbox.

Again, nobody said “don’t test if a candidate can code”. You should do a minimal test, then move on to more important things, rather than beating the same horse.

”In my experience these types of exercises are also more random”

Well, “your experience” also says that you regularly encounter senior candidates who can’t code at all. I doubt the statistical validity of your experience.

> Joel Sposky wrote that blog post to say that you should do an absolutely minimal check that someone can write code, then move on to more important things.

Interesting, and I won't look up the article again before writing this comment.

I remember it as saying he was having a hard time finding people that can code at all, that a FizzBuzz is weeding out a large percentage of applicants. I don't recall it as a gateway to move on after.

You’re remembering it incorrectly.

Note that "junior interviewers" are not necessarily junior, just junior as interviewers. They may be good coders, but they don't know what is reasonable to expect for the role, or how to test for it.

Furthermore coding questions stop being quantifiable and objective as soon as you add in, "What feedback do you give, when, and how?" Two interviewers asking the same question of equivalent candidates can get very different results based on how stressed they make the candidate, what hints they offer, what followup questions they ask, how well they telegraph whether the candidate is on the right path, and so on.

> Note that "junior interviewers" are not necessarily junior, just junior as interviewers.

Sure, but these are highly correlated. If you've been working in startups for a few years, you will have some experience in both coding and interviewing coders.

Even most of the successful large companies are pretty good at cultivating interviewing skills among their employees.

> Furthermore coding questions stop being quantifiable and objective as soon as you add in, "What feedback do you give, when, and how?"

I would moderate that statement as "become less quantifiable and objective". They're still more objective than "tell me about the project you are most proud of" or (worst) "what is your biggest weakness?" (perfectionism, duh!).

You can also control many of these factors by standardizing interviewer behavior. For example, "no feedback of any kind until the candidate writes a working solution", or working off a predefined set of hints.

Sure, but these are highly correlated. If you've been working in startups for a few years, you will have some experience in both coding and interviewing coders.

Even most of the successful large companies are pretty good at cultivating interviewing skills among their employees.

I would put it the other way around.

My experience is that most startups just put you in front of people and tell you to figure it out. People who have done that for a bit wind up with really bad interview habits because they never get corrected. My experience with large companies (Google and Amazon) has them giving interview training. I learned a lot more about interviewing from that than the informal practice that I got in startups.

> My experience is that most startups just put you in front of people and tell you to figure it out.

Some do, sure. And that's the difference between a startup and a regular company right there: that "figure it out" bit.

You'll mess up and fumble and come up with crazy ideas, 95% of which are worse than what the established companies are doing.

But you'll learn a ton along the way.

It's messy and inefficient but that's how startups are.

I personally learned a ton from hacking interviews at startups and all that "figuring it out".

Also, guess what? All these sacred "FAANG interviews" that seem to have come down from the sky, etched on tablets? They were developed by Microsoft back when it was a startup, then evolved by various SV companies at their startup stage, too.

The next great idea in interviewing also won't come from the thousands of engineers obediently marching to the tune of the same principles everyone is using, but from some startup trying something crazy and ambitious and miraculously getting it to work.

> Coding questions are among the most quantifiable and objective questions there are.

Only in the most trivial cases (for statements, not necessarily solution). If you want to assess engineering ability, specific coding questions are a small, tiny sample of the space, and generally the more difficult the problem the less useful it is.

> Me personally? I’ve never interviewed a senior person who couldn’t code at all. Not after the phone screen, anyway.

Not sure how common this is, but I've been one of those flame-outs. It was during a Google phone-screen.

I was given a very simple programming problem, and something in my brain just broke (figuratively).

In retrospect it was probably from being too tense because I was star-struck about the employer.

But on that one particular interview, I could barely have written printf("fizbuzz\n");

If it's any comfort: everyone performs worse under the stress of an interview. This is widely recognized by hiring employers, and accounted for in the interview evaluation.

For example, if I test-run a new question, and it takes my engineers 20 minutes to solve it, I will add 30-50% handicap for stress. I.E. if a candidate manages to solve it within 30 minutes, that's roughly equivalent.

Unfortunately, there's no way to account for someone having a complete blackout such as you describe.

Don't ask people to do something they've maybe never done before and will never have to do on the job (write code with a marker on a whiteboard as seconds tick down). If you want a reasonable coding assessment, sit them down at a terminal and give them an hour (and an appropriately difficult problem). But literal whiteboard tests are a recipe for complete blackouts.

> If you want a reasonable coding assessment, sit them down at a terminal and give them an hour (and an appropriately difficult problem).

I am doing just that.

> But literal whiteboard tests are a recipe for complete blackouts.

Not always. I've done a lot of whiteboard interviews too. It's a different way to discuss a problem, and one that people do use at work.

Most design sessions happen with a colleague or two in front of a whiteboard, not sitting at a workstation.

I disagree that blacking out is so common, though I understand it does happen occasionally. Also, we typically do at least 5 interviews in every onsite, one blackout wouldn't destroy the chances of an otherwise strong candidate.

It affects some people much more than others, it's not a uniform random occurrence, so a person with one blackout is more likely than most to have more than one. Some people are very anxious during interviews, and their frontal lobe basically shuts down, others love interviews. So it's very likely that many of the people you've interviewed who you thought "couldn't code" actually just couldn't code while you were watching them.

I think that's pretty common. At least, I hope it is. I have been that person, and completely flamed out. Probably came across like I knew exactly nothing. I do well under routine job stress, tight deadlines, etc, and I have a great track record producing real results, but something about the interview process puts me on edge and stresses me in unique ways.

Fortunately I don't find myself in that style of interview anymore. The guy interviewing me already knows I can code, so all we are really trying to see if there is a culture fit. My preferred interview location is over beer.

I personally don't care that much on how well a candidate can code, as measuring that is itself quite hard (in my opinion). What I like to interview for is someone who really likes to code. I look for things that demonstrate recent personal growth, ability to explain & teach something they do know, a tendency to avoid claiming they are good at anything, open mindedness on trying new things, etc. In my experience, someone who really wants to code and shows a minimum viable capacity for doing so is the person I want to hire.

> In my experience, someone who really wants to code and shows a minimum viable capacity for doing so is the person I want to hire.

My comment referred specifically to candidates with at least one year of full-time hands-on development experience under their belt. The typical candidate I interviewed had 3+ years of experience.

If you want to code, then you should have ample opportunity to do so during a year or more of full-time employment.

If you were working in a full-time programming position for over 3 years yet you can't write even a trivial amount of working code during the interview, then clearly you either lack the capacity or the will to develop your programming skills.

Programming nowadays is easy - everyone has a powerful laptop and internet access. It's not like you need privileged access to some $100k time sharing machine using punchcards, and learn machine-language from obscure mail-ordered manuals.

What excuse does anyone claiming to "want to code" have for not coding already?

I'd be quite suspicious of anyone waxing poetic about their genuine heartfelt love for coding who somehow couldn't demonstrate any coding ability.

Would you believe someone who swears they "love long-distance running", but collapses after 50 yards and says they just didn't have the opportunity to put this great love to practice?

> If you were working in a full-time programming position for over 3 years yet you can't write even a trivial amount of working code during the interview, then clearly you either lack the capacity or the will to develop your programming skills.

Genuine question... What kind of question(s) would I ask to get someone to demonstrate they can code? If my questions are effective, I'm fine. But if my questions stink, it'd be easy to overlook that fact that many excellent people wouldn't be able to answer them well.

There are different approaches, but you can come up with any simple programming task. Doubts are fine, so just run them through some of your existing engineers, especially those you think are really good. If people you consider excellent engineers fail them, then it's back to the drawing board.

That's an exercise I do for hiring in general. For example, every time a hiring process change is proposed, I run it through my existing engineers, and make sure I would have hired them by this process.

For example, in a place that was starting to get a lot of great candidates, someone proposed tightening the education requirements of the preliminary screen. I quickly observed that would have disqualified one of my best performers, who didn't have a CS degree at all. The proposition was therefore struck down.

> There are different approaches, but you can come up with any simple programming task.

My challenge internalizing this phrase is that I have a hard time latching onto the idea of simple. It's a highly subjective measurement. For example, if I ask an to implement FizzBuzz & they can't do it, to my satisfaction, are they a not worth hiring? I suppose it depends on what satisfies me. If my criteria for hire/no-hire is whether they wrote concurrent & streaming FizzBuzz, maybe my expectations are unrealistic. If I'm expecting someone to write FizzBuzz in as few characters as possible, am I going to flunk anyone who implements a verbose concurrent & streaming FizzBuzz? Is there a case where it makes sense to hire someone who implements Enterprise FizzBuzz? I may struggle myself with keeping things simple, so there's that to consider :)

Why ask any questions? Sit them down to a simplified version of a real world class your company is working on with corresponding unit tests and tell them to make the tests pass. That was one of my favorite type of interviews and I've used it before.

I do like practical exercises.

For simple questions to verify a person has basic programming competency, I'd keep it very simple. Any simple problem which requires you to use if / else if / else or switch case, or something involving simple for / while loop. This is something any programmer should be able to demonstrate.

I also learned this not long after I started conducting coding interviews. People with resumes from the best schools and the best companies would fail in multiple interviews in a row. Nowadays I don't even look at the resume, though to be fair I am only tasked with evaluating coding ability, and not things like culture fit or pay scale.

They can't code because you are looking figuratively over their shoulder---the clock is ticking next to a hundred grand in a suitcase.

A single question is pulled from subjects vast enough to fill up years of college and there is no time to research, as one would in the real world. Binary pass/fail with your pride/livelyhood/family on the line.

Please state your last exam conducted under such conditions?

Oh and your questions probably stink. I've gotten plenty of them with recursion that might take ten minutes in seclusion but simply not possible under the gun.

> They can't code because you are looking figuratively over their shoulder---the clock is ticking next to a hundred grand in a suitcase.

There is a difference between me asking you how to optimize a graph algorithm (good luck--I probably couldn't do that on the fly with references in front of me) vs giving me a basic FizzBuzz.

If I let you pick your language for your FizzBuzz, you need to demonstrate at least some of the following things:

I/O of any flavor (I'll even accept Logging if you don't do standard I/O or console I/O)

String formatting

Modulus Operator

Nested-If statements (or equivalent--Matching, case/switch, etc.)

I'm not looking for production code. I'm looking for 10-20 lines of "A High School senior with a computer class could pass this."

This is not limited to programming, sadly.

I used to have to interview VLSI designers with "Draw me an inverter", and 70% of them couldn't pass.

To be totally honest, I always find these stats about some x% > 50% failure to program at all totally unbelievable. What do these people do all day, if not design and build software? Yet they're apparently completely unable to write code? How is that possible? I understand that there is always a certain amount of slack and underperformance but any workforce would be completely paralyzed by 70% completely incompetent workers. And yet companies everywhere still produce software.

It's because some large percentage of your time at work is spent in meetings, writing emails, discussing things, etc. where actual ability to do the core task isn't necessary.

And then some large percentage of "enterprise software development" is just hooking up buttons and text fields to a database, and doesn't require any more algorithmic complexity than a few if() statements.

And then some large percentage of the remaining work can be performed adequately by just picking some appropriate ready-made solution off Stack Overflow.

Put them all together and chances are, you can skate by for years (and actually perform acceptably) without ever actually needing to write FizzBuzz-level code for yourself.

1) Selection bias

Good/excellent programmers rarely need to interview except as a formality. Consequently, you are, by definition, interviewing weaker programmers.

2) Tool use masquerades as programming

Visual Basic 4/5/6 was one of the original sins in this genre, but it continues now with other tools and frameworks. Being able to point-and-click a tool and plumb it together isn't programming--but people will claim it is. Then when someone asks for an actual program--those people fail.

This does not necessarily mean that those people are not productive. However, it does mean that they can't actually function in a position where they are expected to program.

> What do these people do all day, if not design and build software?

Indeed this is a fascinating question, and I explored it a few times.

Some folks who have multiple years of "software engineering" on their resume worked in a place where they did some form of "paint by numbers" programming, producing some work by modifying templates with limited (at best) understanding beyond the specific blanks they were filling.

An example is folks who work with large frameworks that are designed to be extended with little to no coding, such as WordPress and Drupal.

Then they want to advance to software engineering, so they recast their experience - of essentially configuring and deploying software, i.e. sysadmin - as "programming", and get those 5 years represented as "a full time programming position".

There's variants of that, basically "developers" doing very limited ant-work with large frameworks they don't understand and couldn't rewrite from scratch if their lives depended on it.

There's also a bunch of languages and frameworks invented for the explicit purpose that someone with little to no CS knowledge of programming talent could produce useful work.

Most of us here live in a bubble of startups where we often create products from scratch using lean (or no) frameworks. In reality, a scary amount of the "IT work" out there appears to be what I described above. Possibly a substantial majority.

How do I stop being a bottom feeder?

Cultivate programming as a skill.

Pick up a good introductory programming book. I recommend Think Python 2e:

http://greenteapress.com/wp/think-python-2e/

Go through it cover to cover and do all the exercises. All of them. Don't skip a single page or exercise, not even if you think "I already know this", and certainly not because it's too tough.

Once you're done, you should be able to start applying for jobs in whatever language that book taught you. If you're still not passing interviews, take on a serious - but manageable - programming project, such as some simple application for yourself or someone you know. If you're a web developer, a simple dynamic database-driven website is an excellent choice. If you want to do front-end, a simple Javascript game will teach you a lot.

You don't always have to apply for new jobs so early. Lots of tech shops have some teams where actual programming happens, even if most of the rest of the company is "paint by numbers" pseudo-programming. Often you can start to take on more responsibilities that involve actual coding if you show the necessary abilities. You won't have to change companies, or even change teams.

Good luck!

It's not a big chunk of employees, it's a big chunk of applicants. Because the least competent apply to a lot more jobs.

"The emperor has no clothes."

It's because current tech interviews are a complete failure and none will admit it. In ten years you'll hear a new fashion and today's will be decried a failure.

The set of interviewees for a software engineering position is not really a representative sample of workers in the industry. Particularly at a company that doesn't have big name recognition, you're going to end up disproportionately getting job applications from the bottom sections of tech talent.

You may get only those questions in a junior interview. I get the optimize a graph algorithm ones also.

Now I certainly could do it in the course of a job within a week, with a day or two of research. But not under the gun.

That is the tech interview failure in a nutshell.

We always get these kinds of responses when interview testing is mentioned. This isn't some high-level algorithm analysis on a whiteboard with a panel of examiners grilling you. This is a simple test of basic competence. It's like interviewing a candidate Formula 1 driver and asking them "so which bit's the brake pedal?" If they can't tell you that instantly then they shouldn't be applying for the position in the first place.

> Please state your last exam conducted under such conditions?

University entrance exams.

University graduation exams.

Any other test that you do which you need to pass to enter or continue your career.

> We always get these kinds of responses…

Perhaps you should start listening.

> This isn't some high-level algorithm analysis on a whiteboard with a panel of examiners grilling you.

Happened to me just three months ago. The req is still open, wonder why?

To reiterate:

- Exams have a topic known in advance.

- Exams never have a person sitting there waiting for the answer.

- Exams are never 1 or 2 questions binary pass/fail with incredibly high stakes in unfamiliar territory.

Which is the brake pedal? If only.

You'll get bitter when the rent is due, watwat.

We're talking about "basic fizz-buzz level coding questions". It sounds like you had a bad experience with something else that we weren't talking about.

(As for 'topic known in advance', I'd suggest that if you don't know what topics that you might be asked about in a job interview, maybe you shouldn't be interviewing for that job.)

There’s very little correlation.

I don’t think I’ve ever been asked a “which is the brake pedal” level question in an onsite interview. Usually it’s more like I’m a mechanic being asked “how do you replace the water pump on a 1999 Saturn Ion, from memory, please.”

Maybe as the first "smalltalk" question you'll get a brake pedal, but yes your Saturn-type question will be the "make or break."

That's a benefit of the coding interview, actually. We don't ask you about that particular feature of some library from 10 years ago, which is basically a luck question: you either happen to know or you don't.

We ask you to code a simple task that you should be able to do in your favorite programming language.

Not entirely sure how the discussion of coding interviews veered towards obscure knowledge interviews - the former was expressly designed to supersede and eliminate the latter as one of its core goals!

My last 'coding interview' consisted of a debugging a broken live VM, with a Java app waiting at the end of the rainbow.

The job was for working on bare metal provisioning using yaml and Python, but I could 'use your favorite programming language'.

Before you think this was some third-rate body snatcher, it's a more well-known name that you've heard of.

They still ghosted me, after telling me what an 'amazing' job I did.

Sounds awful. I'd be interested to know what startup it was. But it's no secret that some of the well-known names do tend to drop the ball on hiring and various other aspects of operations.

We ask people to implement a relatively simple algorithm, that’s particularly practical, in the language of their choice. Then we change the parameters and ask them to make it more efficient.

It’s centered around solving a reasonably common place problem, and doesn’t require anything fancy to solve. It’s more of a test in how they programmatically solve problems over anything else. If somebody struggles with it, then they haven’t been bamboozled by some acedemic algorithm problem, they’ve just shown that they’re not going to be able to write clean code unsupervised.

I’m actually on the job hunt right now. If your company is in the Bay Area, I wouldn’t mind an email.

> they’ve just shown that they’re not going to be able to write clean code unsupervised.

The opposite, shown they can’t write supervised under the gun, which never happens On the job.

Exactly. I don't think they are accounting for how some people react to interviews. I've had candidates who have been explicitly nervous and stuttering, and we've consciously had to decide not to hold that against them. They turned out to be a great hire.

I think I can do okay in coding interviews, but only if I prep for that style of work first. It's definitely different. I'm perfectly (or at least acceptably) competent in my day to day.

If we’d ever had somebody crippled by interview stage freight, I make be able to take that seriously. The coding skills you need to pass our test is writing a for loop that mutates a dict. We’ve never had anybody forget how to do that in our interview, but we have had people come up with remarkably inefficient solutions to the problem.

I don’t think it’s reasonable to say that people’s problem solving skills (which is what we’re actually testing) become exponentially less efficient during an interview. But even if it was, the test is still doing it’s job, because what would we expect to happen when we give a person like that a deadline, or ask them to review a PR?

Don't need to be "crippled." Simply a shot of adrenaline is enough to shut down most higher-level thinking. At that point the candidate is just pulling things from memory at random hoping they fit.

> remarkably inefficient solutions

The first one usually is. As the problem gets clearer, better solutions become obvious. That takes relaxation and calm thought however, e.g. Archimedes in the bathtub.

> I don’t think…exponentially less efficient

Doesn't need to be a large difference. With multiple candidates, even 10% is decisive.

There's also the psychological factor of knowing something makes the "knower" think it's easy while the others believe it's hard.

I do lots of interviews as a contractor, and must say they have little to no bearing on my ability. In the real world I've solved every problem encountered, given some time. Interviews almost none, the few successes depend on whether I wrote the same algorithm in the last two weeks by chance.

A random throw of the dice at the craps table would be just as accurate and less stressful for all involved.

That’s just it: replacing a water pump on a common used car is a task any competent mechanic should be able to do. But, possibly not without the repair manual. And, I certainly wouldn’t think they’d be able to describe step by step how to do it without the car or manual in front of them!

Likewise, many interview programming tasks can be are ones a competent programmer should be able to do with the tools of the trade accessible (namely Google and time to think).

Some simply are not. I was once expected to write, debug, and modify a concurrent chat server in an hour long interview. I do think that’s a reasonable programming task, but not one to be completed in an hour, under scrutiny. It’s the equivalent of being asked to rebuild a motor in an interview : definitely doable under real world conditions, but not a realistic test to determine whether to hire someone.

I had to twitch my feet to all three imaginary pedals to figure out the brake is the middle one. Even in this metaphor doing and knowing how to do are distinct skills.

You would fail anyway, because the interviewer thought it's pretty clear that automatic transmission was implied, not manual, since the job is about baking doughnuts.

One possible way to address this issue is by asking candidates to talk about some existing code you give them, rather than trying to cook something up off the bat while under scrutiny and not having access to their familiar tooling.

> I've seen candidates with anything between 1 and 15 years of full time coding work on their resumes fail to answer basic fizz-buzz level coding questions.

Like, how? I used to hire undergraduate student sysadmins / coders, and we had zero candidates fail fizz buzz. None! The worst we saw were people who maybe had an awkward solution to the problem, typically because of unfamiliarity with the modulus operator.

I should stress I didn't ask fizz-buzz specifically, but similarly basic questions.

I should also stress (again) that back then I brought candidates directly to onsites when their recruiters sent an impressive resume with 3+ years of "full time programming experience".

I learned the hard way that most people who unknown recruiters are eager to push through your hiring funnel are unemployed for a reason.

True, but give them something they can do at a computer, in an hour or a day or a weekend. Coding on a whiteboard with someone staring at you counting the seconds is not natural. It's like asking someone to do their job backwards and underwater. You'll get a lot of false negatives.

I don't see how it is inherit to the candidate, probably most people have political believes, OS preferences etc but you should be smart enough to not blurt them out during an interview.

This is a function of where you are in the interview process.

Most people get rejected at the resume stage. Most who have acceptable resumes get rejected at the first screen. All of this is invisible to software engineers who only see candidates at the last interview step.

> Most engineering interviewees fail to advance because of cultural/personality/communication issues and not technical competence.

This must vary from company to company, but it's clear that tech companies spent tons of time and efforts in technical screening. Most questions asked in these interviews are also technical. It's hard to see why candidates would even have a chance to talk about their political views

We took a punt on somebody who was technically very good, but a total culture misfit recently. In his first two months, one person demanded transfer from his team, and another quit. He’s not a bad guy, just painfully socially awkward. He’s the comic store guy from the simpsons, on steroids.

It was a good lesson for us, because it confirmed what we always kinda knew. Doesn’t matter if you’re good at writing code, we need to get along to do good work, and hiring somebody people can’t stand being around is a terrible idea.

Whether hiring managers want to admit it or not, in the vast majority of cases, the person giving the interview already has their mind made up about a candidate before they've said a word (so everything from the resume/background info to initial impression based on looks).

I have a ~90% success rate in guessing whether I'll go on to the next stage / get an offer based on how warm the interview is to me within the first couple of minutes of the interview. The interviewers pre-judged you positively are rooting for you to succeed, and those who are biased against you are looking for reasons to not pass you. (This is assuming, of course, some very basic level of competency and that one passed the initial screening without lying)

"Can't understand their accent" _is_ discriminatory. Please don't ever recommend against a candidate for that.

Companies are definitely taking the easy way out. The reality is that most of them don't have a good hiring process, aren't consistent about hiring decisions, and tend to choose based on factors that have nothing to do with the job they're hiring for.

Good communication is a requirement of the job. If you can't communicate, you aren't likely to be efficient.

Take some time to take classes and learn the language better. Try working in a Spanish-only environment as a pure English speaker and see how far you get.

This doesn't mean "he has an accent", just that they couldn't understand it.

We don't have to litigate this from first principles; this is such a common problem that there is a name for it in EEOC circles: "accent discrimination". You can be civilly liable if you do it.

I wasn't aware of this, but sure enough, "accent discrimination" is addressed by the EEOC. However, in the case that nobody can understand the person due to such a thick accent, the employer may have some argument that it is not discriminatory. Here is the relevant text from the EEOC Enforcement Guidance on National Origin Discrimination:

Under Title VII, an employment decision may legitimately be based on an individual's accent if the accent "interferes materially with job performance." To meet this standard, an employer must provide evidence showing that: (1) effective spoken communication in English is required to perform job duties; and (2) the individual's accent materially interferes with his or her ability to communicate in spoken English. [1]

[1] https://www.eeoc.gov/laws/guidance/national-origin-guidance....

In my opinion as someone present, this standard was met.

(1) Programmers need to be able to communicate about what they did, what they need to do, and how things are designed. (2) Interviewers kept on saying things like, "I managed to pick out enough of the right words that he probably answered me, but I wasn't sure."

None of us cared that he had an accent - we hired plenty of people with accents. We cared that we could not understand him well enough to coordinate with him. But if we had told him that, he would have had grounds to file a lawsuit. We'd have hopefully won, but he could still file it.

How would you have handled a deaf candidate in the same position?

That decision would have been up to HR and the executive team. I was neither.

Speaking personally, if the company hired an interpreter, I would have been OK with it. If the company insisted on having all design meetings in a chat room, I would think that crazy. Most people's typing speed is a small fraction of their speaking speed.

Actually that decision would not have been up to HR and the executive team, would it? In the United States, that decision was made for you at least 28 years ago, right?

Actually, no.

You're referring to the Americans with Disability Act. What it requires depends on the "essential duties of the job" and what is consider a "reasonable accommodation". Those are judgement calls. Those judgement calls need to be made by executives on the advice of HR.

My lay understanding is that the law does not insist that the job requirements change. So if being able to participate in design meetings, daily scrum, and so on are daily requirements for anyone to have a programming job at your organization, they are essential duties. Even if the same job title in another organization has different requirements. (But can you document your requirements?)

That brings us to the question of what a reasonable accommodation might be. Hiring a full time interpreter to follow that person around is probably considered unreasonable. Allowing someone who lip reads a device that can do text to speech is clearly reasonable.

The ADA affects the decision. But it doesn't make it for you.

This is a really weird argument. It seems unlikely that you would succeed in legally justifying excluding deaf people from your team based on the idea that verbal communication is an essential duty of a software developer, which is the analysis that would likely be used against you.

Also: if your management decided to exclude deaf people from your team, wouldn't you quit? I would quit.

The judgement call of whether to act on an argument like that is not up to you and me, it is up to HR and the executive team. If it comes to court, the validity of the argument is up to a judge.

As for protesting choices that you don't like by quitting, that is your right. Speaking personally, deciding not to hire someone because you believe that they will be unproductive in that role seems to me to be a perfectly reasonable thing for a business to do. And I don't see a moral distinction between different reasons why someone is expected to be unproductive.

Presumably with what's called a "reasonable accomodation". For example, interviewers always facing the candidate to facilitate lip-reading and allowing use of a speech synthesizer. Perhaps even paying for a sign-language interpreter (although, for eventual employment, that may well not be reasonable).

These are, of course, just examples from a complete non-expert, and there is a plethora of information on the Internet regarding accomodations, as well as what's considered reasonable (and how that's arrived at for each situation).

Even if a heavy-enough accent could be accomodated in a similar manner (which is debatable, at least), it's questionable if it's a disability under the law (philosophically/morally is yet another matter).

> he would have had grounds to file a lawsuit.

Anybody can file a lawsuit against anyone else at any time for any reason.

To whatever extent that is true, there is a practical difference between the kinds of suits that any law firm can get dismissed, and the kinds that decent plaintiff's lawyer can credibly threaten will see trial.

I think the reality is that credible lawsuit threats will virtually always settle, relatively quickly. That's what I've seen at smaller companies, and I assume it's even more the case where Ben Tilly works.

>Interviewers kept on saying things like, "I managed to pick out enough of the right words that he probably answered me, but I wasn't sure."

Did it ever occur to them to ask "Sorry, could you repeat that?"

Sometimes it takes a bit more effort to understand someone, whether it's because of an accent or a speech disorder or whatever. As an interviewer, you're in a position of power, and you have an obligation to put in that effort.

Have you really never been in this situation. I have, several times. Yes, of course i ask the candidate to repeat what they said. And again when i don't get that. And again. Varying my question a little too see if they'll say it differently. I'll go about 5 times before giving up and either moving on to another topic in the desperate hope that it's the specific words that are the problem, or switching to a chat channel or something. I really really don't want to lose the chance to evaluate the candidate in other relevant areas, just in case I'm the only one who can't make out the accent. (Which has never happened so far, since due to my circle of friends I'm well above average at deciphering accents.)

But even if i do successfully communicate with such a candidate enough to evaluate them technically, i will most certainly bring it up during the debrief. To not do so would be dishonest and unprofessional; i cannot make a call that it would be ok to hire this individual under an assumption that all communication will be written or whatever.

Also, it is very probable that i will have only managed to make it through a small fraction of my intended questions in such a situation.

(I have to say that your assumption seems unwarranted that the previous poster was simply not bothering to ask them to repeat themselves.)

This was exactly the experience, but with the twist that it was a group interview, so interviewers would move on hoping that some other interviewer actually understood that answer.

> in the case that nobody can understand the person due to such a thick accent, the employer may have some argument that it is not discriminatory

So the intent of the law is to prohibit making hiring decisions on the grounds of "I don't like that particular accent", it's not intended to force companies to disregard whether a candidate is intelligible.

Seems sensible enough. I imagine this isn't even specific to foreign candidates - here in the UK, there are quite strong associations with different regional accents (which ones sound 'refined' or 'unrefined', etc). It would of course be unfairly discriminatory to rule out a candidate on those grounds.

Speaking the language and speaking with an accent are two different things. Learning to listen to someone with an accent is a skill you can develop, same as they can develop their english skills (which they will, with practice and time).

This goes both ways, and frankly it is racist to say you can't be bothered to try to understand someone's accent. I've worked with asian immigrants who learned english on the job, it's really not that hard to work with someone with a non-American accent.

And if the DSA in your name stands for what I think it does, you should know better.

It's not racist, because language does not arise from race. Many races can speak one language, and one race can speak many languages. Someone who is racist will be so no matter the accent or language. Language arises from culture. So it might be said that the person is being culturist, if that's a word.

However, I don't see what proof you have that the person is motivated by culturism, when there is a more likely reason, that it's too much work, and he doesn't believe it's his job. It's not my job to teach you English any more that it is to teach you Python. If you don't show up to work knowing both English and Python, it's not my job to train you. I'm talking about severe accents. I have worked with people from another country and had no trouble understanding what they said, and yet another person from the same country, I have no idea what he just said! If you are working on a project with that person, that's bad! If the project involves banking, medicine, or rocket ships, it can be dangerous.

And I'm not being hypocritical. I would not expect to land a job in Spain, even though I can speak Spanish somewhat, because I cannot speak it well enough to work together with Spaniards full time.

As a person who learned English as a second language and who has plenty of family who sometimes struggle with English I can't deny that it is harder to work with someone you cannot understand. Even if English is the only language they speak if I can't understand what they're saying I'm going to not be able to work with them. My relatives have indeed taken classes to improve their English skills. Its just something you have to do.

There is discrimination and then there's being unable to communicate. If you cannot communicate you cannot work together. I think if your English is terrible you just might not be qualified for jobs where your language barrier might ruin productivity and in other cases be a risk to your safety and the safety of others.

It's a hard cake to slice through at the end of the day since there's so many different factors to be considered.

There're terrible accents that are hard to understand. I have one. I had interviews in the Bay Area while I was living in The Netherlands and I had mild trouble understanding Indian and Chinese interviewers. When I moved to the UK I would dread calling service support as all the call centers are in the north. I have an accent and many times when meeting someone new I need to repeat myself, as I have a very unusual accent.

In all of these cases the thing I noticed is that most of the problems with accents completely go away in less than a month. Accents are funny in that exposure is be enough for them to become a non-issue.

>"Can't understand their accent" _is_ discriminatory. Please don't ever recommend against a candidate for that.

Sorry, I disagree. A team is more than just a bunch of automatons punching the keyboard.

If I can't understand what you're telling me, if you can't communicate your ideas, if nobody can understand what you're saying, if everything needs to be explained multiple times, and/or slowly, it becomes exhausting to work with a person like that.

If someone can't communicate their knowledge and skills that's one problem, and a very common one with or without an accent barrier.

If someone can communicate their ideas and do the job and you don't want to hire them to avoid having to actually expend effort in communicating, that's a different problem, and it's not theirs.

If you can't understand them, then they can't do their job. The one who have accent also have to expend effort in communicating, too.

Yes, It is discriminatory. So ? Not able to code is also discriminatory to someone who don't know how to code.

You bet there are absolutly people who want protection from this discrimination. Those people want it broken down to the concept of nothing more than 'I was here first, you must offer the job to me or I have cause to sue'.

It is one of the hallmarks of union labor management. It is one reason why private labor has a competitive advantage.

I think your point that the actual companies have to judge culture fit is critical. TripleByte's interview is about as purely technical as you can get. Their promise to client companies is that the candidates who pass are technically sound to a baseline level. That leaves the companies to judge cultural fit, which is where all of that legal liability seeps in.

I've done the TripleByte interview before. Even got an offer through them (though I didn't take it). Their interview is almost entirely about fundamental skills plus a bit about your ability to communicate. There's very little in that interview where you could come up with lawsuit material.

All of that said, I think their technical interview is a pretty good one. Their interview feedback was accurate, and it definitely felt both more rigorous and more fair than the vast majority of the first rounds I've done.

I agree 100%. I recommend that anyone who gives engineering interviews, especially phone screens, to go through the Triplebyte process.

This is absolutely correct. Companies can and should discriminate against anyone who wouldn't be a good culture fit for any number of reasons. I don't fault anyone who has ever refused to hire me for personal reasons. At the end of the day, a company is a group of people working together toward a common goal. Company is Latin for those you break bread with, and although companies aren't usually that close-knit (modern business lunches don't have the same level of trust and closeness as an ancient meal) the point is still the same: you're a team.

You are a team, but you should still attempt to be objective enough in your evaluation to determine whether a new person will allow you to be a functional team. But when you say "culture fit", the implication is that the team would prefer not to change at all, not that it would accept changing into a different-yet-comparably-productive team.

Maybe I used culture fit the wrong way. I just meant the ability to get along in non-trivial situations and communicate effectively. I've met people who I have so little in common with that we couldn't even share a joke in either direction, because the recipient just couldn't understand it at all. It was so difficult to accomplish even basic things because our experiences were so different that we didn't have common ground to work from. Not that a similar sense of humor is necessary, but having at least some commonality is necessary if you're going to be able to solve problems together.

> It was so difficult to accomplish even basic things because our experiences were so different that we didn't have common ground to work from.

I am curious what kind of work this was, if you can share.

I had a lot of difficulty in the past when working in situations where there was "life-experience" context to the problem space that was not shared by the whole team.

But we had to get the job done so we worked around it.

I think in the end the need to be more explicit, to provide more context and to work towards abstract descriptions of problems was also a positive.

When life gives you lemons and all that.

Sure, you try to make lemonade. That doesn’t mean it will be a success.

Have you seen Star Wars: The Empire Strikes Back?

I've never heard "try to make lemonade" only "make lemonade"

In my experience difficult problems can be solved if people keep a good attitude and are invested in making things work, even when success seems unlikely.

But sometimes you will fail.

I was interested to know what sort of problem space the parent had their bad experience in, and to hear more about how things didn't work out. I don't doubt that there are domains where a "can do attitude" will not cut it.

Yes, I have. One of my favorites, actually.

And definitely nobody says, “try to make lemonade...”. That goes against the saying, I agree.

My point was just that even when you take the “when life gives you lemons” approach sometimes you won’t be getting that lemonade after all. As such, I also didn’t think it to be the best phrase for what (I thought) you were trying to convey.

I agree with your reply, 100%. Thinking a bit more as I write this, I may be wrong above (in this reply; about the wrong phrase) and it is, in fact, the best idiom. Not sure. But now I’m definitely on the fence, at least (compared to above, where I was on one side of the fence).

Exactly this. And it’s often misconstrued as something else.

Facebook gives feedback. I interviewed twice and didn’t pass. They read the feedback report right off their screen to me.

So that makes me question the legal liability reason. Facebook is a bigger target than most for lawsuits. I think it’s just uncomfortable to tell people why you didn’t hire them.

Not all companies can afford to have a legal team review feedback before it’s given.

Yeah, I think that's a big part of the difference.

Also, if somebody posts online complaining about their Facebook interview and the feedback they got, it's essentially going to be lost in the noise of other discussion of Facebook. If somebody posts their feedback from RandomStartup and says the interview was biased or otherwise bad, it could end up being in the first page of Google hits for the company, which would be a mess.

Not for everybody, apparently. They didn't respond when I asked for feedback after my interview.

The fact that you interviewed twice implies you're a candidate they like, but for some reason or another you weren't strong enough.

If a company keeps the door open, it's certainly in their best interest to help you enter it sooner rather than later.

If you don't get a paper trail, you can't sue. Oral feedback is pretty hard to use in court.

I was with you until you said that refraining from hiring someone because his accent was too difficult to understand. That's an insane reason - why pass on a good candidate for this reason? Can your company afford this?

If you are working closely with this person, it will be 3 months before his accent is sufficiently adjusted.

This is a stupid reason to pass.

of course the assumption is there are someone else with similar skill but has easier to understand accent, its no brainier which one to pick.

I've seen this a million times teaching students. They raise a shitstorm for two weeks because they can't understand their TA's accent. Then they learn and can understand them just fine.

The truth is it's part laziness and part racism.

That being said, there is reinforcing incentive to be a bad communicator when the people around you don't make the effort because of your accent.

I am conflicted about the use of racism in this context. Accent varies by ethnicity and ethnicity is a proxy for race, so they are disadvantaged by their race. But if a student had a ta of the same race but no accent it would be fine. Or if the ta was white but had a bad accent the complaining would continue but it wouldn't be considered racism.

Don't be confused - it's not racist. It's "accentist" perhaps. I'm "white" and there've been plenty of "white" folks who I can't understand due to their accent. In some cases, I would not be able to work with them. It was nothing to do with 'race', everything to do with their ability to communicate in a way I could understand. If there are two people of equal technical ability, and one I (and the team) can understand without hesitation, and one who has trouble communicating, because of an accent, and they're both white, and we choose the one without the accent... are we racist? No.

Fortunately, EEOC considers national origin equally important to protect, and 'accentist' is likely adjacent enough that your lawyers will not support you going there.

Someone from deep rural alabama vs someone from illinois - they're both from the same country. both 'white', both have same qualifications. one has a deep accent that is hard to understand, one doesn't. Please define how making a decision based on accent would be 'racist' (by any EEOC definition).

Cursory research suggests that you would likely be liable for excluding an "ethnic group" if you refused to hire people with southern accent; "southerner" is an actual example I found in USG hiring guides.

interesting, but not useful to my scenario.

again, if you have 2 candidates that have equal background, skills, etc, you have to make a choice if you can only hire one. it seems that any decision you make could be challenged on some point.

The 'alabama' accent might just be an accent they have, and they're not from alabama. But they still have an accent that is difficult for people to work with. If you have another candidate of equal experience and credentials, but who is easier to understand... do you hire the person who is harder to understand precisely because you might get sued otherwise?

> Accent varies by ethnicity and ethnicity is a proxy for race

Accent varies by location, not ethnicity. My Scottish ancestry does not in any way help my understand a thick Glaswegian accent but if we took a kid from China and bought them up in Glasgow they'd have the same accent as everyone else.

Location isn't a great proxy for race.

> it's part laziness and part racism

This is not a fair summary. I have several friends (especially online, who I communicate with via asynchronous email/chat) who are technically competent and lovely people.... but who I would not ever want to have as an in-person lecturer/teacher, because their accents are extremely difficult for me to follow. In spoken communication one or both of us have to constantly repeat ourselves, idioms differ between us and sometimes intended meaning is severely misunderstood, and overall communication is slow and difficult on both sides. In some cases my friend speaks English as a second or third language and feels awkward/uncomfortable speaking English face to face at normal conversational speed.

In a classroom setting, there is usually some technically difficult material to be learning, and often a course is structured so that the first concepts taught are essential building blocks on which the rest of the course relies. Trying to simultaneously decipher a thick accent and learn demanding technical material will put a student behind their peers who are taught by someone easy to comprehend, and might make the course dramatically more difficult.

It is neither “racism” nor “laziness” to want a teacher who is a fluent speaker of a form of speech you can easily understand. Just simple pragmatism.

> I've seen this a million times teaching students.

If most of your students are complaining about your accent, is it really a fair to conclude that they are all just lazy racists? Maybe you could work harder on developing an accent comprehensible to natives in the place where you are teaching.

The truth is it's part laziness and part racism.

I would lengthen that list to part inexperience, part laziness, part racism, and part a real problem.

College students are one of the stereotypically worst groups for this. They often have only really experienced one accent and racial group - their own. And suddenly they are being taught by people from another country with strong accents. So inexperienced and lazy are likely, while racist is not rare.

By contrast in tech, you have to work with people who have a variety of accents of different kinds and strengths. And frequently this happens over the phone with outsourced teams. The variety is astounding. For example I'm dealing with countries from Paraguay to Vietnam in my co-workers, and regularly deal with have outsourced contractors from India to Poland. I don't have trouble with any of their accents.

When experienced tech people like me give up on trying to understand you, it is unlikely to be inexperience, doubtful to be laziness, and probably isn't racism. Which means that you likely have a real problem.

Accent is the hardest part of a language to acquire. That person may take 3 months to adjust, or maybe much more. In the meantime that accent hinders communication, which is a bad thing.

Accent is part of fluency, and fluency is a skill, like coding or graphic design. Hiring someone without an important skill in hope he will acquire it later is a risk you may not want to take.

> why pass on a good candidate for this reason?

Given two people otherwise capable of doing the job, one you can easily communicate with, and one you cannot, which would you choose?

If it's just a matter of accent, then I'll decide not to give a fuck about that and hire the very best person. I have done this on two occasions that immediately come to mind (almost certainly others also) and it was obviously the correct decision.

Why the hell do you care about accent? If you talk to someone every day, they can have a fucking martian accent and you'll learn to understand it.

I've had projects where I've been able to understand everyone just fine, but the non-native speakers who were from different countries couldn't understand each other. Luckily, it was a minor inconvenience that all of us could easily handle, but I could see this being a valid reason in some circumstances (e.g. jobs that require a lot of time spent on the phone)

Just say he's no fit for the organization. Safe and at least partially fair for the candidates.

Interestingly, if they give concrete technical reasons why people weren't hired in most cases, then telling some people that they were "not a fit" could actually raise a red flag.

Basically, it tells them that there was no technical reason not to hire them, which raises the question of whether it was something illegitimate.

It may raise the question, but it’s not evidence, and it’s not actionable. No lawyer would ever take a case based on a lack of interview feedback, or “not a fit.”

No, but it might prompt someone to dig deeper. I think companies are starting to treat the hiring process as a security risk and are trying to minimize the attack-surface.

To anyone who’s try “digging deeper” in a situation like this, I say good luck.

For most of us, dealing with this kind of issue is a hassle, even when there's no actual legal danger. Substitute "bad PR" with "litigation risk" if you prefer.

The point is: there exists an incentive to think in terms of information leakage, and it's a very unfortunate state of affairs because everybody loses.

This gets right to the heart of the issue, IMHO. Hiring has become such a litigation-prone process that companies are now incentivized to leak as little information as possible.

It's sad because nobody wins -- companies get sued for petty nothings, candidates who have been wronged have no recourse, and candidates aren't given the feedback they need to improve themselves.

Our startup isn't hiring yet, but I must confess this kind of thing has me worried...

Hiring has become such a litigation-prone

Where? I've never seen anyone sue a company for not hiring them, and no company I've ever worked at has been sued for not hiring someone. If it was litigation-prone, I'd expect to see some litigation. I don't work in the US; maybe this is a weird US thing? Maybe people who do work in the US can give us some numbers? What proportion of companies one has worked for have been sued for not hiring someone? Or in a given year, what proportion of rejected interview candidates come back to sue the company?

It is a weird US thing, and nobody can give you numbers because the existence and outcome of these lawsuits is never talked about (most are settled out of court).

But talk to anyone in HR and you'll hear, "The stories that I've seen, if only I could tell you!"

So are they real? No numbers, no talking about it, just people in HR saying "No no, I promise you, they are real!"

If everyone is so cautious about hiring for fear of litigation, do they still happen? Since everyone is so cautious.

They are real. In some organizations more frequently than others.

Anecdotally, call centers seem to be a particularly good source of interesting HR lawsuits.

> I've never seen anyone sue a company for not hiring them

http://www.dailymail.co.uk/news/article-6067331/Swedish-Musl...

Well, now I've seen one. Such a big deal that it made a national newspaper. That suggests it's not very common.

Well that sucks for the person if they were rejected because of their accent and no feedback was given. All that hard work in preparing for interviews and you don't even know for sure why they didn't pick you.

I partly agree and yet... surely the candidate noticed that communicating was difficult?

If they're never getting the feedback that they're hard to follow, maybe they don't?

There is a point where you realise you don't understand, and are too embarrassed to ask someone to repeat for the fourth time. So you kinda take a guess and move on to something else.

It may not be obvious to the other party that you didn't understand depending how well you covered.

This is a small part of why anti-discrimination laws are harmful. Companies can't be honest because they need to cover for potential discrimination lawsuits.

If you go a step further, a truly racist company is never going to hire someone of a race they look down on, but they can't put anything on a job description about it, so they just end up wasting a minority's time.

>they just end up wasting a minority's time.

They also waste their own time, so there's some good coming out of it.

But I wouldn't say unintelligible accent is racism. I've met some unintelligible people that were born and raised where I live.

An accent is also something you can change (even though it's hard). So it would be really valuable feedback to the person who's not getting it.

_You_ wouldn't say an unintelligible accent is racism, but a civil court might. It's valuable feedback for the candidate, but it's high risk (high magnitude, even if chance of happening is low) and near-zero reward for the company.

Yes, I completely agree with that. In the end as an interviewee you have to learn to read body language and subtext and see where (and if) it goes south in your interviews.

I can usually predict quite well who will hire me based on my interview experience, but I've been surprised some times where I got hired after I thought I failed completely at the interview. This may sound weird, but in that case I usually assume the company couldn't find anybody else, which is also a red flag for me.

Being a non-native English speaker (edit: my native language is French) leaving in South-East Asian I can attest to two things:

- peoples accent improves in the first months of them practicing (with you).

- my understanding of non-native English speaker (Thai, Japanese, Indian, Chinese, etc) improved in weeks of exposure.

So I don't think anti-discrimination laws are harmful. The situation may not be as confortable for a few weeks but eventually it does not get on the way of productivity.

edit: added my native language, French

I am wondering why are the technical interviews are put before the personal interviews then? If none of the technical skills matter in light of the soft skills because some candidate has a hair color or accent which bothers a team member, why bother with checking technicality in the first place?

Depends on what you want to optimize for. It may be that the technical filter is the finer one, so start there and have fewer in the second round. It could also be that technical is more important, as no amount of soft skills substitute for technical ability in some roles. Also keep in mind that we're usually evaluating soft skills as a single dimension, or sometimes even just a byproduct, in what is actually a broader behavioral interview.

Other companies effectively outsource the first stage of their hiring to Triplebyte. These companies have much more agreement on the "hard" skills than the "soft" skills, and also have an easier time trusting Triplebyte to evaluate the former. A candidate who passes a general technical interview could be a potential culture fit for many companies.

Because most people applying for programming jobs can’t write fizzbuzz and it’s easier to verify than “culture fit”

Honestly, the fireworks guy seems pretty fun.

Curious what the lunch argument was too

The accent thing could be viewed as not hiring someone on the grounds of disability. If you can't understand how someone speaks, you can always communicate via Slack or email.

The lunch one - if the argument was not related to work, then I can't see an issue. You don't have to talk personal stuff to the co-workers, so unless the conversation wasn't mandatory and wasn't initiated by the candidate, then no issue here.

Only really valid cause is the firework.

When I was a hiring manager, I used to always include a personal note that included suggestions and constructive criticism for the candidate. In a couple of cases, those people replied to me, demonstrated some actions towards those goals, and I hired them later, when I had more available positions.

And those that I didn't hire, I encountered them at other companies. It was flattering to hear them say they remembered me and had a positive impression of our recruiting process, even though they were rejected.

I've always believed that the recruiting process is a great way to sell one's company. Even if the candidate isn't a good match, that candidate may recommend peers to the role if they have a positive experience with you.

I appreciate people like you but unfortunately most companies' policy mandates not talking about the reasons due to some sort of legal risk of law suit.

I interviewed for an internal position once and got similar feedback, by phone, from the HR person. She was on the phone with me for about an hour and, in all honesty, that rejection phone call made that one of the best interviews I've ever had.

I didn't get that job, but it gave me a lot of constructive advice and I ended up getting the next one I interviewed for.

That's nice and helpful, especially since tech interviews can be taxing. Sounds like they actually liked you and probably would've hired you under different circumstances.

I had terribly frustrating experiences interviewing. Mostly just taking a bunch of tests and interviewing two, three times, and not hearing back for months. What sticks out was a post-interview for a large company that aggressively recruited from my uni. When I asked how I could have improved the answer was, "You ask too many specific questions about the company and software platform. Be more focused on the interviews." "For example?" "It isn't appropriate to discuss how wages are adjusted according to location or salaried overtime policies or the tech stack... in an interview..." I took that one as the, "not gonna drink the Kool Aid." box being checked. Dodged a bullet there, though, seeing as her answers did not exactly inspire faith.

You'd probabbly apply again sometime right?

If my circumstances were the same I probably would, but circumstances have changed enough that I wouldn't apply for that type of position.

I wish more people did this, but IMO this is very rare.

> In a couple of cases, those people replied to me, demonstrated some actions towards those goals, and I hired them later, when I had more available positions.

I've seen this being automated in enterprise recruiting systems as "Candidate Relationship Management" using terms like "silver medalist" to identify and re-engage folks who didn't quite make the cut for positions they interviewed for but may be good fits for other open positions or for future pre-vetted candidates.

I applaud you for making things more human!

I once sent 49 rejection letters (for an internship!): « Here are statistics about the 50 applications I’ve received. » Received big thanks from at least 50% of them.

Last internship position I opened, I received more than 100 applications. Going through all of them and replying (even with a standard template) was grueling. I did give feedback to everyone we interviewed, though.

A good 50% of the resumes were flat out wrong for the position or missing critical information. A standard rejection letter with stats like these and basic recommendations might be useful in the future. It might also trigger a lot of self-righteous justification though... Don’t know if I’m up to receiving another 100 re-submissions with cooked CVs.

>When I was a hiring manager, I used to always include a personal note that included suggestions and constructive criticism for the candidate

That's seriously awesome. I would so love that. For me most of the time they just stop responding, even right after "I'll get back to you by the end of the day!" type conversations.

I don't care if it is a no, I just want to get a message, and feedback would be even better.

One company I wanted to work at recently did exactly what I described .... all hyped up meeting, we all got along, good stuff, we'll get back to you by the end of the day. Then nothing, I called a bit later, emailed, nothing.... My impression was pretty negative.

I have a job now, I'm excited to start it, that other company, very negative feelings towards that other company ... if they just sent an email even to say no I'd feel better about it, but nothing.

If you/your company doesn't have a policy of sending personal feedback please consider doing this at least for junior people. Volunteer your after work time if needed.

Trying to find the first job is extremely stressful process. A junior person has no notion of his worth on the market. Each rejection even if only by a lack of any response ("I'm sorry, I'm afraid we are looking for a bit more experienced person" would suffice) can be like a kick on the face when you're just barely learning to walk and most likely is a burned bridge.

I've mentored my girlfriend for 3 years from almost 0 to getting her first job in a company run by a React Native core developer. She had the skill, great attitude, really solid work ethic and very analytical thinking. It'd trust her more with any task than significant number of my past and current senior coworkers. It's hard to prove and no one expects that so naturally her applications had been ignored or rejected. With each one I saw her confidence, self-esteem and enthusiasm crumb. With each positive reply/invitation she was invigorated until the next step came. I'm pretty sure for some the roller-coaster or even worse, being rejected over and over again can be a life defining experience.

Any reply is great, personal is even better. If you spend time describing what was missing from the expectations of your company (don't say "You don't know enough", say "We need someone with more knowledge") and sincerely wish the person well you can be sure they'll be grateful, remember you, work on the gaps and who knows... maybe some day become part of your team.

Please feel free to reach out if you want some example for inspiration.

Edit: Please don't do that against the policy of your company. But if there are no reasons against just ask if you could provide some feedback and resources for the rejection letter.

Our HR asked me to personally call people and thank them for their declined application.

But at the same time requested to not give any feedback because of fear from litigation. Sad world.

If someone told me that in my country (or maybe just outside US) I would simply not believe them at first. It might just be the choice of companies I've worked with though.

It is sad indeed.

I would have simply ignored that HR person and given honest but polite feedback.

You're willing to bet your own employment on that? We'd all love to live in a world of butterflies and sugar plums, but risking your own for that is silly don't you think?

Absolutely I would. Employees create the culture too. If you cant push back against stupid policies then it is probably good to be pushed out and move on. Plus any environment that has a policy like that is probably a very sterile workplace.

Off topic, but I find it amusing that we all do in fact live in a world with both butterflies and sugar plums. They are both very cheap and plentiful as well.

Managerial CYA, and fear of the potential for litigation are crippling corporations more that I think we'd like to admit. Financial risk is something people seem comfortable accepting, but the specter of unknowable legal risk cause so many management anti patterns and so much passive aggressive behavior is it incredible.

As a relatively junior person in management, it is amazing the kind of phantom fears I've been cautioned against. Some of which don't even have any legal precedent at all!

I think a lot of it is trotted out as managerial "emergency hypothesis" for why someone doesn't want to do something, and so invents some plausible legal risk to justify their decision. But, honestly, it can't be only that.

For a swath of business responsibilities, this "phantom legal risk" is the Most Available Excuse (TM).

We see Most Available Excuses in product feedback ("it's too hard to use" is easier to say than "I didn't see how this would help me accomplish anything I actually care about"), in social engagements ("sorry, too busy this week"), and many other areas.

I'm a natural skeptic so I maintain a mental set of Most Available Excuses, and when I hear one I treat it as a dodge, not an answer. Why don't they want to do it? How might I make them more comfortable with me so they can explain how they really feel?

Why don't they want to do it? How might I make them more comfortable with me so they can explain how they really feel?

I'd be very cautious with this approach. Politeness is an extremely important social defense mechanism for most people. By ignoring the standard polite response and trying to get at the truth you're undermining a person's attempt to save face. By doing so, you're attacking their autonomy and agency as a human being.

I'm not suggesting directly asking these questions of the other person. I'm suggesting these as topics for you to think about if you're getting the polite excuse and want the actual reason. To get that you have to actually make them more comfortable; calling them out on a polite lie obviously isn't going to do that.

> fear of the potential for litigation are crippling corporations more that I think we'd like to admit.

Sure, I sometimes see it that way until I'm in the seat of a employer. This isn't a one-sided "corporations suck" because guess who's doing the suing in these cases? That's right, the potential employee. So where is the onus in this negative externality? I'd argue both sides.

Agree. I remember having applied to McKinsey many years ago as a graduate. I got rejected after the first round of interview, but one of the interviewers would call me to explain their rationale. I was very grateful but I can imagine that it must be painful when the candidate doesn't react well or sees that as an opportunity to put the foot back in the door.

I've rejected dozens of people right after face to face coding session of a simple task (third meeting, first technical) explaining the reasons, providing them some guidance on what to tackle next, if I saw hope invite them to try again once they feel they filled the gaps or at least describe the progress and ask if we think it's enough to try and/or what could be next.

I've most likely never had a person who left without a handshake with a sincere smile on his/her face and most of them expressed their gratitude.

Sometimes you have to reject a person on what you feel is a gut feeling. It's because over time you developed an intuition which is picking small details in a less conscious manner. In the end there are some reasons your intuition is shaped that way not the other and you can find something that presented within the context of your company and expectations will resonate with the candidate and he won't feel like he's been scammed.

Having to give that kind of feedback just sounds horribly draining to me. I know there are people who would accept it. There are people it would really help.

Some would already know it and just say ‘thanks’.

But the people who argue with you that you’re wrong, or they need another try, or ‘I forgot to mention X’, or ‘you just hate me because Y’... the people who feel hopeless and you’re just ‘confirming’ their fears (even if they applied for something way outside their qualifications) or falling apart over it.

I would never want having to deal with that be a big part of my job.

> If you/your company doesn't have a policy of sending personal feedback please consider doing this at least for junior people.

If you want to keep your job, don't follow this advice. Honestly, I would love nothing more than giving junior people (all people in fact) feedback on why they didn't get the job, but people will sue at even the slightest hint of any type of potentially litigious situation. It's even worse when the person is in a position of desperation ("I can't pay rent because I can't find a job...oh what this lawyer is going to take my case on a performance basis...heck ya, let's sue those assholes!"). Most of these cases get settled because no one wants to deal with them and it's easier to just pay the problem to go away, so they're easy wins.

Seriously, most good honest HR people WANT to give rejected candidates feedback, but asking them to benevolently provide feedback at the risk of their own job won't earn you many friends.

I didn't say to do that against the policy. What I meant was if your company simply doesn't have a habit of doing it just say: "Hey, can I write some feedback and provide some resources to that candidate in your rejection message?".

Edit: My intuition is most companies don't provide the feedback because simply they don't see a value in the time spent or simply never really considered that as there are always other things to do than think about people you'll probably never meet again.

> I didn't say to do that against the policy.

And I didn't say anything about this having to do with policies of companies. Regardless of whether you have policies in place or not, doing what you suggested without any counsel is a very dangerous way of losing your job. Companies will make it very easy to fire a person who costs them a lawsuit (and the subsequent negative PR).

> My intuition is most companies don't provide the feedback

Your intuition is probably right, but it doesn't mean that people who DO want to give feedback should all of the sudden ignore sound advice. Bad HR teams who don't want to give feedback will always use legality as a shield for an excuse, but that doesn't mean that good HR teams who are also taking legal advice are not interested in doing so. As many people have cited in this thread - the long term effects of giving feedback to rejected candidates (they tell their friends, they come back later, etc) are numerous, but the downside risk makes it very difficult for any HR team to make this investment.

We do agree 100%. :)

Why not make candidates sign a non-liability agreement to receive feedback? Of course, choosing to ask for such feedback would be optional - but if you want it, sign the form so you agree you won't sue. Most people would find this information quite valuable to correct their mistakes for next time. It makes the whole process much more efficient for all parties if there's quick, specific feedback.

You can't absolve a company from liability for US labor laws. So even after you sign the non-liability agreement, you can still sue. It's not a real shield for the company.

I once got a detailed, feedback-driven rejection email, stating very clearly and professionally where I shined in my interview, and where I didn't. I was so appreciative of the message that I made sure to follow up with the manager working on my application and thanked them.

9 months later, I found myself in a bad management situation at another company, thinking about looking for another gig when the company that rejected me reached out asking if I'd be willing to come back and interview again. I did and accepted the offer.

By giving good and candid feedback, they wound up saving months of searching for a new dev when they reached back out knowing I was a good fit for what they needed at that time. I was essentially a lead they'd already warmed months prior. It made me wonder why more companies don't think of this.

When someone can’t answer an interview question about relational databases, it might be that they don’t know anything about relational databases.

I thought you all were better than this. Why are you asking questions about relational databases? Why not just have candidates accomplish the thing you're assessing with an actual relational database? I know you're work-sample-literate! But if your feedback emphasizes communication, doesn't that imply a lot about your process is subjective? After all, and to extend an analysis used in this blog post: it could be that the candidates couldn't effectively communicate knowledge about RDMBS's. Or, it could be that the interviewer wasn't effectively listening to what the candidate was saying.

Because sometimes understanding the base concept is important. I cannot possibly ask you to solve 1,000 scenarios in 45 minutes. But if you get the basic idea of how the concept works, I can be sure that when you encounter scenario #945, you'll have the basic grasp on the concept to at least know where to look, and when scenario #487 comes up, you'll know the basic idea of how to handle it.

Asking you just to do one thing in an interview risks accidentally hitting one of the ten-twenty things you do know how to do, leaving me with no proof that you can solve the other 980-ish possible problems.

Isn't a lot of the job of software engineering to quickly and concisely communicate complicated concepts? Might this actually be an accurate work sample? How else might you measure something like this?

Also the next few lines kinda address what you are saying:

> It also might be that they know them inside-and-out but aren’t used to answering questions on the fly, or that our question didn’t use the vocabulary they’re familiar with, or that they misheard the question and answered a different one. It made quite a difference just to phrase the feedback in a way which acknowledged all those possibilities.

>Isn't a lot of the job of software engineering to quickly and concisely communicate complicated concepts?

No, I write code daily but I might have to distill down technical concepts once a week or so (usually not even that much) and even then if I happen to be the only one who can distill it down.

If your devs are often explaining basic stuff like 'what is a relational database?', you need to hire someone specifically to do that. It's not a good use of time especially when they can go google/wikipedia those concepts and figure it out themselves.

To be clear, we don't ask candidates 'what is a relational database', and I'm totally in agreement that that's a weak interview question.

Sure, people don't need to explain RDBMS frequently, but that code you wrote last week? Or that reason you can't do exactly what the PM wants? YMMV but I spend a LOT of time communicating difficult concepts to other engineers (not only mentoring juniors, but also just doing hand-offs and stuff to others), to product managers, sales people etc.

Some engineers really do sit in a quiet room all day writing code, but my experience has been that it is an extremely communication-centric job.

Either way: if you do work in the kind of environment where you need to work with other engs and teams frequently you do need to test communication skills, and simply coding is not always sufficient.

>YMMV but I spend a LOT of time communicating difficult concepts to other engineers (not only mentoring juniors, but also just doing hand-offs and stuff to others), to product managers, sales people etc.

This is a good use of time though. You won't find this on wikipedia, obviously, and is not considered basic technical information.

This is what I want to spend my time explaining.

If you can’t communicate ideas and basic concepts to non technical people, you will both limit your career opportunities and not be able to get your ideas implemented while someone with worse ideas will.

Developers underestimate the amount of influence you can have just by being able to communicate effectively.

If they come to me for basic stuff, I tell them to go research it on their own. I'm not going to regurgitate wikipedia if they haven't put in some effort.

At some point, we need to start demanding basic technical competence from the people around software developers.

Otherwise, people will just be interrupting you all day and how much have we collectively written about that problem?

If they come to me for basic stuff, I tell them to go research it on their own. I'm not going to regurgitate wikipedia if they haven't put in some effort.

And that’s why developers don’t get ahead....

There are basically “three levers of power” in an organization - relationship, expert, and role in that order.

The developer who knows how to build relationships is the one that doesn’t get his silly bug put on blast by the QA and gets an unofficial Skype message and doesn’t get official very visible tickets when something blows up in production and gets a quick Slack message so that he can be prepared to explain it.

It’s also the different between a developer who has to submit a ticket to netops and wait three days for a VM and one that can send an email, get it set up within 30 minutes and then create the ticket as a formality.

That's just silly, you can build relationships in other ways.

If you want to be the go-to guy/gal that gets constantly interrupted with this sort of stuff, your time won't be respected.

Plus, you're teaching them to go research things on their own. Why is that a bad thing?

Once you get to a certain level in your career, part of your job is to be the go to person that explains things, mentors, spends way too much time in meetings and just greases the wheels. The heads down developer is not seen as the multiplier like the team lead/architect is and they get paid accordingly. I have my office days where I expect to get interrupted and my work from home days where I don’t.

No one gets promoted by constantly telling coworkers and management to RTFM.

>Once you get to a certain level in your career, part of your job is to be the go to person that explains things, mentor, spend way too much time in meetings and just grease the wheels. The heads down developer is not seen as the multiplier like the team lead/architect is and they get paid accordingly.

Great. That's exactly what I said in my original post -- hire someone specifically to do that. Problem solved. Now your junior/mids don't have to explain that. But that's not the career trajectory of every developer, let's be honest.

If someone's going to deny me a promotion for linking a wikipedia page that answers a basic question and completely ignore my technical contributions, I absolutely do not trust that place has the best interests of its developers in mind and is likely driven more by politics than anything else.

No place has the "best interest of its developers in mind". That's true for any industry. It's a lot easier to replace the on the floor factory worker (i.e. the developer) than the foreman (the architect) and they get paid accordingly.

Don't get caught up on the title, role power is the least effective type of power in an organization. If you leverage relationships and can be seen as the expert, you can easily punch above your weight.

Why do I need to punch above my weight? So I can finally tell people 'no' when they try to take my time away with stuff that they can fix themselves?

I think it's clear we have two very different motivating factors in careers. You want to climb the corporate ladder and get power and influence, and I'm content building things.

That's just the point I've been making "climbing the corporate ladder" is about gaining role power. Role power is the least effective method of getting things done in an organization.

I wanted to "build things" my entire career and was stymied by management and team leads who I couldn't convince to see my "vision", net ops and dev ops who made me go through mounds of red tape to get anything done and coworkers who had their own agendas and wanted to get noticed and get the prime projects just as much as I did. It led to a lot of frustration.

The best way to be able to "build things" the way you want is to have the influence to do so by getting people on your side through relationship building and getting people to trust your expertise.

I like to "build things" too and have no desire for management. But, the way to stand out and make more money than the average, heads down developer is to have soft skills.

What you say makes complete sense. It is correct as per my observations. However, one big issue is that sociopaths (manipulators, idea\effort-appropriators...) have an edge. Also, such people accumulate and ruin workplace.

If you can't concisely communicate complicated concepts, you're creating technical debt every time you hand off a project.

If you come to me for basic stuff every time without effort on your own part, you're not likely a good fit for the team.

Once a week (or even every two weeks) is still frequent enough to count as a core job responsibility. And the raw frequency understates its significance, considering that it can be a blocker for other employees' contributions.

Now, you're right, the technical distillation is not going to be on the level of "explain relational databases to a Joe off the street starting from square one", but it's effectively the same as the skill of "demystifying arbitrary misunderstandings and knowledge gaps other have", which is important.

"or that our question didn’t use the vocabulary they’re familiar with"

I lost out a job interview in 1997 because I wasn't familiar with "state management" for websites. The guy was pretty insistent I needed to know what "state management" was. I'd already sent over a project using session management (and he'd created an account, logged in, I sent him the code, etc), but... I didn't know what 'state management' was, so I was passed over. I wasn't strong enough on the phone (and was in a different country at the time - was worrying about the long distance charges!) and... it fell apart. I was essentially a perfect fit (had had an interview before - this was second interview with someone else), but I choked on that phrase, and they passed me by...

Maybe good oral communication skills are part of these particular requirements? We don't know the details of the interview. But I don't understand why it should be wrong to ask a candidate a question that he should be able to answer and see how he reacts.

For some jobs it may even be appropriate to ask questions that the candidate cannot answer and see the reaction. Does he admit that he does not know? How does he phrase it? Is he making things up to cover for his lack of knowledge? And so on.

I have been doing mysql database type things for 15 years solid. Once during a job interview at digg.com, someone [ok ok doxx removed] asked: "what is a having statement in sql?". I jumped in explained how you can filter aggregated sets performed by a 'group by' and rambled on and on. He stopped me and said, "You can use a having statement without a group by, are you sure you know how they work." I have never seen this or done this in practice, so I just stood there stumped. He rolled his eyes and ended the interview. 4 hours of an amazing interview going well: ruined. At least this guy went on to ruin digg.com. "Let's just re-write everything over again better" kinda guy.

[No longer applicable]

Naming a company and recounting an interview experience is not doxxing.

He named a specific person before the edit, which is a bit different. Nothing wrong with naming/shaming digg.com, though.

Naming a specific person is not nice, but still not "doxxing."

That's exactly what doxxing is.(Paraphrasing here) "This guy was really shitty in my job interview. Here's their LinkedIn page."

Seemed pretty cut and dry to me. What about it disqualified it as a not-doxxing situation?

I thought doxxing was the act of publishing the true identity of a person which was only known by their online handle before.

"Doxxing", in the original sense, involves publishing more private info, info like address, home phone, cell phone, SSN, etc. A link to someones public LinkedIn page is not a "dox."

That is an absurd definition of doxxing. Reporting the names of you have had in-person interactions with, in cases where it would not expose someone's pseudonym, is in no way, shape, or form doxxing.

Don't censor others.

If I understand correctly from this post on dba [1], HAVING without GROUP BY would have the same effect as WHERE. Seems like they were just being pedantic for no good reason.

[1] https://dba.stackexchange.com/questions/57445/use-of-having-...

If one of the columns you're SELECTing has some sort of complicated expression in it (e.g. `UNIX_TIME(colA) - UNIX_TIME(colB) AS duration`), I think you can refer to that column by name in HAVING, but not in WHERE. It's a pretty niche thing though; I can't remember if I've ever actually used it.

I believe you’re correct.

However because HAVING takes place after all the results are fetched and processed (so it can do GROUP BYs) HAVING can’t use indexes.

So while the two will give you identical results if you’re not using a GROUP BY, the HAVING version could be thousands of times slower. Or worse.

How would this differ from contains?

honestly who cares? there is no sane reason to use having without group by.

Do you realize you dodged a bullet at that moment? That was a classic case of "smartest-guy-in-the-room" syndrome: from your description, he wasn't there to interview you, he was there to show off and stroke his own ego.

Be glad you didn't get that job, because that would have been the future of your days at work -- constantly listening to Mr. Smartypants compensate for his own sense of inadequacy, where every different opinion is treated as a personal insult or a challenge. No thanks. That personality type is infectious (not in a good way) and it damages an organization.

Hm, I'm honest: If I get along well with an interviewee, I might throw technical oddballs at them like that. I wouldn't have known that specific one.

But at that point, I'm more interested in their personal reaction. Pondering, and/or asking "Why the fuck do you even do that!" would've been fine there to me.

This person probably wanted you to say that there might be a performance problem in filtering a result set using HAVING, instead if selecting rows using WHERE, if the query optimizer fails to see the equivalence. And the only reason why they knew was because they fixed that very same problem one week before, after debugging it for three days, as it is often the case with bad interview questions.

Edit: shouldn't assume gender

Have you ever seen anyone using having in place of where honestly?

I have definitely seen people confuse them, although not in production code.

Imagine a junior developer asking your senior developer a question about how a relational database does something.

There you go, now it's a work-sample for your senior developer.

I suspect a lot of my feeling of whether these people are good or crazy comes down to whether they can contextualize their questions. Most of the questions I get asked are for code I would veto in a PR because there are battle tested alternatives.

I’ve been trying to do something about that when it’s my turn to ask interview questions. For instance, too many front end people struggle with basic data manipulation workflows. I want to virtue signal that it’s better to move this kind of logic to the backend, but I need to test them anyway.

So I create a plausible scenario, maybe this is a POC to see if it’s worth sort or grouping functionality to the backend.

Sure! It's an objective work-sample process if you can say these things about the challenge:

* It's the same for all candidates.

* It captures facets of the work as it is done on the actual job.

* It's objectively evaluated (ideally, it has a rubric established a priori, such that results can be evaluated by someone other than the person who proctors the challenge).

It's possible to devise work-sample challenges that assess communication skills. I have friends who've done it at their companies for customer service and sales roles. I'm saying, the process described in this blog post does not appear to be that.

> Why are you asking questions about relational databases?

Why wouldn't you ask questions about relational databases? I would expect any decent dev to know the fundamentals of relational databases.

I think you're missing my point. Qualifying candidates based on relational database skill is not a problem; if it's something they'll be expected to do on the job, you should evaluate their ability. I'm saying the kind of Socratic interview alluded to in this article isn't the best way to accomplish that.

  Why not just have candidates accomplish the thing you're
  assessing with an actual relational database?

My employer interviews like this, and I can tell you one reason it's not very common: It's a pain in the ass.

After all, it'd be unfair to judge someone on a platform they weren't familiar with - so now you gotta maintain a fleet of laptops with a really wide range of tools. And these have to sorta float outside the usual IT management system because they aren't really issued to a single person, and you gotta be online enough that people can google stuff, and you can't have hiring managers let other people use their login, that'd be bad security practice. And if you didn't confirm in advance what platform the candidate wanted to be tested on, you gotta haul three laptops to the interview. Oh, they're pretty good developer laptops and one went missing? We really ought to have people sign those out...

And even after that, you _still_ have to apply subjective measures like "were their variable names clear?" and judge them on communication - like if they see an opportunity to refactor the code for clarity, but they say they're focusing on completing the task before spending time on that.

I'm not saying it's a bad thing to do this, just that I can understand why many companies don't.

It is harder to build a work-sample regimen than to just send candidates to interviewers, sure. But then, the point of Triplebyte is that they're eating all that work for you.

Regarding "fleets of laptops" and environments and all that jazz: these seem like unforced obstacles. Just have the candidates use their own machines. Here's a crazy idea: have them use their own offices/couches, too.

Regarding security practices... come on. We have an interview process that involves giving remote developers read/write access to an entire AWS environment. These are simple engineering problems. If they're the only thing stopping you from having a better interviewing process, and you hire regularly, just go solve the problems.

  Just have the candidates use their own machines.

We tried inviting candidates to bring their own laptops, and it turns out often they didn't _have_ laptops - or we'd tell them there was a Java-based test and (perhaps due to a miscommunication or because this is an uncommon interview practice) they'd arrive with a laptop without a working Java VM or compiler.

Needless to say, you can't objectively compare two candidates' progress if one of them spends half the interview trying to get their environment set up!

  Regarding security practices... come on. [...]
  These are simple engineering problems.

Perhaps I wasn't clear: My employer is a medium-sized company, and consequentially IT security is actually a complex political problem rather than a simple engineering problem.

You've also made a pretty big shift in the goalposts there, from asking "why don't companies have candidates accomplish the thing they're assessing?" to asking "why don't companies have candidates accomplish the thing they're assessing, and perform remote video interviews, and have the ability to give spin up clean AWS environments and give remote semi-trusted interview candidates access to them?"

If you insist on doing the interview in person, why not just tell them ahead of time what their environment needs to do when they get there? Give people instructions and a script (formal or just a numbered list of steps) that determines they're ready to go.

Better yet, just don't make people do that stuff in your office.

Why bother videorecording interviews at all? I'd have problems writing a line of code with someone breathing down my neck. If you did it to me on the job, I'd chase you out of the room. I feel like a lot of these problems are, like I said, unforced.

Agree to disagree about the degree of difficulty of getting clean environments to candidates. You're either serious about recruiting as an engineering problem or you're not. "Not" is fine, but then don't pretend like there's some kind of rigor in deciding which corners you're willing to cut.

I'm not making this stuff up; this is how we've been hiring people for about 10 years now, and every time I hear someone explain how challenging or untenable our process is, I keep wondering, "what am I doing wrong to make this work so well for us?"

  Why bother videorecording interviews at all?

We don't record interviews. By "remote video interviews" I meant "remote interviews by videoconferencing such as Skype or Google Hangouts" which I assumed was what you meant when you proposed candidates use their own office or couch.

  why not just tell them ahead of time what their
  environment needs to do when they get there?

We did this, including a github test project they could check out and build to make sure everything was working. Still, about 50% of candidates arrived without a working environment.

We chose to supply a known-good laptop instead of rejecting such candidates instantly when they've spent time travelling to us etc.

  every time I hear someone explain how challenging or
  untenable our process is, I keep wondering, "what am
  I doing wrong to make this work so well for us?"

I'm not saying your process is challenging for _you_ given _your_ situation; I'm sure it works very well for you! I'm saying it's challenging for _us_ given _our_ situation :)

Maybe I'm being unclear. I'm asking: why does there need to be video or telephonic oversight of any sort for a work-sample challenge? Why are you assigning yourself that problem? We've never done that and never had a problem.

Ah, you mean a take-home test?

Some people involved in our hiring process don't like them, they say experienced candidates stop responding when sent take-home tests. Their theory is employed people with families don't have the time - although we don't have hard empirical evidence for this for obvious reasons.

People don't do take-home tests because companies give them in addition to interview loops. I'm saying, just do the at-home test, and cut out the interviews.

> Needless to say, you can't objectively compare two candidates' progress if one of them spends half the interview trying to get their environment set up!

If most of the issues revolve around having roughly the same environment for candidates, just create ready to go VM images, for example VirtualBox, and share that with them. Or use a cloud desktop VM.

All of which make it easier for someone to succeed.

> Just have the candidates use their own machines

I agree with you generally, but you'd better have loaner machines ready. Not every candidate currently has a working, dev-capable laptop. Economic bias. (Hell, my current laptop is only 70% functional because I can't decide if I want to repair or replace it.)

If economic bias is your concern, then you shouldn't be asking people to travel onsite for a tech-out interview; you should be doing everything you can to make tech qualification remote, so that by the time you need to call them to your office, you and the candidate have a pretty good idea it's worth disrupting their work and home life with the trip.

After hundreds of interviews (I have no idea; lots, over 10 years of almost continuous hiring) I've never run into a candidate that couldn't do a tech challenge remotely.

And I don't know that that's better than "walk me through the query you'd use to do X". Because the reality is they may need to look up the exact syntax for something, and I can't gauge how much they actually know based on their googling; someone who knows nothing might stumble on a good search and seem to get it really quick, someone who knows all the fundamentals might spend 5 minutes trying to find a keyword that's just slipped his mind ('having', for instance, which I've used maybe...once? :P), who will seem like they know nothing.

Instead, just describe it to me. Best guess it. We'll dive into that.

> I thought you all were better than this. Why are you asking questions about relational databases?

You write about hiring from the perspective of someone with hiring authority. TripleByte doesn't have hiring authority, or even sufficient reputation to get their candidates out of doing another technical interview at the companies to which they apply.

There are two problems you might solve:

- Joe Nerd needs a job. He knows everything about relational databases, but no interviewer has ever noticed this. His limp, effeminate handshake leaves them unimpressed.

- IBM needs a database engineer. They really want to hire someone, but they're having trouble filling the opening; their existing network of friends-of-current-employees is tapped out.

That is to say, you could try to optimize for finding people who will be good employees, and then bully companies into hiring those people, or you could try to optimize for finding people who will pass an existing hiring gauntlet, and then introduce them to companies where the magic will happen naturally.

The first approach solves the candidate's problem and would logically charge fees to the candidate. The second approach solves the company's problem and would logically charge fees to the company. TripleByte wants to get money from companies, and follows the second strategy.

But... they like to send messages as if they were following the first strategy, because that strategy solves the candidate's problem and those messages therefore attract candidates to TripleByte. I don't like this.

My experience with trying this for a year at a previous startup which shall remain nameless is that no matter how I approached candidate qualification, work-sample or interview or ritual chicken sacrifice, I'd still have the same problem of clients rejecting candidates by default. Recruiters mostly all work on your "second" model. So why add crappy tech qualification to your problems? Do at least that right!

According to my mental model of the world, if I'm trying to find people who will pass their interviews at IBM, then the more my qualifying interview looks like IBM's interview, the better I'm doing.

I find it very plausible that your experience ("acceptance rate doesn't seem to change no matter how I personally vet the candidates") is more realistic than my armchair model, but I suspect the model is intuitive to a lot of people and will go a long way toward explaining "why are you asking questions about relational databases?".

You're ignoring the sentence that came immediately after that one:

> It also might be that they know them inside-and-out but aren’t used to answering questions on the fly, or that our question didn’t use the vocabulary they’re familiar with, or that they misheard the question and answered a different one. [...] People are generally open to hearing that, one way or another, they didn’t manage to demonstrate that they understood a topic.

The author is actively acknowledging that being unable to answer a question about RDMSs doesn't mean they don't actually know anything about them.

And the point, I think, stands. An interview isn't a passive process where by some magic algorithm they determine good candidates from bad and the candidate just sits there hoping the right question will be asked. You have to actually communicate to the interviewer your knowledge and experience because they don't know.

No, I get that! I think the author does a good job of implicitly recognizing the weakness of interview processes. I'm really just saying 2 things:

1. They missed a failure mode: in addition to (a) lack of knowledge and (b) lack of communication skills, there is also (c) lack of interviewing skill.

2. It's possible to design an interview process that is resilient to both (b) and (c), and I figured Triplebyte, "who has just one job", would do that.

In addition, on this thread, I've tried (badly) to point out that while (b) is maybe a reasonable thing to check candidates for, it's better to do that explicitly, with an actual test of communication skill, rather than something that can easily get confounded with (a) and (c) (and all the attendant stress that situation generates!).

Thanks for the opportunity to clarify; I'm doing too many things at once today.

> Why are you asking questions about relational databases? Why not just have candidates accomplish the thing you're assessing with an actual relational database?

It's not the same thing. Browse around the various SQL tags in StackOverflow and you'll see plenty of candidates who can "accomplish" things using relational databases yet have positively no idea of how they work.

When shit hits the fan they're asking strangers to optimize their thorny queries. But a modicum of understanding of how a relational database works would have led them to a better way to do things to begin with.

I think the better example of a problem would be asking them how MySQL handles something when you really care about relational databases/SQL in general.

Obviously if the job is highly MySQL specific and they need to know all the quirks that’s relevant.

Are you trying to say that there's some technical detail about solving a problem with an RDBMS that can only be expressed in an interview question? I call "shenanigans" on that. If the most obvious challenges are too easy for candidates to solve, so that they can just copy the answer from Stack Overflow, come up with better questions.

Not saying that at all. Merely that a mere of understanding of a few basics, such as how indexes work and when to use one, goes a long way towards being more effective at interacting with a database.

"Here's some schema information. This complicated query meant to do X is running too slowly. Can you recommend ways to speed things up and explain your reasoning?"

I'd care more if a candidate understands MVCC and transaction isolation levels. (which surprisingly few do)

I've done the TripleByte interview, so the decision to ask questions about relational databases instead of asking for a practical exercise makes sense in context.

It's because you can only fit so much into an already long interview (2 hours). A big chunk of that time is already spent on an exercise about reading/writing/debugging complex code. You can't fit everything in, so database stuff is moved to the non-coding section. Also, the questions aren't "guess the right answer" questions, the interviewer keeps digging with open ended questions to see how deep you can go.

> it could be that the candidates couldn't effectively communicate knowledge about RDMBS's. Or, it could be that the interviewer wasn't effectively listening to what the candidate was saying.

You could certainly get a bad interviewer, but that's a strawman here. If it's not TripleByte judging the candidate's communication skills, then it's the hiring team judging that. The suggestion was about how to give feedback about communication skills. And there are definitely stronger and weaker communicators, and it definitely makes a big difference in day to day work.

Getting rejected at Triplebyte was actually a pretty good investment time wise. Guess the whole thing costed me three hours in total and I got quite a list of things to improve and how. It was clear it was tailored towards the interview not just a larger generic mail.

There are tons of companies that give you a generic email after you completed an IQ test, a questionary, open questions and of course the 8hours+ homework. That's just perverse.

"Try again in three months"

Why? I wouldn't do anything different.

> "Try again in three months"

> Why? I wouldn't do anything different.

But they will. The interview process is stochastic; exactly the same performance from you will lead to different results on different attempts.

> Getting rejected at Triplebyte was actually a pretty good investment time wise. Guess the whole thing costed me three hours in total and I got quite a list of things to improve and how. It was clear it was tailored towards the interview not just a larger generic mail.

For another perspective, here's the entire feedback I got when they rejected my application:

> This was a tough decision and one that we were on the fence about. We really appreciate you taking the time to work on the take home project. We're aware this requires a substantial time commitment and we are really grateful that you invested the time in completing it. We thought you wrote a great, very full featured regular expression matcher. It was especially impressive how much you dug into the academics behind regular languages.

> However we made the decision because we felt that while going through the project together during the interview, we didn't see the fluency of programming when adding to it that we had hoped for. While we specifically designed the take home project track to help overcome the difficulties of coding under time pressure with someone watching, we do still need to see a certain level of programming during the interview. This didn't seem to be the case here, where making changes to the project seemed to be slower and more difficult than we'd have liked.

That's quite a bit less than I got. Perhaps you're just better than me? ;) But I didn't know there might be another take home assignment.

> But they will. The interview process is stochastic; exactly the same performance from you will lead to different results on different attempts.

Yeah I thought about that. But "try x months later" really means that you didn't pass some kind of bar. If I would be one of the five people that passed there would be no problem if I applied next week again, right?

That sounds like a feedback email from a couple years ago - am I right about that? We've definitely gotten better at this over time.

How so?

All the ways I discussed in the article - more nuanced, more thorough, more detailed, more focused on constructive advice you can take to your next interview. Plus, we've just improved our process in general so you aren't tested on skills you don't need. It's easier to give constructive feedback about an interview process you have a lot of confidence in, and much of the work we've put in as a company over the last few years has been designing an interview we think really works.

I'd try it again, what is the process to reapply?

Have you tried the large button their website?

Shoot me an email (kelsey@triplebyte.com) and I'll reset your account.

> It's easier to give constructive feedback about an interview process you have a lot of confidence in, and much of the work we've put in as a company over the last few years has been designing an interview we think really works.

It's hard to take this at face value, as 100% of the TripleByte messaging I've seen since before I received that email focused heavily on how confident they were that their interviews were thorough, high-quality assessments.

I think a lot of the dichotomy here is that nobody really knows what a thorough, high-quality assessment for a software engineer really is. I mean, yes, the standard "work sample über alles" line that comes from research is great, but what really constitutes a valid work sample? How do you set up expectations so the candidate knows where the bar is, much less how to get over it? Things like that.

Edit: You also need to consider that TripleByte's idea of what works is probably different from yours. Their idea is probably more along the lines of "people pass our assessment and get hired." All you really need to do to hit that (not that it's a trivial thing at all), is conduct an assessment that's similar enough to what the hiring companies are doing. And, many of us know that hiring companies frequently aren't very good at interviewing.

So, concretely, how would the process look different to someone who went through the project track 2 years ago?

We don't have the project track anymore, because most candidates weren't willing to do it and it wasn't successfully predicting hires. (There's actually a blog post about this upcoming). We have generalist, front-end and mobile tracks but none of them involve take-home work anymore.No matter which one you do, the feedback will be a lot more thorough than we were able to be two years ago.

Yes, the email is from 2015.

The bigger difference that I see is your statement that "Every few months, I check that all our recommended resources are still up-to-date, available, and free."

In some unfruitful further communication with TripleByte, I asked how I was supposed to improve, given that their feedback seemed to be "we have no qualms with your ability, but we don't think you can pass an interview". They recommended that I sign up on interviewing.io. I did that, and a year later, I was still on the wait list. (I eventually got off the waitlist when complaining about this same sequence of events on HN, and an interviewing.io employee saw the complaint. I don't think that approach scales well.)

Also, this looks like a feedback email after a take home project? I guess the rejection emails after the technical interview should be much more detailed.

While we specifically designed the take home project track to help overcome the difficulties of coding under time pressure with someone watching, we do still need to see a certain level of programming during the interview.

“How to set up a test that works and then completely ruin the results by doing nonsensical things during a dumb ritual that our entire industry seems set on preserving.”

Question for Triplebyte: when’s the last time that a single hour of coding — while being watched — determined whether you’d get to keep your job? Not acquire a job, but keep it.

I’m gusssing “never.” It’s a fake ritual.

I went through TripleByte 2 years ago and got much the same feedback. I was left with the same feelings, on top of the feeling of having wasted a bunch of time. TripleByte only makes sense if it can fast track you to enough companies to make the investment worthwhile. And, even then, I think, at the time (maybe still now), they only let you skip technical phone screens. Never mind that their process is more or less equivalent to the standard tech on-site (which, IMO, means it should at least count for something at the client companies.)

You need something that confirms the take-home test was really done by the candidate.

I have received take-home tests, passed via recruiters, where the recruiters literally sent me the solutions given by previous successful candidates "for reference".

Although that seems like a valid reason, consider how many justifications have been used throughout history to scare people into submission. “There May be cheaters out there” is of the same form as “there may be <insert statistically unlikely thing> out there, so you’d better <unnecessary overreaction>.”

If there is data to support that most people are cheaters, that’s fine. But at Matasano I believe the statistics were ~30 candidates who were invited for an on-site interview after a take home test, and ~30 happy hires.

The on-site interview was also mostly a formality; the fact that they could do the work was enough to all but guarantee an offer.

And when you reduce it to those terms, it seems ludicrous that the world should be any other way. You can either do the work or you can’t. And if you can, nothing else should matter.

There are other counter arguments: what if someone is a huge introvert and not suited to working in a team environment? Bring on the introvets, I say. You won’t regret it. The most talented coworker I’ve ever seen was also someone who had stammering problems and would barely talk. But he was very nice, and much more skilled than I was at the time.

You don’t know someone until you work with them. And if they’re a bad hire, it’ll work itself out within the first month. It’s far better to deal with a possible cheater than to miss out on a skilled, solid hire. The latter makes or breaks companies; the former are just a temporary thorn.

> But they will. The interview process is stochastic; exactly the same performance from you will lead to different results on different attempts.

I agree that's in practice true for many places. But I hope companies have the good sense to be too embarrassed to admit that their inability to be consistent is the reason to reapply.

I think the traditional reason for the "try again in three months" bit is that paper-based processes make it hard to find and re-contact promising candidates who didn't happen to make the grade this time. But if any place really thinks, "We won't hire this developer now but they would be good in the future," I think a much better solution is for the hiring company to make a list of people to re-contact next time they're hiring.

less applicants ? more customers ? error in judgement ?

I did the project (back when that was an option on TripleByte) and failed it. They said I could still try the pure technical interview option, but then ignored me when I asked for that (albeit more than a year later).

Even a year later, you should definitely have had the chance to try again if you'd like. I can reactivate your account; email me at kelsey@triplebyte.com

I'd settle for "do you at least send a rejection email of any kind to the candidate?" vs. the "dropping someone on the floor and not responding for weeks/months/ever". Even without detailed or personalized feedback, it's a huge improvement. Also if an internal person refers someone, you should let the internal person know if you're passing, I think (depends on other factors, though.)

"Ghosting" seems like a common phenomenon across different types of human interaction. There's dating, interviewing, and even pitching investors.

This was a common experience for me pitching my company last year:

1. Investor likes my co enough to schedule an in-person meeting

2. I meet investor in person to pitch

3. I send them a followup email

4. Radio silence

I'd read that investors like to keep you in limbo instead of passing, I just didn't realize these well-respected professionals would value someone highly enough to give them an hour of their day, but low enough to neglect all followup communication. In retrospect I don't think it's a big deal, but I felt bad about it at the time.

This is the biggest US/Europe cultural difference I've noticed. I can't speak for every country in Europe or every industry, but for every job in Europe I've personally applied for, I got a rejection letter if I wasn't offered the job. Sometimes just a minimal notification, but always something. Not in America though...

The best is for European academic jobs. Often there's a schedule up front for when they'll make a decision, usually a 2-stage thing like: we will shortlist candidates by Sept 15, interview in the following 3-4 weeks, and make a hiring decision by Oct 15. So if you didn't get shortlisted, you get informed early and don't have to wonder whether your resume is still under consideration or what. American universities, though, leave you guessing what their schedule is, may take months to get back to you even if they're interested, and usually don't send a rejection letter if they aren't.

Article author - I'm on the writing team at Triplebyte. Most of what we do is summarize candidates' technical performance for their introduction to companies, but we also send feedback to everyone who takes our two-hour interview. I took this responsibility over from our first engineer, who built a bunch of software to make the process faster - it lets me quickly autogenerate emails by clicking all the resources I want to include, and then highlights the things that require more careful review. (So the people who accuse me of being a robot are half-right, I guess.)

Isn't giving detailed feedback a liability nightmare? Everything I've ever heard on this is to say as little as possible.

It's certainly great as a candidate to get detailed feedback (would have really appreciated it back in the day as a co-op student), but I just wonder if the concerns over it have any merit or are overblown.

This is dealt with at length in the article.

This is called out early in the post:

> The number one reason companies cite for not sending feedback is legal risk. Interestingly, I don’t think this is true. Companies put themselves at legal risk if they are rejecting candidates for illegitimate reasons, like race, gender, or a disability. If they send feedback which tells candidates, truthfully, that they were rejected because they didn’t get very far on the coding project, then if anything a company reduces their legal risk: they have a transparent track record of evaluating candidates based only on their skills. I recently talked with an employment lawyer about this, and he didn’t think that specific feedback on technical performance put companies at risk. So legal risk, despite being frequently cited, seems unlikely to be the real driver of policies here.

Then, an explanation that legal risk isn't the same thing as lawsuit risk:

> Even if your process isn’t biased, if you send feedback that creates the perception you’re biased, that’s enough for a costly lawsuit. So while legal risk isn’t a reason not to send detailed, honest technical feedback (as long as you’re not discriminating), it’s a very good reason not to send carelessly compiled feedback through a haphazard process (even if you’re not discriminating).

Right, the liability is not "we are going to send a letter that says you're too old/you're a woman" or something blatant like that, the liability is that a very well-meaning person sends a thoughtful rejection letter and it can be inferred in the language - true or not, and this is the kicker - that there is discrimination going on.

You are doing a nice thing by being detailed, but you are basically introducing nearly unbounded downside for the upside of being nice. Most companies don't find much value in this calculus. It doesn't make it the right thing to do, but it is understandable.

I doubt that liability is much more of an excuse- how often do disgruntled candidates actually sue corporations, in any context? If a company doesn't want a candidate, there's not much value lost by them burning bridges with them, by refusing to send them feedback, or even a rejection notice. This is especially true for big companies who receive a lot of candidates. And for smaller startups, they simply lack the time and energy to give detailed responses to people they pass on. A failed candidate is of marginal use to a company.

The article addresses the "liability nightmare" and they mentioned they reached out to an employment lawyer.

My understanding is that as long as you're not discriminating against candidates on the basis of race, gender or some other protected category membership, and as long as your feedback reflects that by being focused on the technical abilities the candidate demonstrated during the interview, you're not actually at all that much risk. Of course, if you are illegally discriminating, or if your feedback suggests that you are by giving feedback on candidate appearance or something (never do that), then you're absolutely better off not sending it.

How do you imagine they would give feedback on something that's neither technical nor illegal? I'm imagining everything from "we found you too arrogant" to "you smelled awful when you came in"...

For arrogant, I'd try to make the feedback as concrete and specific as possible - "sometimes you gave confidently wrong answers. If you're guessing, it's better to tell your interviewer that. Interviewers typically won't hold it against you if you guess and guess rightly, but if you don't acknowledge you're guessing and get things wrong, it raises questions about whether you know what you don't know." or "sometimes it's great to ignore the spec because you have something better in mind, but on an interview it's typically better to demonstrate your creativity and knowledge while still building to the spec - it makes it easier for us to evaluate you" or "when talking about your last company, you said some things that came across as disdainful about your coworkers. It'd be better to highlight your achievements."

All of those are ways being arrogant can manifest, but they're much more actionable than 'you were arrogant' and unsurprisingly get received a lot better.

I wouldn't comment on smell - yes, that's valuable feedback a candidate really ought to hear from someone, but the risk of really angering them is too high for me to feel comfortable with it.

The thing is you still reduced arrogance to technical correctness. However, what I was trying to get at was, what about cases where the technical correctness is just fine? If it's their attitude or hygiene or something else that you don't like, how do you tell them that?

I was trying to get at the same thing you just said, which is that, like you, most people would become uncomfortable providing feedback on at least some of these. Meaning that you would have to turn away these candidates without any concrete feedback. Now how do you imagine they'll react when they realize most people do get feedback but they didn't? Is their reaction (which might result in bad publicity) a risk you and your company really want to take? For what gain?

So the thing is, I think arrogance is typically reflected in actual deficiencies in interview performance. If it isn't - if it's just a vibe that the interviewer got with no concrete implications for how they work with others, solve problems, or communicate - then I worry taking it into account is introducing bias. If I can't think of a concrete implication that the arrogance had, then I don't think I want to take it into account. (You almost always can identify concrete effects, though.)

>Every few months, I check that all our recommended resources are still up-to-date, available, and free.

What are your recommended resources for technical improvements in coding interviews?

We have a blog post with some recommendations based on what we've seen at Triplebyte: https://triplebyte.com/blog/how-to-pass-a-programming-interv...

I think it's a pretty good starting point. I also like Cracking the Coding Interview and I think there's definitely a place for timed coding challenge sites like leetcode - especially if you've been in a role where you're mostly working on larger-scale problems rather than on producing smart, working code quickly on the fly.

Can you tell me what companies find attractive about: "...producing smart, working code quickly[;] on the fly," (emphasis mine)?

I understand there are a lot of substandard programmers in the marketplace. However, why is it that this specific criteria is the one the industry is so attracted to? Could it be that kids are proficient at these kind of games? Because I can tell you that in the 1980s, 1990s, and early 2000s, I wasn't being asked to write a regular expression parser under time pressure.

Others in this thread say they've done Triplebyte take-home tests, only to end up in a "go fast-fast-fast!" interview in the end.

Why is speed so important? Every popular [aA]gile methodology today is implicitly -- if not explicitly -- against such "machismo" programming. If you're pair programming, how is this ever relevant?

Whenever I see someone say leetcode, hackerrank, and Cracking the Coding Interview is the "answer" it translates to "only the young need apply" in my head.

It's interesting that you pat yourself on the back about it, I think the whole Triplebyte interview process is poorly thought out, including your email comms.

I did your online code quiz and got sent an email about doing a 2-hour technical interview, without really knowing much about what the job I was supposed to be applying for was.

On the interview, since I didn't really want to waste 2-hours on something I didn't want to do, I asked the guy a few questions about the company only to learn he's actually a freelancer interviewer, has little direct relationship with triplebyte and doesn't really know anything about me.

I carried on for a 2-hour quick-fire interview with a guy that was obviously trying to fill in a questionnaire rather than actually gauge my ability, questions designed by people who likely have no real-world experience in the scenarios they describe ("how would you architect the amazon.com frontpage?" is not a 2-minute answer)

About 15 minutes in, I was sure that even if I had wanted the job in the first place I wouldn't have taken it; and I had forgotten about it when I got an incredibly patronising email explaining how, if I do some online code puzzles and study hard, I too can get a job. Gee, thanks.

Granted: a bored, funemployed, grumpy dev is probably not your target audience, and I'm sure this interview style works to filter out people fresh off college, but the email was definitely the most ridiculous part.

Yeah, another disadvantage of feedback is that some people really resent suggestions on how to improve - they can come across as condescending. I definitely would rather get feedback to someone who wants it even if this annoys someone who didn't, but I think lots of companies are making the opposite tradeoff - and that's part of why feedback is so rare in the industry.

I don't think the suggestions are bad per se. The reason they come across as condescending is because they're obviously very generic and they're sent to people who, in the current market, can be picky about who they want to work with.

Ultimately your whole business model is competing with tech recruiters, and my recruiters will call me to give me feedback from a role application, you have reduced that human touch aspect to an email with a few links to hackerrank.

As a writers for TripleByte, how much technical background do you and the rest of the writing team have?

I did a degree in symbolic systems (CS + philosophy + linguistics; I have some CS background but less than I'd have gotten from a CS degree), I did one software internship, and Triplebyte was my first job when I graduated. I'm sure every candidate I send feedback is a stronger engineer than I am, but I do have some technical background. Most engineers want to write code all day, not emails, but I think a technical background does help us do our jobs.

At least you get a response even if it is a rejection letter. I have heard - not experienced - that sometimes you just don't hear back from the company at all, which seems worse to me.

I get why companies don't do honest rejection letters, but this there's no excuse for whatsoever.

It'd be nice to have some kind of public list where we could report companies that ghost, to warn other engineers to stay away.

seems like the interviews portion of glassdoor would support that?

(caveats re trusting glassdoor, blah blah)

Just write up a review on glassdoor. Specifically calling them out for a crappy interview process. Or if you are really bold and bother with linkedin, make a post.

You can't trust this because candidates do get petty when they get rejected and invent or omit details. That happens often on glassdoor.

Just like with any "crowdsourced" review site, I find value in the reviews, even if I don't, strictly, trust them.

Of particular value are multiple reviews that corroborate certain details, especially in the absence of reviews providing contradictory details.

At the very least, with something like "ghosting" during the interview process, it can help set expectations and inform behavior such as follow-up. For example, if interview reports complain of ghosting, I might still apply, but I wouldn't exert as much (if any) effort in soliciting a post-interview reply.

It absolutely is worse to not hear back at all. As someone who has dealt with this recently, the one positive thing I can tell myself about the experience is that I would not work for a company that cannot be bothered to write a rejection letter.

It reminds me of a restaurant I worked at in my youth - because the owner and her daughter were so conflict averse - rather than fire someone, they would just slowly write them off the schedule. Sad.

> because the owner and her daughter were so conflict averse - rather than fire someone, they would just slowly write them off the schedule.

Firing someone (without cause) leaves you open to having unemployment claims filed against you. Writing them off the schedule so they're forced to quit on their own accord negates that leverage; underemployment claims are harder for complainants to pursue/win.

Restaurant owners being the stingy type, I guarantee you this wasn't done to avoid hurting employee feelings.

Hourly workers who have their hours dropped below a minimum threshold qualify for unemployment in many states, as that is frequently treated as a de-facto layoff.

You make a strong, valid point. However, in this case, as someone who worked there for a long time, and knew both the owner, and her family rather well.... I can say with absolute certainty it was to avoid the conflict / hard feelings.

This happened to me. Several rounds of interviews with a well known colored-hat company, then... nothing. No response to follow-ups either.

What was especially frustrating to me was that up to that point, the tone of both the conversations and email exchanges was very positive and cordial. I would have expected a "Thanks, but no thanks" follow-up at least, especially considering I was an internal referral from a Sr. Mgr. But... nothing. Made my reconsider my view of that particular company.

When this has happened to me before with bigger companies, I finally get a rejection letter months after the fact. My guess is that it’s them hedging and not wanting to reject until they’ve filled the position.

Lots of companies are a mess internally.

If in 2-3 weeks you haven't heard from the recruiter, you should ping them back, if no response don't was further time and move along.

Interviews often seem like hit and miss. I would recommend training at geeksforgeeks.org just to refresh dynamic programming, etc. But beyond that you're better off applying multiple places.

I’ve had that. But not from anyone I cared about after going through the interview. Unsurprisingly.

Yeah, I was referred to a company and went through the full interview process, ended with a cheerful sounding "talk to you soon" and then zip. No messages and no replies to my emails.

It took my friend there a week to find out that I'd been rejected.

I had this happen on hires I was responsible for, but on "continuously open positions" or when the position is left vacant and the headcount repurposed to another position.

I didn't find a useful or correct way to inform all the potential candidates about that change. That happened two times and I only sent the more generic e-mail we send for rejection telling the people that had had at least one face to face to apply for other positions if they were still interested in the company.

For the easier case of filling the headcount up with someone and not wanting the rest it's easier to send a rejection e-mail, it's just not what always happens with every job opening.

I've personally experienced this with a YC backed company that still posts job listings on here.

After 2 full days on-site with said company, I got radio silence. Not even a quick "thanks but no" email.

I've had this happen to me after a half-day interview. I chalk it up to incompetent and uninterested HR staff.

I once got a rejection from a company six months after I interviewed on site. I'm not sure if that's better or worse than hearing nothing at all

I'm still waiting to hear from SouthWest Research Institute. I interviewed there in 1990.

I haven't had much interviewing experience lately, since I was at my last job for 5 years and at my current job for 6, but over the past 15 years or so, I came to the conclusion that not hearing back was the norm rather than the exception. I think it's ludicrously unprofessional, but that's typical these days.

I used to write rejection emails for companies at the end of YC interview days. It always sucked, especially when it was borderline decision (which it often was) but PG made doing these well an important part of internal YC culture. We couldn't leave until they were finished and each one was reviewed by another partner before sending.

In hindsight I'm glad we did this. In the years since I've had multiple people tell me the rejection was a positive turning point and the only honest feedback they'd received.

I'm going to go against the grain and say that interview feedback is overrated (at least for senior people). If you got offered the job, then there's your feedback. If not, the interviewing company isn't going to tell you any more than you could already discern yourself by playing back your answers and conversations with the interviewers. If you honestly feel you aced the interview, then other factors are in play - perhaps they realized they are overstaffed, layoffs are imminent/hiring freezes, or just a slightly better and more personable candidate came along.

One time I interviewed for a position that I wanted badly. I studied and prepped for the interview, then during the interview I nailed every question. I waited a week but never heard back. After a few weeks of silence and giving up hope, I searched the company on LinkedIn, and found the person they hired for the position. It turns out he had more backend experience, which is what they were looking for. It was a painful truth, but them sending me a rejection email telling me this wouldn't have helped me at all.

An email would've at least saved your time spent in LinkedIn search. And what if the new employee wasn't on LinkedIn?

Precisely. Often times a rejection isn't saying that the candidate didn't meet the job requirements or wouldn't do well in the position, it says that the employer found someone who fit the role even better or knew that they could given past hiring experience.

I agree with you, except that the company should send out a rejection letter as soon as they can. If I were hiring, I would only send a non-generic response if the rejected candidate specifically asked me if I would be willing to give her or him constructive feedback, or otherwise indicate why they did not get the position.

What if they are not rejecting you? What if they like you as a candidate but decided to move forward with someone else (and it was a tough decision), and want to wait to see if that person will work out. It sucks, but it happens.

A rejection brings closure. If I spend four hours answering these silly Big O questions, the least the company could do is give me a definitive yes/no in a timely fashion.

the hours of interview time, scheduling, and travel shouldn't be discounted so easily. not that the company owes you anything, but surely some of the smartest business minds in the world can come up with a way to safely provide some feedback. i'd probably sign a waiver to at least get something for my time

> When someone can’t answer an interview question about relational databases, it might be that ... they know them inside-and-out but aren’t used to answering questions on the fly, or that our question didn’t use the vocabulary they’re familiar with, or that they misheard the question and answered a different one.

Ultimately, that means your interviews have bias. (Even though it appears you try very, very, very hard to avoid bias.)

Honestly, I don't think interview feedback is a good idea. It just encourages gaming the system. I'd rather that feedback come through a neutral 3rd party. We just haven't set our field up to do that.

Why neutral 3rd party? Because of the above situation! The 3rd party could just say things like, "looks like this was just a bad interview. Don't read too deep into it, and keep trying." The 3rd party could also push back on the employer if the interview ran poorly.

And no, recruiters are not neutral 3rd parties.

> giving feedback effectively is an enormous amount of work

I take a lot of issue with this. Interviewing and doing code projects is also an enormous amount of work. If a company sends an 8 hour exercise to each candidate, then in aggregate the candidates are probably expending way more person hours than the total expended by the hiring company to settle on a new hire.

I no longer do unpaid work. Of course I’ll interview, but to show them how I code on their product and work in their processes, I will only accept a contract-to-hire offer. If more people did this I believe it would exert pressure on companies to not be so wanton with what they ask of candidates, and how expendably they treat them.

my triplebyte rejection was surprisingly insightful. I don't know whether it's cookie-cutter, entirely handwritten, or a combination of a few macros, but it makes sense to me.

https://pastebin.com/AGPyzmgU

>I heard back from many of the engineers I write to, and often, they were furious

Bingo. I've opted to share specific team feedback via phone and although candidate feedback was generally positive and thankful, once in awhile the reaction would be extremely negative. I now opt for the much more (emotionally) safe route.

Triplebyte is more incented to provide candidate feedback because if the candidate improves, Triplebye may be more likely to place them in the future. With companies, this incentive is less apparent.

Yeah, this sounds like as much of an issue as the legal risk to me. Imagine if you reject someone and they blog about the letter you sent them and the interview process, and the post makes Hacker News or Reddit.

Now you have to decide whether to fight in public with someone you didn't hire, normally bad form, or say nothing.

Interesting read/points about risk and candidates not being receptive to feedback. I've worked for companies that reason like this but personally, I believe the biggest challenge to overcome is for the person declining the candidate to articulate clear/concise constructive feedback over the PHONE vs sending an EMAIL.

My current firm (McKinsey & Company) expects every candidate in round 1 or final round interviews (either from the recruiter or hiring manager) to receive a call same day or within a day of interviewing with their interview results. If the results are a decline, feedback as to how and why we came to that decision is provided. It's painful for sure and no one likes to give bad news but the firm has been operating this way for years and I’ve found candidates appreciate knowing sooner rather then later.

Let's face it, there are a lot of bad hiring processes out there and not hearing back is the WORST when on the job hunt. At my firm, we rigorously evaluate candidates based on performance and will always do our best to ensure they are provided with feedback in a timely manner (note: I'm sure there have been slip ups in the past RE: same day/1 day after interviewing feedback but the firm expects every recruiters/interviewer to follow this process).

If they send feedback which tells candidates, truthfully, that they were rejected because they didn’t get very far on the coding project, then if anything a company reduces their legal risk: they have a transparent track record of evaluating candidates based only on their skills

I think the problem comes when he talks to his friend of another race/gender and that friend said "Yeah, I couldn't finish that either, but they still hired me". The company may have had a legit reason to overlook the coding project (like the second candidate had experience in some other technology), but when you tell candidate X that they didn't get the job because they didn't complete the coding exercise, but then you hire candidate Y despite him not completing it, it provides candidate X with some concrete evidence of discrimination.

I've applied to hundreds of internship positions by this point (I'm a senior looking for a full-time job starting this upcoming summer). During those hundreds of applications, I've only received explicit feedback (aside from getting offers, since getting an offer means I did good enough; I never got explicit feedback from any of those offers) a total of twice.

One was for a marketing company that's already gone public because I made it to the final round and really fell apart during the coding portion. I knew I screwed up and the recruiter confirmed that (without me asking) during the "thanks for applying, but no thanks" phone call.

The other time was for a medium-size startup. I had to ask the recruiter via email after I got the "no thanks" email, but she provided the info within minutes.

Solid content marketing - I just spent the last 30 minutes taking the coding test because of this post.

So, good article, but another point occurred to me while reading it that wasn't covered. I think that writing a good email explaining the rejection, might be a good exercise for the company doing the rejecting. "Well, why are we rejecting this person, exactly?" Of course, this will only be true if the email is honest (if diplomatic). It could serve as an institutionalized review of whether candidates are getting rejected for the right reason. Building feedback loops into a company's internal process can be a very powerful thing, even when there's no bonus or penalty involved for the person doing the writing.

I wonder, does Triplebyte have any kind of annual summary of why candidates are getting rejected?

Companies hire the candidate they like best, they don't even spend mental energy 'rejecting' the other candidates. If you don't get hired, it says more about the candidate they chose and little about you.

I don't think a company should offer an interview if they're not willing to give proper feedback at the end of it.

When interviewing candidates, I have been more than happy to give detailed feedback if they've asked me to give it. I realise it's unconventional, so I get the feedback peer reviewed before sending it away. I'm pleased to see that there are other companies learning how to give better feedback.

Giving feedback is a small token of respect that a company can give in return for a candidates time.

In my experience, interviewees have been thankful and shared how hard it is to get feedback from their interviewers.

I would really rate a company that provides honest and truthful feedback a notch on top of the others as this shows some form of the culture that they have in their organization.

You can do an automated response to 95% of the rejected ones, and for the rest which made the cut past the initial stage of applying, having a more human-centric approach on providing response is the way to go.

The good words that would come out vouching for the company I think is enough reason that hiring organizations should take the effort to provide a meaningful response to some applicants.

Here's one thing that stuck out to me:

> Even Triplebyte only sends individualized feedback to candidates who've done a two-hour interview with us - we simply don't have the resources to do it for everyone who takes our online quiz.

Unless there's something interesting going on, it seems like it would be easy to give some kind of feedback based on the online quiz, even if it's only "You answered X out of Y questions correct on $TOPIC", repeated for however many topics were covered.

Ah, but have you considered what would happen when you give this "transparent skills-based feedback" to 90% of your rejected candidates, but then a couple of them get rejected for reasons you don't want to specify, or could potentially be interpreted (by an aggressive litigation attorney) as illegal discrimination?

Some candidates get rejected because "nobody enjoyed talking to him", "he seemed weird", "alienated the interviewers", etc.

Are you going to write any of that in your transparent rejection letter?

I've occasionally had a moment of schadenfreude where, after interviewing at a place I hated, I could write something like this:

Dear <So-and-so>,

Thank you for considering me for <position>. I certainly enjoyed talking to you in person. Unfortunately, I feel that <company> is not a fit for my needs at this time. I wish you the very best of luck in your candidate search.

Sincerely, etc.

Perhaps I'm being too broad but I think that rejection emails suck because generally, as a society, we aren't valuing communication or we don't think we can afford the time for actual feedback.

It triggers one of those "how much better would the world be" feelings, if more people took more time to give each other genuine feedback. I mean, maybe giving good feedback (for candidates that took time to apply and clearly made effort) could help people learn, it might even ultimately address unemployment, homelessness, or other root cause problems.

I understand the legal concerns - and there would be candidates who would exploit the process of genuine feedback as well - but I think it would serve to help people more than it would hurt. It does require time and resources, so organizations / institutions would have to look at it as a sort of a social benefit cost or something. But I do wonder how much good it might really do.

you could also just give feedback in the cases where it is requested. As a fresh-faced out of college coder I was rejected from ThoughtWorks after spending 3 days on a coding question. Yes, I sucked - all I wanted to hear though was "we really wanted to see TDD, even though it was optional" or whatever. I asked for feedback, they didn't give it, I now and forever will have a negative impression of their company and will avoid them - and often people whom have worked for them - technicality be damned. You don't always need to give feedback, but a little compassion for those that are new would be nice.

I found the feedback from my Triplebyte rejection to be very helpful in directing my preparation for other interviews. It helped me get a job offer 3 days later from just the type of company and role that they screen for.

When I was getting my MBA, about <many> years ago, I suggested to our career placement folks that they work up a legal agreement with the companies who recruited with us, indemnifying them against any EEOC suits if they shared detailed feedback with us (most large companies go directly to business schools to hire on a yearly basis). They asked a half-dozen companies, and no company's legal team thought they could be confident such a document would stick. Pity, as, at that stage, we all had a lot of interviews to take, and a lot of support in getting new interviews.

I was lead dev in a company, I felt strongly that I don't want to reject people without providing them with clear feedback what they did well and didn't do well.

VP hated the idea and very quickly was abandoned. We got a lot of bad candidates tbh, so it was hard to tell them what they did wrong (they bombed pretty much).

I still think, done well, it provides great benefit to candidates being considered.

Thing that worked well for me, I had elaborate set of topics/knowledge I want my developers to know and be rated on, it wasn't arbitrary selection. Still, when someone bombs, it is hard to relay they did bad.

Seriously, we need something written on why rejection sucks?

Rejection sucks because we all like to imagine that we are good enough and the only reason we applied is because we believed we are good enough so it stinks to be told that we are not good enough.

Doesn't matter how you phrase the email, might be nice to give a feedback, but for anyone who receives it, it stings. The only difference is that some folks have a positive mindset, they get over the sting and work towards getting better. Feedback or not.

Id rather get a rejection email than just not hear back. If you dont bother responding with a rejection after an interview you are a coward. And shouldnt be interviewing people.

The other reason specificity is a legal issue is that it provides data that can be disputed. For example, if you reject someone black and say the reason they were rejected because hey didn’t get far enough in the coding test — you’d better not hire the white guy who only got just as far (which might happen for a variety of reasons).

It’s almost the same reason you stay quiet when held by police. Even something seemingly innocuous may end being used against you in the future.

Hmmm, so on standardised tests I typically score in the top two percentile. (yes I'm fabulous). But the best developer I ever worked with was a Russian guy who interviewed terribly. He was great at code, he was even great as a team lead. But he sucked at interviews. I never interviewed him so I can't say why that is but...if there's more than a few of these guys out there, there's room for (major) improvement in the interview business.

I WISH I could get rejection emails. I'll talk to a recruiter at a company, exchange emails, even meet them .... 99.9% of the time if they're not offering I get NOTHING. They just don't respond.

I don't care that they're not hiring me, I'd just like some feedback. FEEDBACK PLEASE, anything that really matters that I can improve on or such.

It is to the point that even automated rejection letters seem nicer than the usual "ghosting".

I was once told by a recruiter that she absolutely guaran-damn-teed that she would call me after the interview process and let me know the employer's decision. Guaran-damn-teed.

After my in-person interview, about a month passed with no contact from her. I figured I didn't get the job. But I wanted to call her anyway, just because. She said, "Oh, I thought I sent you an email about it. Yeah, they don't want you."

Same, it's a pretty terrible system.

I will often tell candidates on the phone screen that I don't want to go forward for XYZ reasons (always technical). At one point one of the guys I gave feedback to like this turned the call into an occupational therapy session whining about the chicken/egg experience problem, how all these companies want him to know the "trivia" of CS fundamentals, etc.

Believe me, it's a lot easier to just send a form rejection.

TripleBye articles are generally bad. They're a mishmash of random ideas that feel A/B tested for the highest possible SEO return. I still remember reading through this: https://triplebyte.com/blog/a-taxonomy-of-programmers when it was first published trying to make sense of it.

Hard to care about the specific content of rejection emails when the average applicant will get hundreds of them before landing a position. It's like getting mad at the rain in Seattle winter. Though I do admit, the more effusive they seem to be about turning me down, the more offended I am as a professional. Then I forget about it 5 seconds later and move on to my next applications.

> I work at Triplebyte, and over the last year I’ve written over 3,000 detailed, individual rejection emails.

Wait, what? That means you're interviewing on average 12 people every single working day of the year. Even for someone who's job title was "Technical Recruiter" that would be a TON, let alone for someone who is a Team Lead and presumably has other duties. How is that possible?

It's possible his job is JUST to write these rejection letters. He gets feedback forms from all the interviewers, compiles them, reviews them, condenses them, touches them up, then sends them out.

That could easily be a full-time job for a large company.

I don't conduct the interviews, you're right that that'd be impossible. I take the notes from our interviewers and turn them into feedback emails.

In my experience, most of the feedback I've gotten has been trite and superficial. It's not surprising, since most interview processes are not designed to measure quality but rather to measure interest.

I once got feedback that I wasn't technically qualified, and when I asked how they knew that, they said that I hadn't spent enough time on leetcode studying the answers.

> Even Triplebyte only sends individualized feedback to candidates who've done a two-hour interview with us - we simply don't have the resources to do it for everyone who takes our online quiz.

I'm surprised by this. I would think that Triplebyte could automate the feedback for applicants who took the online quiz but didn't make the cut.

> I recently talked with an employment lawyer about this, and he didn’t think that specific feedback on technical performance put companies at risk. So legal risk, despite being frequently cited, seems unlikely to be the real driver of policies here.

This was either written very poorly or lacks serious basis to conclude thoughts about employee feedback (of which drives the thesis of the whole article).

First - "I talked to a lawyer and he didn't think it was a risk", does not sound very much like legal advice. Is there precedence for civil cases that were thrown out due to the basis of "just giving technical feedback"? How often do firms that provide "just technical feedback" get sued and how often do they settle those suits?

Second - I think most people want feedback on "how they interviewed" and not "were they the right fit for the job". This is where you get into a gray area of legality, because anything you might say may get misconstrued as discrimination. "Oh you think I was too nervous during my interview...well I have X condition that makes me like that and you can't reject me for that"

Third - feedback on technical skills? To what avail does this hold for the candidate? Example:

Potential Employer: "You couldn't reverse a string, so work on string reversals."

Potential Candidate: "Ok, I'll go learn a string reversal so I can ace my next interview"

Feedback on interviews is imperfect because the hiring process is imperfect.

I went through the Triplebyte process 1.5 years ago and their feedback was so influential in where I spent the next few weeks studying. I think their process and feedback played a huge role in getting my first (and probably current, too) developer gig.

Actually this is in my opinion the main advantage of headhunters. They will typically call the recruiter after the interview and seek feedback. And it is easier to provide feedback to the headhunter than to the interviewee directly.

I recently bombed a Triplebyte interview. I didn't realize how badly until I got the feedback email. It honestly hurt, but it was really useful. I definitely respect their approach.

Often time, it's just that after interviewing 20 candidates, we realize that this candidate is amongst the worst and telling him/her that isn't helpful.

Triple byte interviewers don’t know what they were interviewing all they have is bunch of questions they keep on asking without any opportunity to answer

On a side note, this also reads as an interesting insight into human behavior and how to communicate in general. A wonderful article.

I read the title as, you suck at your job therefore the emails suck. :)

Reminds of a recent prudential billboard. "We spend more time reading billboards than planning for retirement." Great, if you aren't doing your job of planning then I'll use someone else!

again decent article (though stating obvious) until last bracket which was whole point of posting it

I think the problem here is that it exposes you legally even if you're not discriminating. If your explanation can in any way be argued as euphemism, or analogous to discrimination against a protected class, then you could face trouble. Maybe the risk is overblown, but the form of exposure you're talking about may not be the main one, far as I reckon.

Reply on news.ycombinator.com