Hacker News new | ask | show | jobs
by lessnonymous 4895 days ago
As a hiring manager, the thing I find most interesting on posts like this (ignoring that the analogy is TERRIBLE) are the comments of people used to being on the other side of the desk. I don't think we (as interviewers) do a good job of explaining why we ask the questions we ask. And I don't think we do a good job of communicating what our job is.

Our job is to stop you getting hired.

If we get 100 people applying for the job, then our job is to not employ at least 99. So we are looking for anything that identifies you as being one of the 99.

That you could go away and learn what color the middle wire is is great. But the guy next to you has been fixing wiring in distributor caps for years. And right now, I need people that know what color the middle wire is.

8 comments

The point is that the guy who can fix wiring in distributor caps might be able to do that specific task. But maybe it took him 5 years to learn that and a much better candidate who has no clue how to do that could master it in a week and will be fixing those caps at a higher quality.

It's also that it's incredibly short-sighted to seek such specific skills in the technology industry with the rate of change in tech.

Further, maybe the guy who can fix distributor caps came from an agency that coached him on writing his resume to emphasize this and what to prep for in the interview. I've experienced that first-hand.

The problem with the analogy is that it's too specific. But I'm still hiring for right now. That you can easily learn next year's technology is something I'd rather you don't do on my time.
Then you are the one being short-sighted here. A good engineer is a good engineer is a good engineer, someone with great learning aptitude is a great asset for any company. Say you hire someone for today's task, but next year the technology changes and the guy you hired is horrible at learning new things. What do you do? Do you fire him and hire someone for next year's task? What if the old technology still requires backward support, do you keep the old guy on payroll as well? What if the same thing happens the year after next?

You don't want people to learn on your time? That's incredibly short sighted. Real engineering is about learning all the time, whether it's taking a formal training session or just reading a long post on StackOverflow. If you don't want to pay your engineer to learn things then you simply don't care about the engineering quality of your company and all you care about is short term payroll bottom-line.

I feel sorry for the engineers who work under you.

Of course I'm looking for people who can learn. I'm looking for people who will jump onto Stack Overflow and Google before spending a week reinventing the wheel. I'm looking for someone who writes in a dozen languages (like human languages, someone who knows a couple can pick up more very easily).

But I don't want people learning the "right now" skill on my time.

If I need a PHP developer right now, then I'm going to hire someone who knows it right now. I'll preference someone with C skills and I'll preference someone who participates in an open source project. And I'll preference someone who reads Hacker News. And I'll preference someone who has a great profile on Stack Overflow. And I'll preference someone who attends or presents at conferences.

But if they don't know PHP, they're not going to be learning it on my time as I need someone who knows it right now.

There's no need to feel sorry for my team. The things you read on a Hacker News comment reply aren't the entirety of working for me. Maybe you'll be sitting across the desk from me one day and you'll get to work with an awesome team of talented engineers. Carefully selected.

A lot of engineers will gladly work overtime or at home to pick up a skill. Often you don't start a new job for a few weeks or month.

And any good engineer can work blind on a new technology and still produce decent results. If a great engineer with no knowledge of PHP is required to build a PHP website they can sit down with a PHP book open on their desk and crank it out. They fact that they're mentally superior to other engineers (whose expertise on a narrow subject might be better) and know programming inherently better means there's a good chance their output on something they don't know could be comparable to the PHP coder.

The best managers always build skills in teams. It's part of compensation. Every engineer views bullet points on resumes as a form of income. "If they don't know PHP, they're not going to be learning it on my time" means that you're going to be paying higher salaries with higher turnover and much higher recruiting costs. And if that's not true then something scarier is true: you're actually hiring low-quality engineers who don't realize you're a bad manager with a bad team (or who have no other options than to pimp out their 8 years of SharePoint 2003 experience).

Maybe you wouldn't have such an urgent need to hire experts in narrow subjects if you had staffed your team with intelligent quick learners in the first place! Tip: next time you need an expert in subject X try telling your best engineer: hey I have a project coming up for an X project and I'd like you to play a key part, so can you study up on that as it'd really impress me.

"Maybe you'll be sitting across the desk from me one day and you'll get to work with an awesome team of talented engineers. Carefully selected."

What an arrogant prick.

Then don't complain that you can't find any candidates.

That's what you employers do: you filter out everybody, so there are left like 3 people in the same continent who fit your arbitrary criteria. Then all of you get into a bidding war over those 3, and most of you find that you can't afford to hire.

Finally, you start whinging about a "talent crisis" and blaming the universities for not producing people with the right skills.

Well you made your beds, now lie in them.

Where did I complain about not finding candidates? Where did I whinge about a 'talent crisis'. Nowhere I'm aware of.

At a guess you're projecting other managers complaints on to me. I'm not in the U.S. and don't have these problems.

So you've got actual words from actual me:

* Those three people are worth the bidding war. They're worth 10 times the next rung down.

* I need to fill the position with the best possible person. It doesn't matter that Google et al have take the top people, I still need a new engineer.

* Universities generally suck time and deliver little. Spend the three or four years getting a ton of experience and participating in the community and you'll jump ahead of someone who's passed university, but doesn't have their own project.

"They're worth 10 times the next rung down"

So you will pay 10 times more salary, rather than waiting a couple of months for a new engineer to get up to speed? You must be in a hurry. What about all those other employers doing enterprise CRUD apps, are they in a similar hurry?

"I need to fill the position with the best possible person"

I assume then you are not working on enterprise CRUD or dinky mobile apps like everybody else. Are you competing with Unreal's next game engine? Or working on a rocket to Mars? Because your peer employers are NOT.

Yeah, those guys who complain about not finding candidates.

I wont pay 10 times as much, but I'll pay a premium.

And someone else getting up to speed wont make them the best person for the job. It will make them adequate.

"That you could go away and learn what color the middle wire is is great. But the guy next to you has been fixing wiring in distributor caps for years. And right now, I need people that know what color the middle wire is."

If you're hiring a mechanic, yes. However, the analogy was pointing out that the person being asked the question was a potential car renter. That specific knowledge is not relevant as a car renter.

Now you're torturing the analogy. The equivalent programmer translation is "What is the middle parameter to this library method?" I'm sure most people competent at using Google can tell you in 60 seconds what that parameter is. In a large enough company you can afford to take the productivity hit as someone who is "smart and gets things done" gets up to speed on a new technology or with new libraries. However, if you're in a small team and you need to execute on your business fast without holding up development, you want someone who is "smart and gets things done" and also knows that library inside out.
Yes, the analogy is silly.
Actually, I think you misunderstand the analogy. The color of the middle wire on the distributor is something you'd like a prospective mechanic to know, so he isn't learning on your time. It isn't, however, something that is in any way relevant to driving a car. I think this is why your comment provoked such hostile responses.

The programmer equivalent of the middle wire color question is something like, "Is the 3-phase power supply on XYZ mainframe wired in a delta or wye configuration? As a followup, what is the input frequency tolerance?" A sysadmin might need to know that, and an electrician certainly would, but it is far, far outside the purview of a programmer. [Edit: I'm assuming the programmer to be someone writing software running on the mainframe, not the firmware for a microcontroller in the power supply]

Maybe you're just a very good interviewer and haven't had to deal with the 90% that are crap? :+)

This illustrates why it's a terrible idea to work in a large corporation where the hiring process is managed by an HR department. The process is optimized for filtering out people. The reason why the job postings and interview questions seem to expect unrealistically high standards has nothing to do with the actual jobs requiring any of those high standards. In reality those jobs tend to be very dull and standard.

Tech start-ups and good engineering teams ask a different question: "What value this talented engineer can provide to our team or product?" Their job is not to stop people getting hired. Their job is to convert the available Human Resource to economic value as much as they can.

As far as I know hiring decisions made only by HR departments don't perform any better than randomly hiring one of those 100 candidates. Actually random is better if you really need the absolute best candidates because HR process has a high risk of filtering them out at the initial stage carried out by a clueless junior HR staff. But it's OK for the HR's sake since their actual purpose is to stop people getting hired.

"Our job is to stop you getting hired. If we get 100 people applying for the job, then our job is to not employ at least 99. So we are looking for anything that identifies you as being one of the 99."

If you have only position to fill and 100 people applied for that position, yes, your position makes sense. But if you have 100 positions to fill, will you still insist that you must interview 10000 people to fill those positions?

If you're hiring 100 people, you still only get the same number of applicants. If you get 100 applicants, you're not going to fill your 100 positions. (Note the "at least 99" in my post)

If I'm desperate to hire 100 people and I can't get 100 qualified applicants, that's when I start looking to people who could be the right people in very quick order. I've done that and ended up with some true super stars. But that was a three month investment that could have failed. I'd rather hire someone who already has the skills I need.

Whether you're hiring 1 person or 100, you're still looking for reasons to cull them.

I think this reveals some of the root of the problem. The interviewers have no incentive for hiring good or great people ("superstars"), but absolutely cannot let crappy applicants inside, under no circumstances, under the risk of losing their jobs.

So they just don't care if you are good at what you do, if you can learn fast, etc -- all they care if whether you are not shit and can certainly fulfill the specific requirements for the job they were instructed to fulfill.

How to change this? Well, one way would be to get people interested in the applicant's abilities and long term capacity and commitment. It's good to find this kind of people inside a company which are not in the higher ups. Another alternative would be to attach the long term success of the applicant to the ones responsible for hiring somehow. Those are all very difficult problems, but ones that can be managed with good will and commitment from the guys inside the company.

"Not shit" is the way we get rid of 90% of people. "Superstar" is how we hire from the remaining.

We absolutely cannot bring in someone crap. Our job is to hire, so if we're hiring crap people, we're crap at our job.

See my comments elsewhere in this thread regarding learning fast, but basically I'm going to hire someone who can learn fast. But primarily I'm going to hire someone who doesn't need to learn the 'right now' skill.

I'd love to see a system that tied each of my hire's success to my success. It happens for the first three months: "Hey lessnonymous: this guy is brilliant! Good job!".

But I want to see a system where each pay-rise or promotion the engineer ever gets is recorded against my success too.

"We see your hires got a salary increase of 10% on average. Here's your 10% increase." (It would need to be waaaay more complex than that to look at churn, promotions, firings etc.)

There is the option of NOT changing it but switching to a better job than tech
First off, not sure how your company does it, but I've had companies ask me to interview when I wasn't even looking, and then not extend an offer. So interviews are not always to separate the wheat from the chaff.

Second, the gist I got from the "color of the wire" question was it was an analogy for asking someone to write code for a linked list. It's banal and been done before, so it seems ludicrous to ask, but many places use it as a FizzBuzz filter. I can think of very few places that would actually pay someone to "fix the wiring distributor cap" (write linked lists).

First point has nothing to do with my company in particular. Talent interviews are just different from vacancy interviews. In a talent interview I really am looking for someone who meets our future needs. And without my crystal ball, that means I'm looking for someone with the currently require skill set, but who has the ability to pick up wherever we go in the future.

Agree with you on the second point. This comes into us not explaining ourselves very well. Questions like this ARE banal and ludicrous. But FizzBuzz filters are a great first screening. People lie (shock! horror!) on their resumes all the time. So asking them to write something banal in front of you is annoying for the people who can do it, but quickly finds the pretenders and lets me cut an interview short.

(Oh, and before anyone calls out 'interview pressure', I'll work through the problem with people who struggle. The difference between nerves and talent is blatantly obvious)

> That you could go away and learn what color the middle wire is is great. But the guy next to you has been fixing wiring in distributor caps for years. And right now, I need people that know what color the middle wire is.

And more often than not there is absolutely no relationship between the color of the middle wire and knowning how to fix the distributor cap.

"Our job is to stop you getting hired."

So then, by definition, you have perfect employees. Congrats. I'm sure this extends to the perfect sales team, perfect product team, etc. That is impressive.

So this means you hire people for specific tasks, and when new task comes, you fire them and go looking for new people for the next specific task. seems like a very good strategy...
Please read my other replies on this thread concerning this.