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.
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.
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).
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.
_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.
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.
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.
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.
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.
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%.
>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.
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.
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.
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.
> 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)
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.
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/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 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.
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.
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.
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.
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.)
I had to twitch my feet to all three imaginary pedals to figure out the brake is the middle one. Even in this metaphor doing and knowing how to do are distinct skills.
You would fail anyway, because the interviewer thought it's pretty clear that automatic transmission was implied, not manual, since the job is about baking doughnuts.
One possible way to address this issue is by asking candidates to talk about some existing code you give them, rather than trying to cook something up off the bat while under scrutiny and not having access to their familiar tooling.
”I've seen candidates with anything between 1 and 15 years of full time coding work on their resumes fail to answer basic fizz-buzz level coding questions.”
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.
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.
> 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.
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.
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.
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...
Where? I've never seen anyone sue a company for not hiring them, and no company I've ever worked at has been sued for not hiring someone. If it was litigation-prone, I'd expect to see some litigation. I don't work in the US; maybe this is a weird US thing? Maybe people who do work in the US can give us some numbers? What proportion of companies one has worked for have been sued for not hiring someone? Or in a given year, what proportion of rejected interview candidates come back to sue the company?
It is a weird US thing, and nobody can give you numbers because the existence and outcome of these lawsuits is never talked about (most are settled out of court).
But talk to anyone in HR and you'll hear, "The stories that I've seen, if only I could tell you!"
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.
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.
"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]
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.
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?
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.
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.
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.
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)
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.
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.
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.
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.
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?