Hacker News Reader

Comment by monero-xmr | Hacker News Reader

No one can ever "solve" the recruiting issue. We are exactly where we were 15 years ago - not one thing has changed except certain screen-share coding tests, which are basically the same as white boards.

Can you reduce hiring an airplane engine designer to a set of tests? Or a custom home builder? If so, why is there not just a stack ranking of best ones, or an algorithmic way of hiring one?

Software engineering at elite levels is an art. It is conducted by master craftsmen. On top of it the best people are often quirky / weird and the social aspect when communication of needs is so essential makes it even more difficult to hire "the best".

The business models of recruiting is always either like sales (recruiting firms) or marketing (LinkedIn). I would stay away from the recruiting industry as a software startup - difficult to make any money here in a novel way.

View on HN

I wish we had industry-standard certifications that actually meant something, and were widely accepted. The closest I've seen in the real world is just "degree in comp sci". Other orgs have tried to come up with various certs, but they never seem to have any sticking power.

I guess it's a hard thing to certify when the landscape itself is constantly evolving and skills are obsoleted in 3-4 years. It seems even the pace of change is itself speeding up, and every year I see more technologies come to popularity (if not quite maturity) than I can even remember, much less learn. And it's not just languages and frameworks, but entire architectures... today's best practices are tomorrow's tech debt.

There should always be room for innovators to push the bleeding edge forward, but many businesses don't really need that. Instead, if there was just some shared certification for "good enough engineering" that can deliver a reliable, maintainable product somewhat on time, reproducibly, hiring and job-hunting would be so much easier. I'm so tired of trying to charm recruiters, impress managers, placate HR, all while hoping against hope that the actual dev 2 or 3 interviews later happen to have some overlap in languages, toolsets, shared pain points, etc. It's all such a dog and pony show, with many teams having ill-fitting skillsets and cultures between members because nobody really knows what they're signing up for or getting.

Credentialism is not good either.

And in general I've seen little correlation between credentials and quality, both in the software industry and elsewhere, so I don't think any such certifications will really solve anything either.

I think a more nuanced take on this is that very few companies need top quality, but nobody wants bottom quality.

Top-end devs make a name for themselves and don't really have to worry about hiring. Companies compete for them with crazy high offers.

Bottom-end devs try to make up for their lack of experience or skill by "hacking" the application or interview process somehow.

In between, "good enough" devs power the world's bog-standard apps. They're not going to win any awards or lead any talks, but they can do the jobs well enough to make the company money. They know they aren't top-end and can't just say "I'm quitting, who's hiring?" on twitter, but they are also competing with the hordes of less-skilled devs because there's no easy way to tell them apart.

I've never heard of "credentialism", but why doesn't it work in this instance, when it does for doctors, lawyers, engineers, etc.?

> I've never heard of "credentialism", but why doesn't it work in this instance, when it does for doctors, lawyers, engineers, etc.?

There are loads of bad doctors though, and bad lawyers, and bad engineers.

"Credentialism" refers to over-reliance on credentials, rather than just looking at what someone can do. I'm not against education, but education is not the same as credentials. People that can hack the interview process can also hack the credentials.

I've seen people with college degrees in IT employed as programmers that literally cannot program. I'm not talking "bad programmers" or "brain fart moment", I'm talking "consistently being unable to grasp even basic control flow over a period of months or years". Also some good programmers can be hard to work with for reasons other than their programming ability.[1] Plus not every programmer is suitable for every position or every type of programming or "jibes" with every other programmer in their sensibilities and approach.[2] The hiring process is just as much about that as testing basic skills.

No one thinks credentials are a guarantee of quality (people will always slip through the cracks no matter what), but I'm not sure they're even a strong indicator of quality either, certainly not for programming. This is hard to quantify of course, and just based on my own observations over my career.

[1]: https://news.ycombinator.com/item?id=21585958

[2] Simple example: I'm firmly in team "short names", but I know some people really hate it, but I'm pragmatic if nothing else and don't mind doing whatever works well for the entire team. On one extreme end I've worked in a team that insisted on the longest possible name for everything: every variable had to spell out the full name of the class where it came from, often >20 chars, otherwise people considered it "unclear what anything refers to!" I once added a mkdir() function, this was considered "obscure" so it had to be "CreateDir()", then someone said it may not be clear what "dir" is so "CreateDirectory()", and then another remarked it actually makes all intermediate directories too, so we ended up with "CreateRecusiveDirectoryTree()" – I'm not saying this is "wrong", but it does not jibe well with my sensibilities. Several other things also didn't, so I didn't last too long).

