Hacker News new | comments | show | ask | jobs | submit login
I know why rejection emails suck – I write them (triplebyte.com)
365 points by nosseo 50 days ago | hide | past | web | favorite | 406 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?


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.


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.


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.


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


>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.


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.


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.


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.


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


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


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.


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.


>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.


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.


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.


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?


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.


>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.


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”


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.


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.


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.


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.”


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!


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.


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.


> 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.


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


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


> 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.


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.


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


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.


> 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.


> 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!


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.


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.


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.


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.”

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.


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.


”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.


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.


> 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.


> 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");


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.


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 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'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.


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.


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.


> 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)


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.


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.


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.


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.


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?


> 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.


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.


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.


Honestly, the fireworks guy seems pretty fun.

Curious what the lunch argument was too


"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.


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.


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.


>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.


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


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).


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.


> 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.


> 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.


>"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 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.


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.


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)


> 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 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.


> 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.


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.


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.


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 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.


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.


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.


> 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 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.


>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.


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


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.


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.


> 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.


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.


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.


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?


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.


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.


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.


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.


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.


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.


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.


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.


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?


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.


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.


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


[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?


"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.


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


Don't censor others.


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.


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.

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.


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.


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.


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.


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...


  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?".


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.


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.


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.


> 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.


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 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.


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.


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.


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.


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.


> 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.

More

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: