Yea it's a problem. You're trying to hire from a pool that includes very competent people, and also people who legitimately can't write any code at all and are just trying to sneak in for 6mo to get $100k before they get fired, or think that "fake it til you make it" is a real thing. But at the same time, unlike other engineering disciples there's no PE licensing exams (or whatever the FAA does, I forget), no equivalent degree requirements (for good reason - one can learn to code without it, and a huge portion of a CS degree is very theoretical), but at the same time is qjite difficult, nothing like a plumber/electrician/etc certification level with accompanying work requirements and an apprenticeship program, and has very high pay and demand.
For very small shops willing to incur legal risk or limit the application pool, you can do take home tests and/or lean on side projects, with an hour of explaining the nitty gritty details and choices. At scale it becomes untenable, because you open yourself up for discrimination lawsuits, and you can't convince a lot of people who already have jobs and families to do lengthier take home stuff.
If I had to bet, I'd bet some day it ends up like plumbing. You work as an apprentice, learn real stuff on the job, and then there's some kind of state certification which itself is a joke, but requires you to have gone through an apprenticeship program already where all the real shit happens.
Companies trying to hire "the best" or whatever are still going to have problems, so as long as there's not much regulation increasing cost of dev and uniformity by an alarming degree, we'll still have insane hiring (and insane pay too, regs will make it unprofitable eventually).
So my $0.02 from being on both the hiring and trying to get hired side of the fence. Also I can't do a whiteboard interview to save my life, never could. I mostly think the process everyone is running makes a bit more sense for entry-level applicants. You are dealing with a candidate pool exactly like what you describe above. However, for anything above a junior dev it is horribly inefficient.
Instead I'm always surprised more places don't rely on references and prior experience. Yes people lie, but in my experience its relatively easy to tell the difference with a simple glance at their LinkedIn. If I look at a candidate that spent 2-3 yrs as a Software Engineer at some company that I'm relatively familiar with, and they seem to have 2nds and thirds to people I know in the industry, then pretty good chance they aren't lying. Same for people taking the time out to write recommendations for them. Even bigger signal if they want setup some calls with their prior co-workers who can vouch for them, to me that means they stand by their work and reputation.
I recently went through about seven rounds for a senior role. During that time I repeatedly offered to setup some time with my prior coworkers from those I directly managed, to peers, to those I reported to (executive team). My thinking being that they could hear from the horses mouth how I lead a team, my work ethic, etc. They did not take me up on the offer, which to me was crazy. Yes, I could be running some machiavellian scam with 2-3 people who also made a fake LinkedIn, I also could have put up fake articles in PR Newswire announcing my last position, could have spoofed all those blogs I co-authored from the company I worked at 2 jobs ago, etc. But really, wouldn't it be a better signal for a candidate to offer and have all these things?
Instead you see an industry that puts someone with ~10 yrs experience through a whiteboard interview. It makes no sense.
I think this is more in line with how hiring works for senior jobs. I've been part of 50+ hiring decisions and do it like this.
Social stuff is absolutely the first thing I'm checking. It's a quick test to spot total lies, e.g. you claim you worked somewhere but are connected with zero people on any social network, or claim attendance at a school with zero connection to anyone. If nothing else, it helps to build rapport for the interview.
I would 100%, absolutely trust a personal recommendation over a dumb whiteboard interview.
> Social stuff is absolutely the first thing I'm checking. It's a quick test to spot total lies, e.g. you claim you worked somewhere but are connected with zero people on any social network, or claim attendance at a school with zero connection to anyone. If nothing else, it helps to build rapport for the interview.
There exist quite a lot of people who have no account on any social network for privacy reasons.
> If I look at a candidate that spent 2-3 yrs as a Software Engineer at some company that I'm relatively familiar with, and they seem to have 2nds and thirds to people I know in the industry, then pretty good chance they aren't lying.
The problem is: there exist a lot of companies - you can only be familiar with a very small fraction of them. Also, for many big companies, the differences between departments or groups can be a lot larger than between companies of similar size and sector.
Day to day, how much code do you think principle and staff engineers write? Senior architects and team leads? The problem is I don't think we, as an engineering discipline and career path, are willing to recognize that the job of being a coder stops being about writing code! Yes there are deadbeats who don't contribute (some of them can code just fine), as there are in every industry, but until you've been in a project that failed because there was no senior architect, someone getting paid a comfortable salary to be the "senior architect" and not write code sounds like a waste of the company's money to the intern.
At the start of a SWE career, I don't think things broken. Study up some leetcode and write code on a whiteboard to prove that you, as a candidate, are smart and motivated enough to play the game. It's after that, that things get out of sync and you get absolutely amazing people who have written world changing software who can't pass your stupid puzzle of a whiteboard interview. And then what do you do? This person failed your test but you want to hire them. Here's the part where we fail, where we are too stuck on following the rules.
They failed the test so you can't make an offer? No. Move heaven and Earth to bend the rules, and make them the offer anyway. Don't hide behind corporate handbooks and the HR or the legal department.
Obviously this power can be abused, but I don't take it as a given that it must be, given a hiring panel.
Google could have made an offer to Homebrew's Max Howell but chose not to, which speaks volumes.
> Yes there are deadbeats who don't contribute (some of them can code just fine), as there are in every industry, but until you've been in a project that failed because there was no senior architect, someone getting paid a comfortable salary to be the "senior architect" and not write code sounds like a waste of the company's money to the intern.
Oh, if only the worst was not contributing. I've been at a company full of brilliant programmers that was just driven into the ground by the senior architect, who wasn't necessary. Hiring someone who can't Fizzbuzz for that position (and giving him the authority to overrule the development leads) was absolutely the single decision that sank that company.
> Google could have made an offer to Homebrew's Max Howell but chose not to, which speaks volumes.
Programming is divided into a multitude of various cultures with their own (often incompatible) rules. Not without reason, you tend to talk of a "Java shop", "C# shop", "Python shop", ...
So, when looking for a good programmer, you either look for a beginner who is still "malleable" into your desired culture, or has the same right pedigree as your company.
In this sense, I a priori have no doubt that Max Howell is a decent programmer, but I do believe that he comes from and is attached to a very different programming culture than Google's; thus he would likely not be a good fit.
> For very small shops willing to incur legal risk or limit the application pool, you can do take home tests and/or lean on side projects, with an hour of explaining the nitty gritty details and choices. At scale it becomes untenable, because you open yourself up for discrimination lawsuits, and you can't convince a lot of people who already have jobs and families to do lengthier take home stuff.
At the end of the day, programming is just a writing job. So if you apply for non-technical writing jobs, e.g. to be a columnist at The New York Times or The New Yorker, do they not read any of your preexisting work on the grounds that it could open them up to discrimination lawsuits? Similarly, do folks who hire designers typically not look at their portfolios?
> So if you apply for non-technical writing jobs, e.g. to be a columnist at The New York Times or The New Yorker, do they not read any of your preexisting work on the grounds that it could open them up to discrimination lawsuits?
If you work in an industry where nothing is published publicly, and then demand to see people's side blogs and use that for hiring decisions, then yea that'll make lawyers at a big company a little skittish.
It's a different thing when your job is to write things that everyone can see, vs having your company own everything you do.
> or think that "fake it til you make it" is a real thing.
Fake it to you make it is actually a real thing. Though you actually have to be able to make it. You can overstate qualifications and experience but not competence. I don't lie about anything but i've definitely known people who have lied in order to get hired who have gone on to perform extremely well.
Sure I mean the extreme form, as in "literally cannot write any code at all" yet getting interviewed at XYZ tech company, and then being shocked when there's a coding interview. Bonus points when they've somehow talked there way all the way onsite, wasting 10+ hours of engineering time, and 48/72+ hours of their own time, before it's discovered that they can't in fact write code at all in any language. (I mean like 1 variable for-loop pseudocode, think fizzbuzz except without any conditional logic, even easier).
> because you open yourself up for discrimination lawsuits
Is that because when looking to make a possibly subjective judgement on the performance in a test and especially what a side project shows, it then becomes more difficult to prove that the judgement was not instead made because of some protected characteristic of the candidate?
That, and a big chunk of it is kids. In the same way you can't decline to hire someone because they're pregnant or may soon become pregnant (or are the father side of that equation) - requiring side projects is a very thin/loose proxy for "doesn't have kids". It's not a big enough problem to really stop people, but a big company's lawyers will stop it internally.
But people have absolutely sued, successfully, for discrimination. Just not in the context of being treated like an adult by an interviewing system that gives actual feedback.
Notably virtually no big companies will give feedback by policy, because of their own lawyers. All the engineers on the other side would freaking love to give constructive feedback. Their own lawyers prevent them from doing so.
Yes tech companies get sued for discrimination in hiring on a routine basis. The issue with giving feedback is the you hand evidence to the opposing side in a future lawsuit. There's very little benefit for the company, and a lot of risk.
Microsoft settled three years ago on a race discrimination in hiring thing. And two years ago for discriminating against non-citizens (and in some twist, Facebook settled the same year for discriminating against citizens, so... damned either way).
Just this year Workday got sued for discrimination in hiring, which is mildly hilarious because they're the HR-as-a-service company.
> Or is it just the amorphous possibility of suits?
It's mostly this, driven by the lawyers. They've seen a few previous settlements and just decide "well, none of that here".
I don't know if you've ever done hiring at a big company, or sat through the legal training things, but even if you don't draw a lawyer who tells it to you straight, it's pretty easy to infer what's going on.
Give feedback -> get sued due to something in the feedback
The worry is:
Give feedback -> ??? -> get sued for discrimination-> feedback is used as evidence that the hiring decision wasn't for a concrete/justifiable reason once its torn apart by a lawyer in front of a jury of 12 random people, only 7 of whom you need to convince.
For very small shops willing to incur legal risk or limit the application pool, you can do take home tests and/or lean on side projects, with an hour of explaining the nitty gritty details and choices. At scale it becomes untenable, because you open yourself up for discrimination lawsuits, and you can't convince a lot of people who already have jobs and families to do lengthier take home stuff.
If I had to bet, I'd bet some day it ends up like plumbing. You work as an apprentice, learn real stuff on the job, and then there's some kind of state certification which itself is a joke, but requires you to have gone through an apprenticeship program already where all the real shit happens.
Companies trying to hire "the best" or whatever are still going to have problems, so as long as there's not much regulation increasing cost of dev and uniformity by an alarming degree, we'll still have insane hiring (and insane pay too, regs will make it unprofitable eventually).