Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

When hiring senior engineers, you’re not buying, you’re selling

hiringengineersbook.com

Post reply on HN
Print view View original

31–40 of 694 posts

Re: When hiring senior engineers, you’re not buying, you’re selling

#31

Post by nicoburns »

tptacek wrote: post #3

A lot of this post seems pretty reasonable. But: In my experience, it’s fairly easy to judge technical skill. A friendly conversation about technical interests and recent projects can often be enough. Bullshit. Sounding credible in technical interviews is a skill, not the same skill as actually being a good programmer, and might even (statistically, in the large) be close to orthogonal to it. We found this out the ha…

I think this might be the best thing I've read on hiring.

As an engineer, I love work-sample tests. And I also like the insight you had, that a test should test code-reading as well as code-writing.

Some people complain about the amount of time that they take, but if you're good at what you do then you should only need to complete one work-sample. Whereas you could easily need to attend many interviews that accurately assess your skill. Some companies even have many-stage interview processes, and these definitely take longer than creating a work sample.

Re: When hiring senior engineers, you’re not buying, you’re selling

#32

Post by captain_crabs »

tptacek wrote: post #3

A lot of this post seems pretty reasonable. But: In my experience, it’s fairly easy to judge technical skill. A friendly conversation about technical interests and recent projects can often be enough. Bullshit. Sounding credible in technical interviews is a skill, not the same skill as actually being a good programmer, and might even (statistically, in the large) be close to orthogonal to it. We found this out the ha…

How did you go about creating your work sample test?

Re: When hiring senior engineers, you’re not buying, you’re selling

#33

Post by stevenjohns »

tptacek wrote: post #27
autotune wrote: post #25

Earlier quoted context omitted.

The most annoying thing is when you show yourself perfectly capable of doing the technical challenge and still get passed up on the interview because they completely ignore the results and/or then check your ability to script on a whiteboard. I’d say the work sample is a waste of time if I didn’t view it as a learning exercise.

I couldn't possibly agree more. The current cargo-culted trend of take-home problems is a scourge. If you can't hire almost directly off the results of your challenges, you're wasting time and shouldn't do them at all.

> The current cargo-culted trend of take-home problems is a scourge

I hire based on take-home problems. But then again I don't have candidates whiteboard.

I give candidates time to produce something in the comfort of their own environment that goes beyond solving puzzles on the fly and is actually a reflection of the work people will do day-to-day.

Re: When hiring senior engineers, you’re not buying, you’re selling

#34

Post by josh2600 »

tptacek wrote: post #3

A lot of this post seems pretty reasonable. But: In my experience, it’s fairly easy to judge technical skill. A friendly conversation about technical interests and recent projects can often be enough. Bullshit. Sounding credible in technical interviews is a skill, not the same skill as actually being a good programmer, and might even (statistically, in the large) be close to orthogonal to it. We found this out the ha…

Just to add some thoughts here: I’ve interviewed people who were google L7+ (IC) a couple of times who weren’t very good engineers, at least on the work sample stuff.

I’ve found that the highest correlation to performance in senior engineers is raw algorithmic skill and willingness to say “I don’t know” when you don’t know.

This is not true of hiring devops or sre’s. For those positions, you want the gopher archetype. This is the person who loves hunting down weird behavior and doesn’t give up when debugging. Let’s be real, debugging is you versus the machine and you’re eventually going to win if you can just be honest and patient.

Hiring senior engineers is really hard, I wish everyone luck.

Re: When hiring senior engineers, you’re not buying, you’re selling

#35

Post by nicoburns »

notjesse wrote: post #26
ryanworl wrote: post #13

Earlier quoted context omitted.

It does always amaze me that literally what you learn in HR 101 in an undergraduate management curriculum is controversial. The r^2 of a ton of different methods for predicting job performance is something large companies are highly incentivized to get studied by academics (and they do). Spoiler alert: work-sample tests are the only practical and generally tolerated one to use (for software engineers) that is actuall…

But it’s not generally tolerated. You end up optimizing for sub-prime candidates because those are the only ones desperate enough to take 4-6 hours out of their free time for a company that hasn’t even bothered interviewing you, yet. If they want to turn the onsite into one big work sample, by all means, that sounds very effective (and something I’ve seen work well). But in my experience, you’re going to deter qualif…

The best interview I ever had was a 2-hour onsite work sample, followed by 1/2 an hour discussing what I'd come up with. I was offered the job the next day.

Surely most people would prefer this to whiteboard tasks?

Re: When hiring senior engineers, you’re not buying, you’re selling

#36

Post by [deleted] »

mchannon wrote: post #29
tptacek wrote: post #3

A lot of this post seems pretty reasonable. But: In my experience, it’s fairly easy to judge technical skill. A friendly conversation about technical interests and recent projects can often be enough. Bullshit. Sounding credible in technical interviews is a skill, not the same skill as actually being a good programmer, and might even (statistically, in the large) be close to orthogonal to it. We found this out the ha…

When a guy tells you his experience, and you call bullshit, it's hard to tell whether you doubt his sincerity about having the experience at all or whether the experience itself was not representative of your reality. Either way, you're telling us not how it is, but how you are, and that's simply not useful. In "The Last Starfighter", the recruiter/hiring manager Centauri is constantly accused of using "the Excalibur…

[deleted]

Re: When hiring senior engineers, you’re not buying, you’re selling

#37

Post by ryanworl »

notjesse wrote: post #26
ryanworl wrote: post #13

Earlier quoted context omitted.

It does always amaze me that literally what you learn in HR 101 in an undergraduate management curriculum is controversial. The r^2 of a ton of different methods for predicting job performance is something large companies are highly incentivized to get studied by academics (and they do). Spoiler alert: work-sample tests are the only practical and generally tolerated one to use (for software engineers) that is actuall…

But it’s not generally tolerated. You end up optimizing for sub-prime candidates because those are the only ones desperate enough to take 4-6 hours out of their free time for a company that hasn’t even bothered interviewing you, yet. If they want to turn the onsite into one big work sample, by all means, that sounds very effective (and something I’ve seen work well). But in my experience, you’re going to deter qualif…

I don’t have an opinion on whether or not it is done synchronously or asynchronously and I hope I didn’t imply work-sample = take home test.

Re: When hiring senior engineers, you’re not buying, you’re selling

#38

Post by cloogshicer »

tptacek wrote: post #3

A lot of this post seems pretty reasonable. But: In my experience, it’s fairly easy to judge technical skill. A friendly conversation about technical interests and recent projects can often be enough. Bullshit. Sounding credible in technical interviews is a skill, not the same skill as actually being a good programmer, and might even (statistically, in the large) be close to orthogonal to it. We found this out the ha…

Hi, author here, thanks for your feedback. I think you might be right, thinking about rewriting that paragraph a bit.

For me it's been really obvious in interviews whether someone knows what they're doing or not. But probably I've just been lucky in this so far.

Looking forward to reading your post about it. Haven't read it yet, but if it's not in the post, could you give a few examples of what people said, that turned out to be bullshit? And the other way around, too? Not questioning you, just genuinely curious.

Re: When hiring senior engineers, you’re not buying, you’re selling

#39

Post by doctorless »

Hands down, the number one problem in hiring and retaining senior engineers is being able to match the compensation level. FAANG-type companies have a huge difference to practically everyone else. Startups, especially, can’t match the salary, and few make up for it in equity comparable to the risk level engineers take on by accepting the job. Senior engineers typically know better, and so you end up with mid or even junior applicants for senior roles, and out of desperation, they end up being the pick.

Re: When hiring senior engineers, you’re not buying, you’re selling

#40

Post by acjacobson »

dceddia wrote: post #14

I agree with a lot of the points here. One specific pet peeve of mine is job listings that refuse to nail down which specific technologies they're using. Some will say things like "Front-end web development using a framework such as ExtJS, React, Vue, or Angular". Neat - which one? I'm happy to work with 1 or maybe 2 of those. Do you mean that you actually use React but you're fine with people who come from some othe…

While this is only my experience, when I write job requirements that cover multiple languages or frameworks it really is 'any of these are fine'. The theory is that you don't want to filter out people that would otherwise be a good fit - because for the most part smart people can learn new frameworks and languages pretty quickly. You are correct that it is suboptimal for people wanting to work on a specific tech stack, but if you're not getting any applicants because your requirements are unnecessarily strict it's not in anyone's interest.
Post reply on HN