[notTyler]

'Get involved with hiring for your team and company, and maintain a high bar for hiring quality candidates.'

Posts derailing this 'high bar' are posted semi-daily to Hacker News, no? It's a really big dilemma (extensive hiring process that weeds out good candidates due to time and frustration or take risks) and it makes it sound like it's just something, you can, you know, do on a Tuesday in your spare time, and then on Wednesday you can solve the architecture problem.

And that's pretty much this list summed up. It's nice on paper, and maybe it will make a difference if someone consults it when making tough decisions. Thanks for your effort.

[LandR]

Especially nowadays when Developers don't seem to have to be required to actually be able to code.

I'm not part of the hiring process at our place but from what I've tried to contribute as a potential technical test, I get told it's too hard... It's really really not hard at all. But from what I can tell if you ask them to code, even in their own time or in the interview, that's unfair and stressful and you aren't seeing them at their best. So you ask questions instead of asking them to code, but then developers don't remember stuff they can just google nowadays. Again, you are being unfair and it's too hard for them!

We really seem to have allowed the infantalization of our industry, it's very depressing. Maybe the answer is just reject anyone under 35?

[iovrthoughtthis]

I find that things I think would be easy and often incredibly difficult for people who are not as experienced as I am. That certainly played out while I was writing exams for undergraduates.

Once we become experts (relatively) at something it becomes very difficult to judge "easy" and "hard" things. I suspect we have rose tinted glasses about our prior selves and their ability. Plus, the people we are testing are not our prior selves and have a totally different set of experiences they draw from.

You're comment feel very much so "back in my day" which I am almost certain is a logical fallacy.

[afpx]

I’m seeing the opposite in DC. Our recent “junior” candidates have been very impressive. I can see the affects of competition being played out. And, especially the female candidates - just outstanding.

[daveslash]

I'm sure it depends on your organization, and with large orgs maybe even your particular subdivision. That said, I can sympathize. I'm involved in the interviewing process of my niche in the org and try my best to hire quality candidates, but I can say that a non-trivial amount of devs are hired into the org without demonstrating any ability to code.

I think even a simple fizz-buzz can be a good litmus test. "I see here that you put JavaScript on your resume - good, we need that here. Let's open a console window in Chrome and do FizzBuzz". I've honestly gotten blank stares - developers who don't even know where to start.

[Edit: Spelling]

[hutzlibu]

So you want to implement an age measure of qualification, since you cannot get hiring to implement a good technical interview process? Do you also write code the same way?

[icebraining]

Are you having problems with the junior developers that are getting hired?

[PopeDotNinja]

