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

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.

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

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.

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

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.

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

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.

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.

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

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.

This is the world we live in, unfortunately.

Both are possible.

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.

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.

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.

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

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

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.

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.

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.

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.

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.

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.

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.

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!

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.

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

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.

> Please state your last exam conducted under such conditions?

University entrance exams.

University graduation exams.

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

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

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.

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.

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.

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

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.

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?

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

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.

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

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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?

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.

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

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

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.

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

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.

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

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

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

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?

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.

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.

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

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

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

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.

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)

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.

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

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

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?

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

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

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

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

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.

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.

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.

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.

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.

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

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

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.

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

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

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.

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.

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

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.

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

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.

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.

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

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.

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

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.

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

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.

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.

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.

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.

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

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

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.

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!

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.

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.

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

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.

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.

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

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.

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?

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.

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.

It is sad indeed.

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

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.

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.

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.

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

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.

Edit: shouldn't assume gender

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.

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.

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

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?

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.

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?

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

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.

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.

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.

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.