Live data from Hacker News

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

hiringengineersbook.com

561–570 of 694 posts

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

#561

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…

I find this "salary first" a little bullshit too. For the most part it's true, but it's not strictly true. If Amazon offers me $180k but I need to work like a slave, but a startup offers $150k but is very chill, I'm gonna choose the startup.

150k is reasonable, for a startup, but the majority are offering less. However, 180k is well, well below amazon.

And the stock grants won't begin to compare.

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

#562
post #340

Earlier quoted context omitted.

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

> The difference between talking (very intelligently) and doing is huge To be fair it is environment dependent more than anything else. Forget competence, charisma, intelligence, and everything else about the candidate that could bias their selection and instead look at processes and code already in place the new candidate is jumping into. Does the environment strongly favor original ideas/solutions or does it dictat…

> Having gone through this myself it has taught me to ask very probing questions, as a candidate, during the interview.

Like what questions? I'm assuming the work you're looking for is more along the lines of "wonderful solutions" as opposed to "task completion" - is it as simple as asking, "How anal are you guys about code syntax and whatnot?" and, "How hard are your problems actually?"

Or is it more subtle than that?

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

#563
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…

To be honest, I don't think your questions were good enough to filter out the smooth talkers. I was in a senior position at a successful agency and was hired before they changed their interview style to match the eye-rolling "technical interview" that is now gold standard. I repeatedly argued they were getting too many false negatives and only a certain kind of developer with this style, but they believed "if Google…

Ask them about the challenges which they've faced when using x, y framework.

Ask them why they prefer one framework to another.

Ask them how they view testing

Walk through with them on a simple whiteboard problem and ask them where they would write test cases.

Watch for the amount of detail they give you. That will give you an indication of what kind of a developer and how deeply they go into problems.

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

#564

Earlier quoted context omitted.

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…

And then run several existing hires through it to validate.

It’s amazing how often hiring processes are built and not tested.

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

#565
post #340

Earlier quoted context omitted.

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

> The difference between talking (very intelligently) and doing is huge To be fair it is environment dependent more than anything else. Forget competence, charisma, intelligence, and everything else about the candidate that could bias their selection and instead look at processes and code already in place the new candidate is jumping into. Does the environment strongly favor original ideas/solutions or does it dictat…

Perhaps it is better to leave the menial tasks to the machines. They're far better at it - "on file save, reformat code to this template."

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

#566
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 do you get senior candidates to spend any time and effort on submitting "work samples"? I'm a senior engineer. Last time I interviewed, I received multiple offers from brand-name employers. None of them required any work samples, just hard technical interviews. A few times I saw a small unknown company that piqued my interest. I talked to them. Occasionally one would require me to do some sort of a task. Why woul…

This seems extremely off to me - from my POV who the hell has time to study algorithms and implementing data structures every time they need to find a job? Trying to make sure I can whiteboard a random CS problem from a massive set of potentials on the fly in front of observers is drastically more involved and requires much more time that serves no other purpose than facilitating interviewing, versus just spending an hour of my time programming a solution to a problem at home.

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

#567
You need to ask open ended questions and expect detailed answers that only an experienced engineer would be able to answer. And keep asking more and more details. Only another experienced engineer would know if that are bsing. Most companies put way too much on whiteboarding. Failing whiteboard guarantees you lose the job seem to be very inefficient.

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

#568
post #283

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…

I hear what you're saying, but I think you're maybe creating a straw man argument here. A smooth talking engineer isn't one who sounds like a used car salesperson or is just hyped about the latest trendy framework. There are people who can talk through challenging problems at their former companies and how the problems were solved. They can tell you everything you'd want to hear because it's true. Except…they didn't…

These problems are very simple to solve. Get them to go into detail. Get them to explain their thought process while looking to solve the issue.

If you feel that they're talking about a problem someone else solved, ask them that directly. (Did you work with others? etc) If they're lacking on the technical details either it's been a long time ago or they didn't do it.

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

#569

Earlier quoted context omitted.

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

What happens if they can't work from home? They're expected to take time off, AND prepare beforehand?

What round is this?

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

#570
post #283

Earlier quoted context omitted.

I hear what you're saying, but I think you're maybe creating a straw man argument here. A smooth talking engineer isn't one who sounds like a used car salesperson or is just hyped about the latest trendy framework. There are people who can talk through challenging problems at their former companies and how the problems were solved. They can tell you everything you'd want to hear because it's true. Except…they didn't…

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

Unless they were pair programming through that problem. They can't and won't. They won't have the hard lessons that it brought.
Post reply on HN