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

481–490 of 694 posts

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

#481

Post by sethammons »

tpxl wrote: post #403
sethammons wrote: post #147

Earlier quoted context omitted.

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?

We ask that the code they write have a unit test. The nature of that unit test is that it has a dependency. They can mock however they like, but passing in an object that represents the dependency (dependency injection) is the easiest and most straight forward way to do that. That object should have a method on it (a know method, with a known signature, also known in some circles as matching an interface).

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

#482

Post by nailer »

jcadam wrote: post #461
AznHisoka wrote: post #139

Earlier quoted context omitted.

I can’t overemphatize how much persistence really paid off in past jobs I had. Coworkers that had persistence were such a delight to work with because they didnt give up the first time they got stuck. They did the nitty gritty work of tailing/grepping logs, using a debugger, endless Googling, print statements, and anything to find out the root cause of a bug... or even to understand a legacy codebase.

I've done that sort of work. Eventually you realize that nobody notices the guy who tracked down and killed that vexatious heisenbug in the legacy code base. You need to be working on the new, shiny, high-visibility projects or your career is going to stagnate.

Or change the culture.

Friday demo day (to sales and cust success and everyone else): "hey everyone, know that thing customer X keep complaining about that we've never been able to solve? It's been super tricky. Just wanted to announce that James here figured it out and it's fixed forever. James you're a hero."

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

#483

Post by dkersten »

unclebucknasty wrote: post #354
droithomme wrote: post #344

Earlier quoted context omitted.

It's a highly effective and quick disqualifier. 100% of those that couldn't do it are not qualified candidates. Some of those that could do it are good candidates. When you bring in someone that has a nice looking CV and experience and recommendations and you ask them a very basic question and they can't respond at all, it is a safe disqualifier. It also doesn't take six hours.

> 100% of those that couldn't do it are not qualified candidates. OP stated nearly the inverse: that 90% of those who can do it are qualified candidates.

So you discard 100% of those who can’t do it, knowing that 90% of the rest are qualified.

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

#484

Post by dkersten »

Tharkun wrote: post #390
flipactual wrote: post #212

Earlier quoted context omitted.

I don’t know what your work-sample looks like, but unless it’s time actually working with your team on a real project, it gave you no indication of whether or not someone was “capable of delivering” You may think you filtered out people who failed your test, but you have no indication that that’s the case – you could just as easily have filtered out people who don’t like tests or people who don’t test well I trust yo…

> but unless it’s time actually working with your team on a real project.. I've ranted about this before on HN, but that's very much illegal in my neck of the woods. As soon as someone does useful work for you, they're an employee. YMMV but you can't expect new candidates to do actual work until you've hired them. There are plenty of programming assignments, exercises or questions you can have them do instead.

So have a basic filter, hire based on who meshes well with the team and have a trial period during which they actually get evaluated for competence. They’re technically an employee during the trial period, but with the understanding (and contractual agreement) that they will be evaluated at the end of the period and that the employment will be terminated if they do not meet the criteria.

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

#485

Post by dkersten »

BrissyCoder wrote: post #422
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…

Totally agree. I suck at interviewing and freeze up on the spot. Even on-site coding tests I'm not great at. Give me the time to sit back in my own comfortable environment and I'm confident I can solve 95% coding problems (and reasonably quickly). I've been involved in a lot of hiring and I always advocate a choice of a couple of fairly in-depth (maybe 4-6 hours) take-home coding problems. I think people should be pa…

I’ve got a friend who is a lot like you. I’ve worked with him, so genuinely know he’s good, but he sucks at interviews. He freezes up and can’t answer simple technical things, things he knows and has successfully done often. Some people simply suck at interviews.

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

#486

Post by sethammons »

swish_bob wrote: post #416
sethammons wrote: post #301

Earlier quoted context omitted.

Interesting. To clarify, you are saying that these boiler-platey languages, it is not fair to write a unit test in a 45 minute time block with access to Google? I'm not a Java guy. All the languages I've used, this would not be an issue. Again, I'm wrestling with it because it I feel it should be easy but like 80% of our candidates who chose Java struggle with it.

I guess it depends how far back you're starting from. I suspect most Java developers don't spend that much time creating projects from scratch (I do, but the work environments I'm used to suggest I'm an outlier). I tend to give candidates a simple project already to go, with junit and hamcrest, possibly mockito already available, and ask them to go from there using a provided IDE (which I attempt to get set up as nea…

It starts from scratch. Familiarity with one's tooling is important. Setting up a project seems like it should be part of the basics. Would it not be unfair to others who choose a different language if Java gets hand holding in terms of initial classes?

For 20% of Java candidates, they do it just fine. Heck, a few echew the IDE and are fine working completely from the terminal (these tend to be particularly very solid at coding). Still wrestling with the idea.

The folks that already work with us (who wrote Java in a former role) see no problem with setting up a project nor do the folks that we hired recently (seeing as they likely passed that technical interview). But that all could be bias.

Maybe you are right. Maybe the next candidate or five in Java will get a base project and we can see how it goes.

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

#487

Post by tjpnz »

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've turned down roles in companies that took this approach to hiring. It raises a massive red flag in my mind on the organizations technical pedigree and the sorts of people I would be working with.

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

#489

Post by mgkimsal »

aprdm wrote: post #288
austincheney wrote: post #177

Earlier quoted context omitted.

I disagree. If you can’t tell the difference between a smooth talker and strong technical competence you are probably interested in the wrong qualities. I have interviewed enough now to see why some companies cannot figure it out. Ask yourself if you really actually want a senior or a strong junior. It comes down to interest. A good senior got that way because they like solving challenging problems. They are not inte…

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…

There's times when i think i'm coming across as the bullshitter. "Tell me of an accomplishment you're proud of". I struggle with this one, but I've given this example years ago.

Worked at a company which did nightly data imports. Things worked until 'companyx' became a cEient, and the imports were huge. They would take 18-20 hours. Then longer. eventually they were touching the 24 hour mark - unacceptable. Client's data would be more than a day behind. Granted it was a moderate amount of data, but shouldn't take that long.

I was 'new' there - only started a month before - and the rest of the team who'd put this together had been there a year or more. I reviewed what was in place, took a couple of days, and got it down to an hour. Then worked with the existing team and we got it down to under 30 minutes with some tweaking.

I do see some eyes rolling when I tell that, as I know it can sound terribly self-aggrandizing. However, I had a decade of experience at this point, and the rest of the team was just out of college; they'd never faced this problem before. I basically just took the data and imported in small chunks in to in-memory tables (to avoid hitting the disk), and copied those to disk every X rows, and dropped indexes until everything was done. It wasn't rocket science, but did take someone who had a deeper understanding of DB mechanics.

As I'm telling this, I always realize they have no way of verifying this, and essentially I'm just another bullshitter. The more believable I sound, there's an equally high chance I'm either really good, or just a really good bullshitter, and nearly every time, the person I'm talking to has no idea how to tell the difference. It's worse as you get older, because the younger folks just think you're waxing nostaligic about the 'good old days'.

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

#490

Post by [deleted] »

aprdm wrote: post #288
austincheney wrote: post #177

Earlier quoted context omitted.

I disagree. If you can’t tell the difference between a smooth talker and strong technical competence you are probably interested in the wrong qualities. I have interviewed enough now to see why some companies cannot figure it out. Ask yourself if you really actually want a senior or a strong junior. It comes down to interest. A good senior got that way because they like solving challenging problems. They are not inte…

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…

[deleted]
Post reply on HN