> I've seen people with college degrees in IT employed as programmers that literally cannot program. I'm not talking "bad programmers" or "brain fart moment", I'm talking "consistently being unable to grasp even basic control flow over a period of months or years". Also some good programmers can be hard to work with for reasons other than their programming ability.

Your link talks about "good programmers that lack social skills". In my experience, politeness is a finite resource and dealing with people on a regular basis fully unable to do their listed job is a severe tax on mine.

I wasn't talking about people who are well-intentioned but a bit abrasive if they're having a bad day, I was talking about people who are so unpleasant they "completely crush morale for the rest of the team or company".

I hear ya. Essentially, credentials aren't a good way to measure -- much less guarantee -- quality? That makes sense.

I've encountered several doctors, etc. who weren't very good, including one who shouldn't have been allowed to practice, IMO. Point taken.

Anyway, in your experience, what actually WOULD be a good indicator of candidate quality?

> Top-end devs make a name for themselves and don't really have to worry about hiring. Companies compete for them with crazy high offers.

Those who don't have to worry about hiring are not (necessarily) top-end devs, but good self-promoters and networkers. Not every top-end dev is a good self-promoter or good at networking.

Fair point.

It’s simply too free-form and the industries software is used in are… all of them. I believe it is better to certify the outputs (product features, uptime SLAs, security) than the inputs and how the sausage is made.

Software engineering is building a factory. The inputs are data. The outputs are data. All of the stuff inside the application are the different conveyor belts, elevators, gears, rollers, pounders, etchers, etc. to move and manipulate the data to make the output valuable. The factory can be constructed infinite ways without any care about physical dimensions, and the raw material can be duplicated to infinite amounts. The situation is beyond regulation and it should not be regulated. Only the product output should be regulated.

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.

You want to make it hard on yourself, that's your business.

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

Seven rounds! What questions was this company asking you for seven rounds?

Every time I’ve had a company go longer than 2 rounds, another company got me an offer first.

Not the OP, but Elastic and Glassdoor had me do 6-7 rounds.

Glassdoor had the gall to just ghost me after the 6th! Never again.

What questions were they asking you over so many rounds? Like how much more information about a candidate could one possibly need?

I think they were stringing me out while interviewing others. I should have seen through it, but wanted it to work out at the time.

Wow. I feel like for most recruiters, a simple "hey just to let you know you're still in the running"-type of check in would suffice?

If you could credibly spoof all that most companies would love to hire you. Would likely be your most valuable skill.

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

People absolutely embellish and get away with it.

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

The threat of litigation does not actually exist in terms of software engineering interviews:

https://news.ycombinator.com/item?id=22258113

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.

Source? Which tech companies? Or is it just the amorphous possibility of suits?

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.

Right, to be specific, the worry isn't:

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.

Indeed. I think tptacek's perspective on hiring is quite radical, certainly for established shops where doing things differently than the rest of the industry just adds friction elsewhere.

My read on the approach is that it works very well for certain types of engagements, but other types, such as where you are trying to build a solid team of peers, requires something _closer_ to the traditional methods. That being said the Starfighter approach is probably right most of the time -- teams are almost certainly never stable, management usually treats ICs as fungible cogs and moves them around, in which case individual value should trump things like team fit or culture. But we're human.

Appropaches like Google's work better (n.b. I am far from a proponent of what they do) because the interviewers are human and despite the whole blind-panel thing if the interviewer and interviewee can't get along the interview won't go well. So culture and team fit _is_ evaluated significantly more than something like Starfighter. People care a lot about that implicit bit, in my experience.

I used this approach at a company of about 750 folks, bending HR to bypass some of their stuff. E.g., they insisted on collecting resumes, but I generally discarded them. Instead, I did a one-on-one phone call for the purpose of them to ask me questions--not to grill them, and to ask them if they would like go to the next step and do a work sample test.

I tailored the work sample test to the role. I did it for the compliance hires and for the project manager. The results were unexpectedly excellent.

As a result of this process, and having a solid company culture, there are around ten or twelve folks that have a new career in the security field that would likely not have had another opportunity in the classical hiring scheme.

I think the state of the industry with respect to hiring and evaluating folks is broken across the whole spectrum. It is like once someone becomes established in a field, they invent all manner of gatekeeping tests that they didn't pass to get where they are. The whole story of sabermetrics is another example.

Fly.io is several solid teams of peers, built on resume-blind work-sample hiring.

For sure! But the company was built that way. An existing 1000 person corp works differently.

Everyone has to be on board for it to work, I'd wager.

Software interviews feel more like an audition which isn't necessarily a bad approach, except we're using random people sometimes with two years of experience or who do not even want to be there as casting directors.

Reply on news.ycombinator.com