Live data from Hacker News

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

hiringengineersbook.com

621–630 of 694 posts

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

#621

Earlier quoted context omitted.

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.

>And the stock grants won't begin to compare.

If you're counting stock separately, $180k salary isn't well, well below Amazon. That's the max they pay, and only in Seattle and the Bay Area.

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

#622

Earlier quoted context omitted.

> 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 before. I think this is overstated. Disruption for the sake of it is often not that helpful in the context of the business (although, in fairness, you do go on to state they often see tech in that context). I much prefer people who are delivery focused to those who are overly…

> I much prefer people who are delivery focused to those who are overly idealistic or want to change everything out of the gate Do you have problems to solve or not? Often the problem isn't really a problem, except that your current 'solution' is making it so. I've untied a lot of gordian knots in my career. It really is a thing. And if you don't have big problems to solve, why do you want a senior developer then? Ju…

Great post

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

#623
post #612

While the definition of senior engineer is a bit squishy, I agree completely that as some one gets more senior they increasingly choose the company rather than the other way around. I'm soft-launching a product to help companies recruit and I've done about a dozen customer development interviews with hiring managers (5 person companies through FAANGs) in the last two weeks. One thing I heard constantly was that refer…

Whew, that is a hard thing for me to read, it actually really bummed me out (apologies if this comment winked in and out of existence...wanted this to not be one giant blob). (Bear with me, gonna anxiety dump a bit here ;) feel free to skip to the end where I have a pertinent question...=) ) Background: I've worked as a high-level contributor both at the management and engineering levels for the last decade of my car…

Sorry to bum you out. That's not my goal.

As one becomes more senior the hiring manager expects a candidate to do their due diligence and ask some questions beforehand rather than hopping right into the application process. For a referral, that has already happened somewhat as the candidate already presumably talked to the the referrer about working at that company. You don't have to be a referral but a hiring manager expects you to do this due diligence. You don't necessarily need to go through a friend and you don't have to work with your friends. However, having an acquaintance at the company even in a different team is a massive help.

Think of it from the company's perspective for a second. They don't want somebody who just "wants a job". Money is always a factor but if somebody takes a job solely for money then they'll jump ship the moment somebody offers more. Companies want somebody interested in their space who wants to work there. You mentioned that you purposefully pursued some roles that looked like they'd be good fit for you. That's smart! Make sure the hiring manager knows it. By just clicking apply on the website, that may not be communicated clearly.

Here's two concrete pieces of advice:

