Live data from Hacker News

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

hiringengineersbook.com

401–410 of 694 posts

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

#401

Earlier quoted context omitted.

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…

> "Treat me with enough derision and pressure off the bat and I guarantee I'll fail your test even though I do fine at other companies." If only more companies realized who they are able to hire is a function of how they hire. And it starts with the job / opportunity / role description. As a side note, it seems to me, all this friction in hiring (senior level talent) makes a good case for developing and promoting fro…

If management is rude and naive enough to be bad at hiring, they can be expected to be equally bad at promoting and retaining internal talent.

For example, there's the simple pattern of ignoring employee careers and expectations until, after the least patient ones have left, suddenly there's a lack of personnel, and the best remaining people are needed in their current dead-end role.

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

#402
post #398
post #288

Earlier quoted context omitted.

This is a good post. Have been in the UK startup environment it was crazy how many companies got funding but didn't had a strong senior in their software department. Because of this their hiring process was aimed to hire more "strong juniors" even tho they didn't realize it. A strong senior is a person who completely changes how you are even approaching the problem or someone who shows you problems you hadn't seen be…

I think it's also important for seniors to look at new ideas at a regular basis. People who don't, tend to overrate the "good old [insert language/framework here]". You should not stop improving yourself, just because you are already able to get stuff done. (Example: Java introduced lambda functions in Java 8 and many Java seniors are still not using them)

I think the difference a senior person can make is to see what things the new language/framework/paradigm still doesn't solve and think of ways to evaluate their risk to a particular project's requirements and how to mitigate that risk. Things like downtime for upgrades or migrations, handling dependencies on ecosystems of community developed libraries without quality and feature change controls, the ability to update the system when it's been in production for 3 years and see few changes have been made and the original developers have all moved on, etc.

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

#403
post #50

Earlier quoted context omitted.

Again: this is true of "work sample" tests in their mainstream implementation in our industry (spend 6 hours jumping through a hoop for the privilege of running a standard, nondeterministic interview gauntlet), and those hiring processes are a scourge. But there's a right way to do it: give work sample challenges and then, at least for the most part, end the technical qualification part of your process there . You sp…

We subscribe to the work sample test as your best option for technical validation, but we also limit ourselves to a small window of time, on site. We pick something we recently worked on, distill it down to something we can knock out in 15 minutes, and give the candidate about 45 minutes to work through the distilled problem and then we explore for about 15 minutes their solution and how they would make it production…

>Part of the code we want right now requires a unit test with dependency injection to match an interface.

What exactly do you mean by this?

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

#404
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 would advice reading "Software Craftsman" by Sandro Mancuso. It contains a chapter about hiring "craftsmen" (best kind of developers).

And many things from the article check out in regards to that.

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

#405

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…

If you're asking questions related to "raw algorithmic skill" you're filtering for people who either: 1) Have had a computer science education and happen to remember the algorithm at hand. This is also a function of recency so senior engineers are less likely to remember any given algorithm. 2) Study algorithms so they can do well at job interviews. Neither one is something you want to be selecting for. Some of the b…

> If you're asking questions related to "raw algorithmic skill" you're filtering for people who either: 1) Have had a computer science education and happen to remember the algorithm at hand.

Probably true. But perhaps that could be accounted for in the assessment process. After all graduates from Neuroscience, Maths and Physics degrees have got to be some to smartest people around.

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

#406

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…

If you're asking questions related to "raw algorithmic skill" you're filtering for people who either: 1) Have had a computer science education and happen to remember the algorithm at hand. This is also a function of recency so senior engineers are less likely to remember any given algorithm. 2) Study algorithms so they can do well at job interviews. Neither one is something you want to be selecting for. Some of the b…

Agree. A lot of coding is simply banging your head against the wall, search SO over and over, changing things around, until it does what you want.

Raw algo quizzing skill isn't necessarily the same thing, though you'd think it was somewhat related because when you're learning to code up "find longest continuous run" you also need to change things around for a bit.

Difference is in real life there's never an end. The algo quiz leaves you at some optimum eventually due to being quite a small thing.

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

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

I am confused by the world you live in.

Yes, above a certain size, companies typically have some formal procedures. But typically those are a fig leaf.

In many labour markets, there's a legal 90-day probation or equivalent. You bet your boots some people get dismissed at 80 days. Or the job was contract-to-hire, and the contract doesn't "get renewed".

But on top of that, literally every company I've worked at or any of my friends have worked at (including lotsa startups, two of FAANG, and some in-betweens) will terminate when they want to terminate. In most non-European labour markets that I'm aware of, there's a penalty for doing so, and the company just pays that penalty and gets on with it.

Sometimes there's more security than that, I've heard (but not experienced). And sometimes the company puts in large effort to cultivate the underperforming employee first (had that happen to me once; they tried and I tried but it didn't work out). But the overwhelming majority of cases of my first-hand and second-hand experience, dleslie's summary is about the whole story:

> The real interview is always the work you do

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

#408

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…

If you're asking questions related to "raw algorithmic skill" you're filtering for people who either: 1) Have had a computer science education and happen to remember the algorithm at hand. This is also a function of recency so senior engineers are less likely to remember any given algorithm. 2) Study algorithms so they can do well at job interviews. Neither one is something you want to be selecting for. Some of the b…

the ability to prepare for an interview is likely correlated to the ability to do the required work, so that point is moot.

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

#409
post #272
post #233

Earlier quoted context omitted.

This reply applies to several here. I know a few architects (as in for buildings and civil structures) who wouldn't be able to pour a foundation, frame a wall, or run plumbing properly. They're working at a different level of abstraction and are concerned with different problems. Or to put it another way, if you can code does that mean you should be able to design a CPU, even a very basic one? After all, how can you…

I wouldn't expect a building architect to do a great job pouring a foundation, framing a wall, or running plumbing. But I would expect them to be able to do it, at least to a basic level. Architects that don't understand how to do the fundamentals of implementing the designs they make tend to make unrealistic designs, that are expensive to implement and may look pretty, but function poorly for the owners and occupant…

> I wouldn't expect a building architect to do a great job pouring a foundation, framing a wall, or running plumbing. But I would expect them to be able to do it, at least to a basic level.

waaaaat? That is completely utterly 100% unreasonable. Unless you mean that you expect every adult member of society to do those things?

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

#410
post #27

Earlier quoted context omitted.

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.

I think something people tend to miss is when these problems are appropriate. If you are hiring from a pool of recent graduates for a junior position, or any such situation where you have a demand for the position, then this might be a good idea as a first step.

For more senior people this kind of test might even be more appropriate, because they are not always working on exactly the same type of thing in recent memory but in their own time will come up with a good solution quickly. However, for more senior people this type of test should certainly not be one of the first steps of the interview process.

You should ideally have much shorter and simpler technical tests during the first interviews to try to weed them out while also giving them exposure to what kind of environment they can expect to be working in, but also tell them this kind of task will be coming and why you are doing it. Once they're more committed to actually wanting the position they will be more likely not mind spending their personal time doing this kind of work exercise, or you could even offer to pay for their time on it to show you are not the kind of company that expects them to do work for free.

If you don't do this, you'll only come across more senior people who are desperate enough to jump through these hoops, which is rare and you better know for sure why they are desperate.

Post reply on HN