When hiring senior engineers, you’re not buying, you’re selling • Hacker News Board

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

#541

Post by unclebucknasty » Mon, Jan 21, 2019, 3:33 PM UTC

droithomme wrote: post #344

unclebucknasty wrote: post #282

Earlier quoted context omitted.

> 90% of people that can do that are decent I can't imagine this being an effective qualifier for any but the most junior of devs.

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.

>Some of those that could do it are good candidates.

Looks like you edited your comment. In any case, that's a non-statement, as some is quite different from nearly all (i.e. 90%).

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

#542

Post by unclebucknasty » Mon, Jan 21, 2019, 3:41 PM UTC

bertil wrote: post #465

unclebucknasty wrote: post #282

Earlier quoted context omitted.

> 90% of people that can do that are decent I can't imagine this being an effective qualifier for any but the most junior of devs.

Honestly, just try it. Have a significant preface about how it’s simple by design, and you are not trying to trick them, if you are hiring, say, a VP or a CTO; call it a warm-up if you want. But absolutely try. I’ve had a majority of candidates with five-year experience as a data scientist not be able to load a csv file using np.read_csv() The problem wasn’t that it didn’t work (the csv intentionally had a minor quir…

>if you are hiring, say, a VP or a CTO

If I were hiring a VP of engineering or CTO, my only goal in administering such a basic test would be to see whether they are offended and prepare to politely leave the interview. Not kidding here.

Sure, CTO duties can run a broad spectrum, depending on company size, etc. It could essentially mean "dev lead with a small team", all the way up to public company CTO with a good command of financials, managing budgets, large multi-level teams, etc. But, at either end and anywhere along that continuum, I would want to skip to probing higher-order thinking around architecture, strategy, people-management, etc.

So, if I've brought in people who I believe are adept at skills like these, I'd expect them to be confused and perhaps even insulted when I pull out a fizzbuzy integer summation problem.

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

#543

Post by jimmaswell » Mon, Jan 21, 2019, 3:45 PM UTC

darkpicnic wrote: post #533

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…

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…

Does it have to crawl the whole internet or can it just scrape the top 5 or so most important sites?

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

#544

Post by sheikheddy » Mon, Jan 21, 2019, 3:45 PM UTC

throwawaymath wrote: post #519

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?

No, let me give a specific example. Imagine you're interviewing a candidate and they're talking through how to design an analytics service. They begin talking about e.g. database architecture, and how this type of data is most appropriate for a star schema. They start talking about the tradeoffs of row versus column orientation. They mention they'll need to do indexing for performance and talk about the index space v…

Wow, I feel like I'm the sort of person this comment is calling out. What advice would you give me so I can be the real McCoy? The only solution I can think of is to keep writing as much code as I can, so I can get real experience instead of just hot air.

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

#545

Post by asaph » Mon, Jan 21, 2019, 3:50 PM UTC

jimmaswell wrote: post #543

darkpicnic wrote: post #533

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…

Does it have to crawl the whole internet or can it just scrape the top 5 or so most important sites?

Asking clarifying questions is a good interviewee practice. Well done.

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

#546

Post by mlthoughts2018 » Mon, Jan 21, 2019, 3:54 PM UTC

There are a lot of comments in the thread claiming that there’s some kind of “smooth talker” senior engineer candidate, but frankly that is preposterous and I simply don’t believe all the impossibly perfect anecdata thrown around.

It is incredibly hard to talk clearly about complex projects you’ve solved before in the specific tradeoff circumstances of some past project or job. Someone who can do that with great clarity is extremely hard to find and valuable.

I saw one comment that said something along the lines of hearing a candidate talk fluently about tech details (at a very specific implementation level) of past work, but then put them in front of a keyboard and they go “hmm urr uhh” or whatever.

This is frustratingly dumb. First of all, senior engineers should spend way, way more of their time thinking and directing architecture choices or prioritization than writing code, _especially_ in early stage projects or companies.

Second, I’m absolutely certain that the coding question you’re asking to generate this himming and hawing is some Cracking the Coding Interview bullshit trivia question that this senior engineer hasn’t thought about in 20 years since their algorithms class in college because they were too busy actually solving real business problems for people (including a few rare problems that involved detailed deep dives into novel or complex algorithmic solutions).

We harass and haze people with bullshit trivia, then turn around and don’t even ask them what problems they have really, actually solved before, or invent reasons to rationalize that if they solved a lot of problems before, they’re just some sort of smooth talker and somehow the only proof is if they memorized Floyd’s cycle detection algorithm or some other ludicrous bullshit.

What a deeply humanity-hostile industry it is!

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

#547

Post by draw_down » Mon, Jan 21, 2019, 3:55 PM UTC

scarface74 wrote: post #242

draw_down wrote: post #167

Earlier quoted context omitted.

Well, feel free to name names then if that’s the case.

You really think that the only place software engineers work in the entire US is Silicon Valley? All of these cities have a better salary/cost of living trade off than SV. https://www.matrixres.com/salary-surveys

A list of cities. Fair enough, I suppose.

I think the best move is to work remotely in one of those places for a SF-based company. I’m sure you’re right that companies elsewhere are open to hiring senior devs, the question is whether it makes sense to work for them.

There are a lot of people who want to buy a Lamborghini for $5,000, and are having trouble buying at that price. In that situation you can do two things: raise your offer, or complain about the lack of supply. Many opt for the latter.

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

#548

Post by dceddia » Mon, Jan 21, 2019, 4:01 PM UTC

acjacobson wrote: post #40

dceddia wrote: post #14

I agree with a lot of the points here. One specific pet peeve of mine is job listings that refuse to nail down which specific technologies they're using. Some will say things like "Front-end web development using a framework such as ExtJS, React, Vue, or Angular". Neat - which one? I'm happy to work with 1 or maybe 2 of those. Do you mean that you actually use React but you're fine with people who come from some othe…

While this is only my experience, when I write job requirements that cover multiple languages or frameworks it really is 'any of these are fine'. The theory is that you don't want to filter out people that would otherwise be a good fit - because for the most part smart people can learn new frameworks and languages pretty quickly. You are correct that it is suboptimal for people wanting to work on a specific tech stac…

It makes sense that you wouldn't want to prematurely filter people out, but in that case I'd think it might be better to explicitly state that. Something like "We use React, but experience with another framework (Angular, Vue, etc.) is fine. We assume you can learn React."

I think the unintended consequence of leaving it broad is that you might lose people who are specialized in the very framework you use.

In my own case, I'm pretty biased toward React, having written a book & been blogging about it for a few years. I definitely pass over job listings that leave the framework open to interpretation. The cost of finding out what they actually use is too high, unless the job looks exceptional in some way.

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

#549

Post by gerbilly » Mon, Jan 21, 2019, 4:05 PM UTC

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…

> The reason why some companies cannot figure this out is because they don’t value the problems at hand. They need bodies to put fingers on keyboards

Exactly this.

Too many companies are availability focused instead of ability focused.

The reason? When your processes and engineering are weak, you need people available 24/7 to put out fires.

When I interview for a position, I'm interviewing them as much as they are me.

One of the biggest asymmetries in the whole hiring process, is that of course every company will tell you they have the best development processes, frameworks and code to work on. They may even believe it because they don't know better.

Then you take the job and are stuck fighting fires on a big ball of mud codebase that takes over your life.

If you want to standout as a candidate, try and probe and really find out how good their 'culture is.' Interview them back.

One of the best questions for getting to the real answer is: "What are your expectations for availability?" If they expect availability from you after hours, then their stack is likely unstable because the need availability to keep it running.

If you are lucky enough when you are senior and good at what you do, you don't have to put up with that.

I often tell them about a the third of the way through the interview: "I'm not an availability guy, I'm an ability guy." They often are surprised by the statement. And the discussion that follows it usually tells me whether I want to work for them or not.

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

#550

Post by justinhj » Mon, Jan 21, 2019, 4:11 PM UTC

throwawaymath wrote: post #519

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?

No, let me give a specific example. Imagine you're interviewing a candidate and they're talking through how to design an analytics service. They begin talking about e.g. database architecture, and how this type of data is most appropriate for a star schema. They start talking about the tradeoffs of row versus column orientation. They mention they'll need to do indexing for performance and talk about the index space v…

I may be miss-characterizing your point but there have been many times that I’ve sat down at a terminal and not been able to remember how I did something a few months ago. On the job the important thing is knowing the high level goal and the fundamentals of what you’re doing. The syntax can be easily googled.

edit: yeah upon re-reading you’re talking about completely obvious lack of practical experience... fair point