- Before going in the front door and applying for roles, reach out to the hiring manager and ask them some more details about the role and what working for the company/team is like. If you know somebody at the company who can put you in touch (even if it isn't the same team), that's better, but even if you don't that's ok. They will talk to you and if they don't you probably don't want to work there anyway. LinkedIn is useful for this.

- If you're applying for a local job, try to meet the hiring manager or somebody else at the company in person if possible. Don't stalk them but to give you an example, I know that a CEO for a local security startup runs the local OWASP meetup and I told a person interested in working in security to go to the meetup and talk to him if she was serious about working there. I've been a hiring manager before and I looked way more closely at any candidate I talked to in person. Don't sound desperate but show them that you're interested and serious enough to go out of your way to talk to them. I had a couple candidates who I didn't know reach out to me via Meetup.com for roles posted to the company website and I had no problem meeting them for coffee.

On a related tangent, I help organize a local meetup and I get asked the question "how do I land my first dev job" a lot. I've helped half a dozen people land their 1st or 2nd tech job. Assuming they already have tech talent, I essentially offer them the above advice. It works at that level but it works for senior roles too! As a hiring manager, you want to talk to qualified people about your open role.

Good luck!

Edit: formatting only

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

#624

Earlier quoted context omitted.

It sounds like this is a pick-your-own-language type test. I'd suggest scoping down to one, or at most, two, simple allowable options that your team is already pretty comfortable handling. I've been on the reviewer side of a handful of "choose your own language"-style take-homes recently and found that it's really not good for the candidate if they actually end up using something that wouldn't have been the interview…

The theory with pick your own language is they should be able to feel fully comfortable (interviews are already stressful enough). If they picked Rust, Scala, or a lisp dialect, (or anything the interviewers are unfamiliar with), it can even be a better interview because we get more insight on how the candidate communicates and their ability to walk someone else through their solution. A potential other bonus is less…

> The theory with pick your own language is they should be able to feel fully comfortable (interviews are already stressful enough).

Ah, but there's the rub. Candidates are trying to please the interview panel. If you don't provide guidance, the odds that they'll just use whatever they think the interviewers most prefer are just as good, if not better, than the odds that they'll actually use whatever makes them most comfortable.

You said yourself that since some candidates pick a language that you don't know well, you can't really tell if the failure of a large number of those candidates is reflective of a bad test or just a mismatched candidate pool. IMO, if you're going to stick to the "pick any language" thing, you should at least find out and ensure that any language the candidate picks will have a fair shot.

> it can even be a better interview because we get more insight on how the candidate communicates and their ability to walk someone else through their solution.

You can still get the candidate to communicate and explain his choices if you give an option: "either Ruby or Python" or "either JavaScript or Visual Basic", etc. The problem with having this happen in a language that the interviewers don't know reasonably well is that they are much more vulnerable to the smooth talker who can present incorrect information confidently, and they won't have enough background/anchoring in the subject matter to know the difference.

> A potential other bonus is less biases leak through from an interviewer on "that is a strange way to do that in language X."

I would say that if you're worried that interviewers will load in biases toward their preferred shortcuts etc in a specific language, that you should be equally worried that some good candidates are being excluded for choosing the "wrong" language in an any-language-goes test.

Above, you mentioned that there'd be a positive response if a candidate used "Rust, Scala, or a lisp dialect" -- these are all relatively trendy. What if the candidate used nim, Pony, or some other language that hasn't pulled in to the hype superstation yet? What if the candidate used a language that's not-so-trendy anymore, like Visual Basic, Cobol, or bash? What if the candidate used a programming language of their own design, and brought a copy of the compiler with them on a flash drive?

I'm asking because I've seen this in practice. Candidates for a devops position who chose to use bash to implement the very simple take-home task they were given were laughed off by several other members of the interview committee, despite being potentially high-value senior people -- they were at least senior enough that they're more comfortable performing sysadmin-style tasks in a shell, rather than using a massive CM framework or an awkward amalgamation of Python scripts running os.spawn.

It feels like this type of thing happens a lot, in the same sense that very often, "unlimited PTO" just means "guess whatever amount of PTO is acceptable around here and hope you get it right".

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

#625

Earlier quoted context omitted.

I gave an example of one of our erstwhile technical interview questions below. Batting around interview questions is a hacker sport and I've met dozens of developers who delighted in relaying and evangelizing their preferred questions. I'll admit, candidly, that "what's your favorite tech stack and what don't you like about it" --- a question you can literally just look up blog posts on, and a question I feel I could…

"a question you can literally just look up blog posts on, and a question I feel I could answer credibly for several languages/frameworks I don't even know" Really? You mean you could memorize a blog post for random languages, go into an interview and answer a question and not completely fall apart from follow up question 1, 2, n?... You make it sound like I'm asking this question, getting a monologue response and jus…

> Really? You mean you could memorize a blog post for random languages, go into an interview and answer a question and not completely fall apart from follow up question 1, 2, n?

To me, this is the crux of why I agree with you, rather than the questions themselves. Anyone can rehearse an answer to any question, but a dialogue needs to be created in order to actually find out anything about a prospective hire's competencies.

To be useful, an interview needs to be a conversation, not a monologue.

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

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

Maybe this is unique to sports? Do other fields exist where a BB-esque expert is totally incapable of practicing? The greatest movie critics probably can't direct or write for crap, but they're not commenting on how the movie was produced, just its output

From what I have seen, most of the academic research principals in computer science are not actually practitioners anymore. They are more like coaches. The actual code is written by graduate students, and most of it isn't even very good because the code isn't the point in most cases.

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

#627

Earlier quoted context omitted.

> It's not like we were asking candidates "hey, how did you enjoy your last software security job?". We were doing something closer to "here's a piece of code with a heap overflow in it; talk us through how you'd write an exploit". It didn't work: there were people who could answer those questions indistinguishably from an exploit developer who nevertheless couldn't write a 1995-era stack overflow exploit if their li…

I mean, I've seen very technically proficient devs fail to deliver because there's too many cooks in the kitchen, or because they drown themselves in tooling or bikeshed their project to death. Maybe something like that happened? There's definitely tons of senior devs out there that care way more about linting and unit testing than they do about writing the code that implements the spec.

Nothing hit quite as hard as the punch to the gut from the bit about linting and unit testing... spot on. I've already decided to move on and such, but my current company is so this that it hurts.

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

#628
post #457

Earlier quoted context omitted.

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…

> 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. I don't find myself in these situations nearly as often as I did back when I was a junior engineer. But damn, I'm sure I looked busier (and more stressed out) back then.

I was mostly through that phase of my career before any of those things were available. Toward the end of it, stack overflow had just launched. I mostly relied on printed books for help with languages and frameworks I was using.

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

#629
post #166
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 recall an interview I was brought into early in my career to talk with someone being brought into be a senior architect... in my mind this meant this dude must be crazy smart right. Everyone in room had all basically made up thier minds and loved the guy. I gave a variable like a = [1,2,4,8,9]; And asked if he could write a loop and print out the values of each element. He embarrassingly could not. I always ask thi…

Being a fast programmer has nothing to do with how fast you type.

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

#630
post #563

Earlier quoted context omitted.

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.

It's even simpler, "tell me about a challenging bug you've vanguished, what it was and how you solved it." People in the trenches love to tell war stories. I do.
Post reply on HN