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

151–160 of 694 posts

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

#151

Post by landryraccoon »

burfog wrote: post #64
doctorless wrote: post #39

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…

The difference being that the FAANG-type companies don't pay well enough to make up for the cost of living. Senior engineers seldom want to live in tiny apartments. See if you can prove me wrong: find a 10-acre lot within a half hour commute, with a large single-family home, that is affordable to a senior engineer. Alternately, make it 1 acre, but within a 5-minute commute.

> Alternately, make it 1 acre, but within a 5-minute commute.

Wait what? What city are you talking about that has a tech hub or commercial center within a 5 minute commute of 1 acre homes?

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

#152

Post by dilyevsky »

cloogshicer wrote: post #144
Game_Ender wrote: post #126

Earlier quoted context omitted.

What if Google or Facebook offer you $300k no risk, with a relatively standard work life balance. Then you have to really carefully weigh the startup equity package and how much you enjoy the respective work environments.

"Standard" work life balance is relative though. I know lots of people who don't want to work full time. This is especially true for people with family/kids (who incidentally are usually older/more experienced).

Google began allowing part time for sr engineers a few years ago. Dunno if they kept the program.

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

#153

Post by shepardrtc »

joshuamorton wrote: post #108
dleslie wrote: post #97

Earlier quoted context omitted.

You've had this condition at every job thus far. The real interview is always the work you do.

This is only true in the most extreme case. Many companies have formal procedures around firing people for performance issues. Short of hr violations or literally refusing to do anything, I can't imagine someone being fired before 6 months.

Most places I've worked at in the US have a 90-day probationary period. There's still red tape, but not as much. More common now, however, is to hire people on as contractors for 3 to 6 months. If you work out well, they'll fast-track you to becoming full-time without a second thought. Otherwise, your contract is up and they choose not to renew it. Which makes things less dramatic if there are issues.

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

#154

Post by sethammons »

tptacek wrote: post #24
gregrata wrote: post #17

Earlier quoted context omitted.

> because someone knows someone and has worked with them for a long time only And this is the #1 thing that gets a near auto-hire from me. I'm not saying don't interview them, but most interviews don't really tell you what it's going to be like working with someone. On the other hand, WORKING with someone (for a long time) 100% tells you what it's like working with someone. If someone has worked a long time with some…

I can't tell if you're saying "look at their resume and see if they've successfully worked on teams for extended periods of time" (don't do this; it's a debacle of a signal) or "hire them if you yourself have worked with them before" (this works fine but network hiring can lead to brittle teams that fall apart as soon as 1-2 people move on).

I read it as someone already with the company has prior work with the candidate and wants to work with them again.

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

#156

Post by sethammons »

rockinghigh wrote: post #98
burfog wrote: post #64

Earlier quoted context omitted.

The difference being that the FAANG-type companies don't pay well enough to make up for the cost of living. Senior engineers seldom want to live in tiny apartments. See if you can prove me wrong: find a 10-acre lot within a half hour commute, with a large single-family home, that is affordable to a senior engineer. Alternately, make it 1 acre, but within a 5-minute commute.

Living on a 10-acre lot sounds like a nightmare.

Why? I'm on 10 acres. I like it for the isolation. Just got it, so maintaining and improvements are going to be interesting and a big learning opportunity.

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

#157

Post by burlesona »

masonic wrote: post #136
burlesona wrote: post #95

Earlier quoted context omitted.

I understand what you’re saying but I think you’re underestimating how many people like city life. I work in SF and most of the people here are here specifically because they DONT want to live on ten acres in some rural place, they love that the city is walkable and dense and interesting. For most folks the issue of living in condos or apartments it’s an issue at all until they reach a certain family size. At that po…

outside of SF there is basically nothing else walkable west of the Mississippi What a sad perception.

Well, go ahead and list your examples, then.

There’s a big difference between places where you can walk (technically that’s almost anywhere) and a city that was built for walking (ie was large before cars).

On the east coast these are much more common, for obvious reasons. Places like Charleston and Savannah have a very similar feel to San Francisco. Some of New Orleans. Most of the center cities in the northeast. A lot of Chicago.

But the common thread here is age of the city and how well it has held on to its historic core. Out west there’s just not much old enough to qualify. Sure, there are some nice small towns here and there with historic main street areas. Portland, Seattle, and Boise have a neighborhood or two. But just ask the question “would you live here without a car?,” and then look at what percentage of the population does. Outside of those aforementioned bits of the country, not owning a car would make life extraordinarily difficult.

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

#158

Post by sethammons »

ChuckMcM wrote: post #125

I think the article is reasonable but it suffers from the imprecision of "senior" as many things do. What is a 'senior' engineer in a startup, or at a mid-size private company, or a large public company? All of those companies have "senior engineers" but they aren't easily swapped out for each other. These are my definitions, at a startup a senior engineer is one that is broad enough in their experience to have gone…

Why should not all those be together and be the bar for senior starting at the start-up layer? I think the only big difference is working/navigating in a small or large org, no?

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

#159

Post by franciscop »

xfitm3 wrote: post #99
josh2600 wrote: post #34

Earlier quoted context omitted.

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…

Why doesn't the gopher archetype also apply to development roles? Persistence pays off if you measure your own results. Knowing how to divide a problem is really important, even if you're great at algorithms.

While persistence is good, it has to be applied correctly. It can become the opposite problem as stubbornness, spending too much time in a small thing that is not actually that relevant because the person really wants to get it done.

More important than persistence IMHO is to know when to be persistent and when not, and those two qualities by OP seem to be quite related to it: "raw algorithmic skill" (to know whether something is optimizable or not) and willingness to say “I don’t know” when you don’t know" (seek help, get the right person for the job, etc).

Edit: I know because I was like that in the beginning; it was okay to learn e.g. micro optimizations when learning programming for fun at university, but it'd have been a big issue if I had not been able to correct it.

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

#160

Post by patio11 »

captain_crabs wrote: post #32
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?

It's a process similar to creating a minimum failing case for a regression: take a tightly scoped problem which you'd actually reasonably assign an e.g. intermediate engineer to in your company. File off the serial numbers if you need to, then start reducing all of the unnecessary scope from the production environment until you get to just the core bit that can reasonably be explored in $TIME_BUDGET.

Package that up in a self-contained Vagrant image / Docker image / whatever with all of the skeleton required to run a full answer to completion. Then, take out the full answer. Consider leaving a reduced test suite so that candidates can see if they're making progress in a positive direction.

Now write the rubric by which you'll assess candidate answers. Generally, you'll want to pick ~5 areas which are important for you and write prose describing what 0 points through 4 or 5 points are worth in each of those areas. Then, determine what a passing score is, perhaps by calibrating through running it with existing engineers at the company. And then (this is the brutally difficult part): convince your organization that the rubric now makes hiring decisions.

Then, create a way for people to submit these into your hiring process. This might be as simple as "Create a private gist of this file and email me the link" through something with material tooling developed.

(This answer may or may not be exactly the same as Thomas' answer, but we were co-founders at a company which was quite related to this problem.)

Post reply on HN