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

521–530 of 694 posts

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

#521

Post by swish_bob »

sethammons wrote: post #486
swish_bob wrote: post #416

Earlier quoted context omitted.

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 soli…

It depends on context as well. Where I currently work, they wouldn't have a chance. The corporate firewall will prevent them talking to Nexus, for example. It just wouldn't be fair to expect them to navigate that sort of thing in an interview.

In general, if I'm asking them to code on my (or the company's) hardware, I'd start from an existing project, if only because I wouldn't expect them to be familiar with the installed tools (oh, you use maven? I'm a gradle user ... etc.) On their own laptop, I'd expect them to be more comfortable.

I'm doing a remote interview on Wednesday. That'll be on the candidates machine (because screen-sharing is easy, getting them inside the corporate network, not happening), and they've been told they'll need an IDE ready to go. I'll expect a project set up and ready to go before the call even starts.

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

#522

Post by felipeerias »

mgkimsal wrote: post #489
aprdm wrote: 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…

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 d…

It doesn't help that in our field the context for many of these past achievements is quickly lost and forgotten.

You can't just say "I did X in Y by using Z": you need to begin by explaining that once upon a time there used to be a thing called Y, and on that thing it used to be very hard to achieve X, but in those ancient days there was also a tool called Z, etc.

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

#523

Post by throwawaymath »

Ntrails wrote: post #514
treypitt wrote: post #412

Earlier quoted context omitted.

If they understand their friend's work deeply, doesn't that imply they've done something comparable themselves?

There is a huge gulf between being able to follow a thought path and being able to find it oneself. I couldn't do the same work in the same timescale as them, I wouldn't make the same decisions or spot the same pitfalls. I am simply not as good. But I spent a bunch of pub/work time discussing it and could project an aura of authority on the projects if I wished. Look at it this way. I was able to understand all of th…

Yeah, that's a great analogy for the core problem.

Imagine putting a math problem in front of someone and asking them to solve it. They correctly identify it as a system of linear equations. They volunteer that they would solve it using x algorithm which has a time complexity of y.

Then you ask them to actually solve it, and they can't even make the first movement towards doing so. They mentioned LU decomposition, but they can't even do Gaussian elimination on paper. They don't know what elementary row operations are. They can't obtain an augmented matrix or put it into (reduced) row echelon form. They don't know anything about linear independence or the rank of a matrix. You put an inconsistent system in front of them and they keep banging away at it, determined to find a solution...etc.

That's what it's like interviewing one of these senior engineers. It's surreal - they confidently pattern match the problem using limited heuristics, and they toss away low hanging fruit to demonstrate knowledge. But when you ask them to do something practical and specific, they either refuse and zoom out into abstract-land again, or they hopelessly fail.

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

#524

Post by watwut »

austincheney wrote: post #177
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 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…

You recognize good senior by not being interested in new technologies and things that makes the job easier? That is a bit dubious.

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

#525

Post by swish_bob »

sethammons wrote: post #486
swish_bob wrote: post #416

Earlier quoted context omitted.

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 soli…

> 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?

Also, how much of their day-to-day work is going to be setting up new projects? I sometimes feel a better test is to be thrown into an existing code base and asked to make a change. It's far more indicative of the sort of work somebody is likely to actually be doing.

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

#526

Post by lelima »

dkersten wrote: post #485
BrissyCoder wrote: post #422

Earlier quoted context omitted.

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.

I think practice help with this "Some people simply suck at interviews".

If you practice at home, after work, try with other companies before applying the ones you really wants and you will improve your interview skills by a lot.

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

#527

Post by PaulHoule »

austincheney wrote: post #177
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 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…

I have been amazed at how many "data science" interview questions can be answered with "look it up in the hash table" or "look it up in the literature".

That last one is a real problem-solving strategy, I can't tell you exactly how to balance a Red-Black tree but I know what a Red-Black tree is and where to look up the algorithm for balancing it and I think that's good enough.

One of the master skills for interviewing is "don't choke." Often good people will make mistakes under the pressure of interviewing and will drop out.

When it comes to a practical session there is the same issue that some good people will choke. Just the sample of who chokes in which environment when is different.

Issues like this turn up in all cases where people try to measure merit. For instance, it is known that some low-SES (socioeconomic status) people will choke on standardized tests like the SAT or IQ tests. It is also known that some high-SES people are as dumb as posts and will have that revealed by standardized tests which are harder to bribe or bullshit.

The hostility towards testing is explained by the combination of those two groups: primarily the Emperor doesn't want you to see they have no clothes, but people have sympathy for poor people.

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

#529

Post by commandlinefan »

fipple wrote: post #340
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…

No. The difference between talking (very intelligently) and doing is huge, and a sports analogy might be illustrative. If you ask detailed questions about football to hire a NFL quarterback, your most intelligent responses will probably be from a coach. “How should you change the position of your right shoulder if you see that a fast edge rusher is approaching you from the left side and you have two open receivers?”…

> hire a NFL quarterback

That analogy highlights what’s irritating me about this post and this entire thread discussion - there are 1,696 players in the NFL, each with an average salary of $1.9 million. When people talk about hiring “senior engineers”, they behave as thought they’re auditioning an NFL quarterback - the 1 out of 100,000,000 people who can actually perform at that level. For a salary of, on average, about $100,000. When you start out - offering comparatively little but looking for Tom Brady, you’ll pass over pretty much everybody, because the person you’re looking for won’t just not interview with you, they probably don’t exist. After a few months, you’ll relax your standards, and after a few more, you’ll relax them even more and end up hiring a comparative retard like myself - somebody with only a mere 25 years of hands-on development experience and a bachelor’s and master’s degree in CS along with a couple of publications. But if I presented in the first few rounds of interviews, back when you were looking for the guy who could derive the tortoise and the hare algorithm in 30 seconds in front of five people in a boardroom, you would have passed.

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

#530

Post by ajcodez »

antibland wrote: post #324
ajcodez wrote: post #118

If you pay low to mid six figures remote then you’re back to buying talent instead of selling opportunities.

Can you elaborate?

In the article the author says there is more demand than supply for senior developers. I’m saying if you hire remote and pay a decent wage there is more supply than demand.
Post reply on HN