I know why rejection emails suck – I write them(triplebyte.com) |
I know why rejection emails suck – I write them(triplebyte.com) |
I think the problem here is that it exposes you legally even if you're not discriminating. If your explanation can in any way be argued as euphemism, or analogous to discrimination against a protected class, then you could face trouble. Maybe the risk is overblown, but the form of exposure you're talking about may not be the main one, far as I reckon.
Dear <So-and-so>,
Thank you for considering me for <position>. I certainly enjoyed talking to you in person. Unfortunately, I feel that <company> is not a fit for my needs at this time. I wish you the very best of luck in your candidate search.
Sincerely, etc.
It triggers one of those "how much better would the world be" feelings, if more people took more time to give each other genuine feedback. I mean, maybe giving good feedback (for candidates that took time to apply and clearly made effort) could help people learn, it might even ultimately address unemployment, homelessness, or other root cause problems.
I understand the legal concerns - and there would be candidates who would exploit the process of genuine feedback as well - but I think it would serve to help people more than it would hurt. It does require time and resources, so organizations / institutions would have to look at it as a sort of a social benefit cost or something. But I do wonder how much good it might really do.
VP hated the idea and very quickly was abandoned. We got a lot of bad candidates tbh, so it was hard to tell them what they did wrong (they bombed pretty much).
I still think, done well, it provides great benefit to candidates being considered.
Thing that worked well for me, I had elaborate set of topics/knowledge I want my developers to know and be rated on, it wasn't arbitrary selection. Still, when someone bombs, it is hard to relay they did bad.
Rejection sucks because we all like to imagine that we are good enough and the only reason we applied is because we believed we are good enough so it stinks to be told that we are not good enough.
Doesn't matter how you phrase the email, might be nice to give a feedback, but for anyone who receives it, it stings. The only difference is that some folks have a positive mindset, they get over the sting and work towards getting better. Feedback or not.
It’s almost the same reason you stay quiet when held by police. Even something seemingly innocuous may end being used against you in the future.
I don't care that they're not hiring me, I'd just like some feedback. FEEDBACK PLEASE, anything that really matters that I can improve on or such.
It is to the point that even automated rejection letters seem nicer than the usual "ghosting".
After my in-person interview, about a month passed with no contact from her. I figured I didn't get the job. But I wanted to call her anyway, just because. She said, "Oh, I thought I sent you an email about it. Yeah, they don't want you."
Believe me, it's a lot easier to just send a form rejection.
Wait, what? That means you're interviewing on average 12 people every single working day of the year. Even for someone who's job title was "Technical Recruiter" that would be a TON, let alone for someone who is a Team Lead and presumably has other duties. How is that possible?
That could easily be a full-time job for a large company.
I once got feedback that I wasn't technically qualified, and when I asked how they knew that, they said that I hadn't spent enough time on leetcode studying the answers.
I'm surprised by this. I would think that Triplebyte could automate the feedback for applicants who took the online quiz but didn't make the cut.
This was either written very poorly or lacks serious basis to conclude thoughts about employee feedback (of which drives the thesis of the whole article).
First - "I talked to a lawyer and he didn't think it was a risk", does not sound very much like legal advice. Is there precedence for civil cases that were thrown out due to the basis of "just giving technical feedback"? How often do firms that provide "just technical feedback" get sued and how often do they settle those suits?
Second - I think most people want feedback on "how they interviewed" and not "were they the right fit for the job". This is where you get into a gray area of legality, because anything you might say may get misconstrued as discrimination. "Oh you think I was too nervous during my interview...well I have X condition that makes me like that and you can't reject me for that"
Third - feedback on technical skills? To what avail does this hold for the candidate? Example:
Potential Employer: "You couldn't reverse a string, so work on string reversals."
Potential Candidate: "Ok, I'll go learn a string reversal so I can ace my next interview"
Feedback on interviews is imperfect because the hiring process is imperfect.
Reminds of a recent prudential billboard. "We spend more time reading billboards than planning for retirement." Great, if you aren't doing your job of planning then I'll use someone else!
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.
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.
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.
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.
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.
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.
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.
The lunch one - if the argument was not related to work, then I can't see an issue. You don't have to talk personal stuff to the co-workers, so unless the conversation wasn't mandatory and wasn't initiated by the candidate, then no issue here.
Only really valid cause is the firework.
Basically, it tells them that there was no technical reason not to hire them, which raises the question of whether it was something illegitimate.
Curious what the lunch argument was too
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.
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 you are working closely with this person, it will be 3 months before his accent is sufficiently adjusted.
This is a stupid reason to pass.
Accent is 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?
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.
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.
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.
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.
There are tons of companies that give you a generic email after you completed an IQ test, a questionary, open questions and of course the 8hours+ homework. That's just perverse.
"Try again in three months"
Why? I wouldn't do anything different.
This was a common experience for me pitching my company last year:
1. Investor likes my co enough to schedule an in-person meeting
2. I meet investor in person to pitch
3. I send them a followup email
4. Radio silence
I'd read that investors like to keep you in limbo instead of passing, I just didn't realize these well-respected professionals would value someone highly enough to give them an hour of their day, but low enough to neglect all followup communication. In retrospect I don't think it's a big deal, but I felt bad about it at the time.
The best is for European academic jobs. Often there's a schedule up front for when they'll make a decision, usually a 2-stage thing like: we will shortlist candidates by Sept 15, interview in the following 3-4 weeks, and make a hiring decision by Oct 15. So if you didn't get shortlisted, you get informed early and don't have to wonder whether your resume is still under consideration or what. American universities, though, leave you guessing what their schedule is, may take months to get back to you even if they're interested, and usually don't send a rejection letter if they aren't.
In hindsight I'm glad we did this. In the years since I've had multiple people tell me the rejection was a positive turning point and the only honest feedback they'd received.
One time I interviewed for a position that I wanted badly. I studied and prepped for the interview, then during the interview I nailed every question. I waited a week but never heard back. After a few weeks of silence and giving up hope, I searched the company on LinkedIn, and found the person they hired for the position. It turns out he had more backend experience, which is what they were looking for. It was a painful truth, but them sending me a rejection email telling me this wouldn't have helped me at all.
Ultimately, that means your interviews have bias. (Even though it appears you try very, very, very hard to avoid bias.)
Honestly, I don't think interview feedback is a good idea. It just encourages gaming the system. I'd rather that feedback come through a neutral 3rd party. We just haven't set our field up to do that.
Why neutral 3rd party? Because of the above situation! The 3rd party could just say things like, "looks like this was just a bad interview. Don't read too deep into it, and keep trying." The 3rd party could also push back on the employer if the interview ran poorly.
And no, recruiters are not neutral 3rd parties.
I take a lot of issue with this. Interviewing and doing code projects is also an enormous amount of work. If a company sends an 8 hour exercise to each candidate, then in aggregate the candidates are probably expending way more person hours than the total expended by the hiring company to settle on a new hire.
I no longer do unpaid work. Of course I’ll interview, but to show them how I code on their product and work in their processes, I will only accept a contract-to-hire offer. If more people did this I believe it would exert pressure on companies to not be so wanton with what they ask of candidates, and how expendably they treat them.
Bingo. I've opted to share specific team feedback via phone and although candidate feedback was generally positive and thankful, once in awhile the reaction would be extremely negative. I now opt for the much more (emotionally) safe route.
Triplebyte is more incented to provide candidate feedback because if the candidate improves, Triplebye may be more likely to place them in the future. With companies, this incentive is less apparent.
Now you have to decide whether to fight in public with someone you didn't hire, normally bad form, or say nothing.
My current firm (McKinsey & Company) expects every candidate in round 1 or final round interviews (either from the recruiter or hiring manager) to receive a call same day or within a day of interviewing with their interview results. If the results are a decline, feedback as to how and why we came to that decision is provided. It's painful for sure and no one likes to give bad news but the firm has been operating this way for years and I’ve found candidates appreciate knowing sooner rather then later.
Let's face it, there are a lot of bad hiring processes out there and not hearing back is the WORST when on the job hunt. At my firm, we rigorously evaluate candidates based on performance and will always do our best to ensure they are provided with feedback in a timely manner (note: I'm sure there have been slip ups in the past RE: same day/1 day after interviewing feedback but the firm expects every recruiters/interviewer to follow this process).
I think the problem comes when he talks to his friend of another race/gender and that friend said "Yeah, I couldn't finish that either, but they still hired me". The company may have had a legit reason to overlook the coding project (like the second candidate had experience in some other technology), but when you tell candidate X that they didn't get the job because they didn't complete the coding exercise, but then you hire candidate Y despite him not completing it, it provides candidate X with some concrete evidence of discrimination.
One was for a marketing company that's already gone public because I made it to the final round and really fell apart during the coding portion. I knew I screwed up and the recruiter confirmed that (without me asking) during the "thanks for applying, but no thanks" phone call.
The other time was for a medium-size startup. I had to ask the recruiter via email after I got the "no thanks" email, but she provided the info within minutes.
I wonder, does Triplebyte have any kind of annual summary of why candidates are getting rejected?
When interviewing candidates, I have been more than happy to give detailed feedback if they've asked me to give it. I realise it's unconventional, so I get the feedback peer reviewed before sending it away. I'm pleased to see that there are other companies learning how to give better feedback.
Giving feedback is a small token of respect that a company can give in return for a candidates time.
In my experience, interviewees have been thankful and shared how hard it is to get feedback from their interviewers.
You can do an automated response to 95% of the rejected ones, and for the rest which made the cut past the initial stage of applying, having a more human-centric approach on providing response is the way to go.
The good words that would come out vouching for the company I think is enough reason that hiring organizations should take the effort to provide a meaningful response to some applicants.
> Even Triplebyte only sends individualized feedback to candidates who've done a two-hour interview with us - we simply don't have the resources to do it for everyone who takes our online quiz.
Unless there's something interesting going on, it seems like it would be easy to give some kind of feedback based on the online quiz, even if it's only "You answered X out of Y questions correct on $TOPIC", repeated for however many topics were covered.
Ah, but have you considered what would happen when you give this "transparent skills-based feedback" to 90% of your rejected candidates, but then a couple of them get rejected for reasons you don't want to specify, or could potentially be interpreted (by an aggressive litigation attorney) as illegal discrimination?
Some candidates get rejected because "nobody enjoyed talking to him", "he seemed weird", "alienated the interviewers", etc.
Are you going to write any of that in your transparent rejection letter?
I 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.
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.
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.
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.
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-...
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.
I lost out a job interview in 1997 because I wasn't familiar with "state management" for websites. The guy was pretty insistent I needed to know what "state management" was. I'd already sent over a project using session management (and he'd created an account, logged in, I sent him the code, etc), but... I didn't know what 'state management' was, so I was passed over. I wasn't strong enough on the phone (and was in a different country at the time - was worrying about the long distance charges!) and... it fell apart. I was essentially a perfect fit (had had an interview before - this was second interview with someone else), but I choked on that phrase, and they passed me by...
Why not just have candidates accomplish the thing you're
assessing with an actual relational database?
After all, it'd be unfair to judge someone on a platform they weren't familiar with - so now you gotta maintain a fleet of laptops with a really wide range of tools. And these have to sorta float outside the usual IT management system because they aren't really issued to a single person, and you gotta be online enough that people can google stuff, and you can't have hiring managers let other people use their login, that'd be bad security practice. And if you didn't confirm in advance what platform the candidate wanted to be tested on, you gotta haul three laptops to the interview. Oh, they're pretty good developer laptops and one went missing? We really ought to have people sign those out...
And even after that, you _still_ have to apply subjective measures like "were their variable names clear?" and judge them on communication - like if they see an opportunity to refactor the code for clarity, but they say they're focusing on completing the task before spending time on that.
I'm not saying it's a bad thing to do this, just that I can understand why many companies don't.
Regarding "fleets of laptops" and environments and all that jazz: these seem like unforced obstacles. Just have the candidates use their own machines. Here's a crazy idea: have them use their own offices/couches, too.
Regarding security practices... come on. We have an interview process that involves giving remote developers read/write access to an entire AWS environment. These are simple engineering problems. If they're the only thing stopping you from having a better interviewing process, and you hire regularly, just go solve the problems.
Instead, just describe it to me. Best guess it. We'll dive into that.
You write about hiring from the perspective of someone with hiring authority. TripleByte doesn't have hiring authority, or even sufficient reputation to get their candidates out of doing another technical interview at the companies to which they apply.
There are two problems you might solve:
- Joe Nerd needs a job. He knows everything about relational databases, but no interviewer has ever noticed this. His limp, effeminate handshake leaves them unimpressed.
- IBM needs a database engineer. They really want to hire someone, but they're having trouble filling the opening; their existing network of friends-of-current-employees is tapped out.
That is to say, you could try to optimize for finding people who will be good employees, and then bully companies into hiring those people, or you could try to optimize for finding people who will pass an existing hiring gauntlet, and then introduce them to companies where the magic will happen naturally.
The first approach solves the candidate's problem and would logically charge fees to the candidate. The second approach solves the company's problem and would logically charge fees to the company. TripleByte wants to get money from companies, and follows the second strategy.
But... they like to send messages as if they were following the first strategy, because that strategy solves the candidate's problem and those messages therefore attract candidates to TripleByte. I don't like this.
There you go, now it's a work-sample for your senior developer.
* It's the same for all candidates.
* It captures facets of the work as it is done on the actual job.
* It's objectively evaluated (ideally, it has a rubric established a priori, such that results can be evaluated by someone other than the person who proctors the challenge).
It's possible to devise work-sample challenges that assess communication skills. I have friends who've done it at their companies for customer service and sales roles. I'm saying, the process described in this blog post does not appear to be that.
I’ve been trying to do something about that when it’s my turn to ask interview questions. For instance, too many front end people struggle with basic data manipulation workflows. I want to virtue signal that it’s better to move this kind of logic to the backend, but I need to test them anyway.
So I create a plausible scenario, maybe this is a POC to see if it’s worth sort or grouping functionality to the backend.
It's not the same thing. Browse around the various SQL tags in StackOverflow and you'll see plenty of candidates who can "accomplish" things using relational databases yet have positively no idea of how they work.
When shit hits the fan they're asking strangers to optimize their thorny queries. But a modicum of understanding of how a relational database works would have led them to a better way to do things to begin with.
Obviously if the job is highly MySQL specific and they need to know all the quirks that’s relevant.
It's because you can only fit so much into an already long interview (2 hours). A big chunk of that time is already spent on an exercise about reading/writing/debugging complex code. You can't fit everything in, so database stuff is moved to the non-coding section. Also, the questions aren't "guess the right answer" questions, the interviewer keeps digging with open ended questions to see how deep you can go.
> it could be that the candidates couldn't effectively communicate knowledge about RDMBS's. Or, it could be that the interviewer wasn't effectively listening to what the candidate was saying.
You could certainly get a bad interviewer, but that's a strawman here. If it's not TripleByte judging the candidate's communication skills, then it's the hiring team judging that. The suggestion was about how to give feedback about communication skills. And there are definitely stronger and weaker communicators, and it definitely makes a big difference in day to day work.
> It also might be that they know them inside-and-out but aren’t used to answering questions on the fly, or that our question didn’t use the vocabulary they’re familiar with, or that they misheard the question and answered a different one. [...] People are generally open to hearing that, one way or another, they didn’t manage to demonstrate that they understood a topic.
The author is actively acknowledging that being unable to answer a question about RDMSs doesn't mean they don't actually know anything about them.
And the point, I think, stands. An interview isn't a passive process where by some magic algorithm they determine good candidates from bad and the candidate just sits there hoping the right question will be asked. You have to actually communicate to the interviewer your knowledge and experience because they don't know.
1. They missed a failure mode: in addition to (a) lack of knowledge and (b) lack of communication skills, there is also (c) lack of interviewing skill.
2. It's possible to design an interview process that is resilient to both (b) and (c), and I figured Triplebyte, "who has just one job", would do that.
In addition, on this thread, I've tried (badly) to point out that while (b) is maybe a reasonable thing to check candidates for, it's better to do that explicitly, with an actual test of communication skill, rather than something that can easily get confounded with (a) and (c) (and all the attendant stress that situation generates!).
Thanks for the opportunity to clarify; I'm doing too many things at once today.
Asking you just to do one thing in an interview risks accidentally hitting one of the ten-twenty things you do know how to do, leaving me with no proof that you can solve the other 980-ish possible problems.
For some jobs it may even be appropriate to ask questions that the candidate cannot answer and see the reaction. Does he admit that he does not know? How does he phrase it? Is he making things up to cover for his lack of knowledge? And so on.
Why wouldn't you ask questions about relational databases? I would expect any decent dev to know the fundamentals of relational databases.
> Why? I wouldn't do anything different.
But they will. The interview process is stochastic; exactly the same performance from you will lead to different results on different attempts.
> Getting rejected at Triplebyte was actually a pretty good investment time wise. Guess the whole thing costed me three hours in total and I got quite a list of things to improve and how. It was clear it was tailored towards the interview not just a larger generic mail.
For another perspective, here's the entire feedback I got when they rejected my application:
> This was a tough decision and one that we were on the fence about. We really appreciate you taking the time to work on the take home project. We're aware this requires a substantial time commitment and we are really grateful that you invested the time in completing it. We thought you wrote a great, very full featured regular expression matcher. It was especially impressive how much you dug into the academics behind regular languages.
> However we made the decision because we felt that while going through the project together during the interview, we didn't see the fluency of programming when adding to it that we had hoped for. While we specifically designed the take home project track to help overcome the difficulties of coding under time pressure with someone watching, we do still need to see a certain level of programming during the interview. This didn't seem to be the case here, where making changes to the project seemed to be slower and more difficult than we'd have liked.
“How to set up a test that works and then completely ruin the results by doing nonsensical things during a dumb ritual that our entire industry seems set on preserving.”
Question for Triplebyte: when’s the last time that a single hour of coding — while being watched — determined whether you’d get to keep your job? Not acquire a job, but keep it.
I’m gusssing “never.” It’s a fake ritual.
I agree that's in practice true for many places. But I hope companies have the good sense to be too embarrassed to admit that their inability to be consistent is the reason to reapply.
I think the traditional reason for the "try again in three months" bit is that paper-based processes make it hard to find and re-contact promising candidates who didn't happen to make the grade this time. But if any place really thinks, "We won't hire this developer now but they would be good in the future," I think a much better solution is for the hiring company to make a list of people to re-contact next time they're hiring.
> But they will. The interview process is stochastic; exactly the same performance from you will lead to different results on different attempts.
Yeah I thought about that. But "try x months later" really means that you didn't pass some kind of bar. If I would be one of the five people that passed there would be no problem if I applied next week again, right?
I did your online code quiz and got sent an email about doing a 2-hour technical interview, without really knowing much about what the job I was supposed to be applying for was.
On the interview, since I didn't really want to waste 2-hours on something I didn't want to do, I asked the guy a few questions about the company only to learn he's actually a freelancer interviewer, has little direct relationship with triplebyte and doesn't really know anything about me.
I carried on for a 2-hour quick-fire interview with a guy that was obviously trying to fill in a questionnaire rather than actually gauge my ability, questions designed by people who likely have no real-world experience in the scenarios they describe ("how would you architect the amazon.com frontpage?" is not a 2-minute answer)
About 15 minutes in, I was sure that even if I had wanted the job in the first place I wouldn't have taken it; and I had forgotten about it when I got an incredibly patronising email explaining how, if I do some online code puzzles and study hard, I too can get a job. Gee, thanks.
Granted: a bored, funemployed, grumpy dev is probably not your target audience, and I'm sure this interview style works to filter out people fresh off college, but the email was definitely the most ridiculous part.
What are your recommended resources for technical improvements in coding interviews?
I think it's a pretty good starting point. I also like Cracking the Coding Interview and I think there's definitely a place for timed coding challenge sites like leetcode - especially if you've been in a role where you're mostly working on larger-scale problems rather than on producing smart, working code quickly on the fly.
It's certainly great as a candidate to get detailed feedback (would have really appreciated it back in the day as a co-op student), but I just wonder if the concerns over it have any merit or are overblown.
> The number one reason companies cite for not sending feedback is legal risk. Interestingly, I don’t think this is true. Companies put themselves at legal risk if they are rejecting candidates for illegitimate reasons, like race, gender, or a disability. If they send feedback which tells candidates, truthfully, that they were rejected because they didn’t get very far on the coding project, then if anything a company reduces their legal risk: they have a transparent track record of evaluating candidates based only on their skills. I recently talked with an employment lawyer about this, and he didn’t think that specific feedback on technical performance put companies at risk. So legal risk, despite being frequently cited, seems unlikely to be the real driver of policies here.
Then, an explanation that legal risk isn't the same thing as lawsuit risk:
> Even if your process isn’t biased, if you send feedback that creates the perception you’re biased, that’s enough for a costly lawsuit. So while legal risk isn’t a reason not to send detailed, honest technical feedback (as long as you’re not discriminating), it’s a very good reason not to send carelessly compiled feedback through a haphazard process (even if you’re not discriminating).
What was especially frustrating to me was that up to that point, the tone of both the conversations and email exchanges was very positive and cordial. I would have expected a "Thanks, but no thanks" follow-up at least, especially considering I was an internal referral from a Sr. Mgr. But... nothing. Made my reconsider my view of that particular company.
If in 2-3 weeks you haven't heard from the recruiter, you should ping them back, if no response don't was further time and move along.
Interviews often seem like hit and miss. I would recommend training at geeksforgeeks.org just to refresh dynamic programming, etc. But beyond that you're better off applying multiple places.
After 2 full days on-site with said company, I got radio silence. Not even a quick "thanks but no" email.
It reminds me of a restaurant I worked at in my youth - because the owner and her daughter were so conflict averse - rather than fire someone, they would just slowly write them off the schedule. Sad.
Firing someone (without cause) leaves you open to having unemployment claims filed against you. Writing them off the schedule so they're forced to quit on their own accord negates that leverage; underemployment claims are harder for complainants to pursue/win.
Restaurant owners being the stingy type, I guarantee you this wasn't done to avoid hurting employee feelings.
I didn't find a useful or correct way to inform all the potential candidates about that change. That happened two times and I only sent the more generic e-mail we send for rejection telling the people that had had at least one face to face to apply for other positions if they were still interested in the company.
For the easier case of filling the headcount up with someone and not wanting the rest it's easier to send a rejection e-mail, it's just not what always happens with every job opening.
It took my friend there a week to find out that I'd been rejected.
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.
It is one of the hallmarks of union labor management. It is one reason why private labor has a competitive advantage.
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 find it very plausible that your experience ("acceptance rate doesn't seem to change no matter how I personally vet the candidates") is more realistic than my armchair model, but I suspect the model is intuitive to a lot of people and will go a long way toward explaining "why are you asking questions about relational databases?".
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.
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.
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.
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.
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.
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.
- 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.
"Here's some schema information. This complicated query meant to do X is running too slowly. Can you recommend ways to speed things up and explain your reasoning?"
I 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 understand there are a lot of substandard programmers in the marketplace. However, why is it that this specific criteria is the one the industry is so attracted to? Could it be that kids are proficient at these kind of games? Because I can tell you that in the 1980s, 1990s, and early 2000s, I wasn't being asked to write a regular expression parser under time pressure.
Others in this thread say they've done Triplebyte take-home tests, only to end up in a "go fast-fast-fast!" interview in the end.
Why is speed so important? Every popular [aA]gile methodology today is implicitly -- if not explicitly -- against such "machismo" programming. If you're pair programming, how is this ever relevant?
Whenever I see someone say leetcode, hackerrank, and Cracking the Coding Interview is the "answer" it translates to "only the young need apply" in my head.
It may not be obvious to the other party that you didn't understand depending how well you covered.
Ultimately your whole business model is competing with tech recruiters, and my recruiters will call me to give me feedback from a role application, you have reduced that human touch aspect to an email with a few links to hackerrank.
You are doing a nice thing by being detailed, but you are basically introducing nearly unbounded downside for the upside of being nice. Most companies don't find much value in this calculus. It doesn't make it the right thing to do, but it is understandable.
I have received take-home tests, passed via recruiters, where the recruiters literally sent me the solutions given by previous successful candidates "for reference".
If there is data to support that most people are cheaters, that’s fine. But at Matasano I believe the statistics were ~30 candidates who were invited for an on-site interview after a take home test, and ~30 happy hires.
The on-site interview was also mostly a formality; the fact that they could do the work was enough to all but guarantee an offer.
And when you reduce it to those terms, it seems ludicrous that the world should be any other way. You can either do the work or you can’t. And if you can, nothing else should matter.
There are other counter arguments: what if someone is a huge introvert and not suited to working in a team environment? Bring on the introvets, I say. You won’t regret it. The most talented coworker I’ve ever seen was also someone who had stammering problems and would barely talk. But he was very nice, and much more skilled than I was at the time.
You don’t know someone until you work with them. And if they’re a bad hire, it’ll work itself out within the first month. It’s far better to deal with a possible cheater than to miss out on a skilled, solid hire. The latter makes or breaks companies; the former are just a temporary thorn.
Of particular value are multiple reviews that corroborate certain details, especially in the absence of reviews providing contradictory details.
At the very least, with something like "ghosting" during the interview process, it can help set expectations and inform behavior such as follow-up. For example, if interview reports complain of ghosting, I might still apply, but I wouldn't exert as much (if any) effort in soliciting a post-interview reply.
(caveats re trusting glassdoor, blah blah)
Just have the candidates use their own machines.
Needless to say, you can't objectively compare two candidates' progress if one of them spends half the interview trying to get their environment set up!
Regarding security practices... come on. [...]
These are simple engineering problems.
You've also made a pretty big shift in the goalposts there, from asking "why don't companies have candidates accomplish the thing they're assessing?" to asking "why don't companies have candidates accomplish the thing they're assessing, and perform remote video interviews, and have the ability to give spin up clean AWS environments and give remote semi-trusted interview candidates access to them?"
Better yet, just don't make people do that stuff in your office.
Why bother videorecording interviews at all? I'd have problems writing a line of code with someone breathing down my neck. If you did it to me on the job, I'd chase you out of the room. I feel like a lot of these problems are, like I said, unforced.
Agree to disagree about the degree of difficulty of getting clean environments to candidates. You're either serious about recruiting as an engineering problem or you're not. "Not" is fine, but then don't pretend like there's some kind of rigor in deciding which corners you're willing to cut.
I'm not making this stuff up; this is how we've been hiring people for about 10 years now, and every time I hear someone explain how challenging or untenable our process is, I keep wondering, "what am I doing wrong to make this work so well for us?"
Why bother videorecording interviews at all?
why not just tell them ahead of time what their
environment needs to do when they get there?
We chose to supply a known-good laptop instead of rejecting such candidates instantly when they've spent time travelling to us etc.
every time I hear someone explain how challenging or
untenable our process is, I keep wondering, "what am
I doing wrong to make this work so well for us?"
If most of the issues revolve around having roughly the same environment for candidates, just create ready to go VM images, for example VirtualBox, and share that with them. Or use a cloud desktop VM.
All of which make it easier for someone to succeed.
I agree with you generally, but you'd better have loaner machines ready. Not every candidate currently has a working, dev-capable laptop. Economic bias. (Hell, my current laptop is only 70% functional because I can't decide if I want to repair or replace it.)
After hundreds of interviews (I have no idea; lots, over 10 years of almost continuous hiring) I've never run into a candidate that couldn't do a tech challenge remotely.
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!"
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.
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.
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.
Both are possible.
Seemed pretty cut and dry to me. What about it disqualified it as a not-doxxing situation?
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.
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.
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.
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.
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.
This is a good use of time though. You won't find this on wikipedia, obviously, and is not considered basic technical information.
This is what I want to spend my time explaining.
Now, you're right, the technical distillation is not going to be on the level of "explain relational databases to a Joe off the street starting from square one", but it's effectively the same as the skill of "demystifying arbitrary misunderstandings and knowledge gaps other have", which is important.
All of those are ways being arrogant can manifest, but they're much more actionable than 'you were arrogant' and unsurprisingly get received a lot better.
I wouldn't comment on smell - yes, that's valuable feedback a candidate really ought to hear from someone, but the risk of really angering them is too high for me to feel comfortable with it.
I was trying to get at the same thing you just said, which is that, like you, most people would become uncomfortable providing feedback on at least some of these. Meaning that you would have to turn away these candidates without any concrete feedback. Now how do you imagine they'll react when they realize most people do get feedback but they didn't? Is their reaction (which might result in bad publicity) a risk you and your company really want to take? For what gain?
The bigger difference that I see is your statement that "Every few months, I check that all our recommended resources are still up-to-date, available, and free."
In some unfruitful further communication with TripleByte, I asked how I was supposed to improve, given that their feedback seemed to be "we have no qualms with your ability, but we don't think you can pass an interview". They recommended that I sign up on interviewing.io. I did that, and a year later, I was still on the wait list. (I eventually got off the waitlist when complaining about this same sequence of events on HN, and an interviewing.io employee saw the complaint. I don't think that approach scales well.)
It's hard to take this at face value, as 100% of the TripleByte messaging I've seen since before I received that email focused heavily on how confident they were that their interviews were thorough, high-quality assessments.
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.
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).
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?
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.
Edit: You also need to consider that TripleByte's idea of what works is probably different from yours. Their idea is probably more along the lines of "people pass our assessment and get hired." All you really need to do to hit that (not that it's a trivial thing at all), is conduct an assessment that's similar enough to what the hiring companies are doing. And, many of us know that hiring companies frequently aren't very good at interviewing.
Some people involved in our hiring process don't like them, they say experienced candidates stop responding when sent take-home tests. Their theory is employed people with families don't have the time - although we don't have hard empirical evidence for this for obvious reasons.
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.
Great. That's exactly what I said in my original post -- hire someone specifically to do that. Problem solved. Now your junior/mids don't have to explain that. But that's not the career trajectory of every developer, let's be honest.
If someone's going to deny me a promotion for linking a wikipedia page that answers a basic question and completely ignore my technical contributions, I absolutely do not trust that place has the best interests of its developers in mind and is likely driven more by politics than anything else.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
(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.)
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.
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.
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 :)
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.
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.
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.
> 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.
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.
> 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.