The "high" in high bar is not a particular useful measurement. What is high? Unless you've defined what that means, and everyone involved understands and agrees what that means, it's just a word. What you can say is "we need someone who knows the internals of tool X, and we measure it via Y". Basically, avoid using adjectives to measure things (e.g. say 1 liter glass, don't say big glass).

[l0b0]

The only "problem" with that approach is that it invalidates most hand-wavy advice:

"Make everything as simple as possible but no simpler." All well and good if your requirements are written in formal logic or if there is only a single axis along which complexity can be measured.

"Hire only the best." What if the best only want to work with the best pay and the most interesting work? But "hire only the best of the very few who are willing to work on your projects for the kind of pay you're willing to offer, who will consider it a blessing that they were hired at 20% above your minimum starting salary with no other career avenues than management, and who are naive enough to think of options as valuable rather than lottery tickets" isn't quite as snappy or happy.

"Don't be evil." And since you have that slogan anything you do is by circular logic not evil. Handy.

[dagw]

"Hire only the best." What if the best only want to work with the best pay and the most interesting work?

That's the interesting question. The hard choice, that I rarely see discussed, is what to do when "the best" won't work for you. Do you hire the "perfectly adequate" or do you not hire and not do that thing you want "the best" person to work on.

[chasd00]

one idea is to put your candidate out of their comfort zone and ask them to get their arms around something new. Try to figure out if they have a process for teaching and improving themself. Maybe if you can't hire the best you can find someone with the potential to be one of the best.

[PopeDotNinja]

I think the short answer if higher the best you can, commit to getting better, and hoping that is enough!

[tomxor]

> What is high? Unless you've defined what that means, and everyone involved understands and agrees what that means, it's just a word.

Yes, this is the right question. I think the reason there is no generic definition is because it's subjective. The most generally applicable part of this is the differences in hiring practices at large-scale vs tiny-scale (there was an article on HN previously explaining this particular area):

The main points were google-scale can afford high salaries and can afford to cut out good candidates from the hiring process in the name of automation, so easy to automate and standardise empirical testing works for them, but not for small-scale, because you wont be able to afford the same candidate. Instead small-scale either hire for the people who fall through the cracks of large corporate structures or they hire for potential.

In answer to your question, this difference affects (or should affect) the qualities being measured... for large scale it's whatever the job requirements are, measured there and then; for small-scale it's the potential for whatever the job requirements are e.g enthusiasm, drive, domain specific interest. That's just one dimension of a company, there are all kinds of other aspects that will also affect qualitative measurement of a candidate.

[C1sc0cat]

What defines a high bar, at BT our team had a DBA whose first boss was Dijkstra (yes that one) we was the unofficial database GURU for the entire engineering centre.

But we also had some one who was even more of a GURU IBM used to ask him for advice on large Mainframe database problems.

[xxpor]

I wonder where people work where they can become a senior engineer in the first place without getting involved in hiring.

[EnderMB]

This is probably far more common than we'd like to admit.

I've certainly worked in places where they'd rather I didn't get involved in the hiring process. These kind of places often heavily relied on external recruitment, and would rather that I spend my time working on projects than potentially rejecting candidates that could do the job, but weren't up to my standard.

These aren't non-tech companies either - these are companies that deal in/sell tech as a project and/or service. Even in companies that live and die by their development team, non-technical management can run the show and dictate hiring.

[dagw]

I've been a "senior" engineer for years, in that time I've read through a few dozen CVs, sat in on 2 interviews, and had final say in hiring of exactly zero people. I suspect the same is true for at least half the senior people here, unless they also happen to managers.

[xxpor]

I'm not trying to sound accusatory, I'm just interested. Aren't you interested in choosing the people the people you're going to have to work with every day? Are managers doing interviews where they're asking technical questions?

[jcadam]

I remember myself and every other senior engineer on a team once rejecting a candidate and being overruled by management. The guy was hired and... turned out to be as useless as we thought he'd be.

[psychoslave]

Well, the person might not have been the most skilled guy around, but how hard did the team worked at integrating this person?

I mean, starting with a negative reputation in a team that felt betrayed by your arrival doesn't seem to be the best condition to give the best out of yourself.

[AtlasBarfed]

There is infinite opportunity to screw over a new hire. Just getting setup in the dev environment on any team is usually 50% undocumented and you need help from coworkers.... it's one of my least-favorite things to do on a new job.

Also undocumented in large companies: how to get ANYTHING done outside the team.

Then when it comes to reviews, especially in large companies, you are utterly beholden to whether or not your manager likes you. I've only ever seen one person the manager disliked get a glowing review, and the manager did it as a joke since they were quitting.

[roland35]

This happened at a company I worked at as well - except the rejected candidate became our manager!

[notTyler]

I certainly have sat in on interviews and think it's valuable experience for a senior, especially when you're looking to fill a particular gap on the team. I was more pointing out that this is a very generic comment around a very complex problem.

[C1sc0cat]

Why most developers never have any HR/IR training or do this in their day to day Job.

[LandR]

I'm a senior developer and have almsot zero involvement in hiring.

PRevious place I worked had probably a hundred senior developers and none of them had any involvement in hiring.

IME the only developers that get involved in hiring is architect level and Lead Developers.

[scaryclam]

At my current company we ask even juniors to get involved. Interviews are in pairs, with at least one senior person in that pair, so we can make sure each interview is as fair as possible. IMO everyone can have a valid view, and since we could well be looking for their next team mate I'd prefer to know that it's not just my opinion that gets heard. It's been working pretty well so far, and given people more experience in hiring that I hope helps them later in their careers.

[zachrose]

Maybe the idea is that the senior engineer here should collaborate on what that bar is.