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

461–470 of 694 posts

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

#461

Post by jcadam »

AznHisoka wrote: post #139
xfitm3 wrote: post #99

Earlier quoted context omitted.

Why doesn't the gopher archetype also apply to development roles? Persistence pays off if you measure your own results. Knowing how to divide a problem is really important, even if you're great at algorithms.

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.

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

#462

Post by bertil »

cloogshicer wrote: post #38
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…

Hi, author here, thanks for your feedback. I think you might be right, thinking about rewriting that paragraph a bit. For me it's been really obvious in interviews whether someone knows what they're doing or not. But probably I've just been lucky in this so far. Looking forward to reading your post about it. Haven't read it yet, but if it's not in the post, could you give a few examples of what people said, that turn…

I think your key point is less that testing is easy than you should let the candidate prove their worth in their own way. This sounds key to me. Your original quote is… yeah, “easy” happens, but it’s not always elementary.

Testing a candidate is actually very candidate-dependent, I found out; however, it is a lot less hard when you let the candidate pick their own approach (and you supplement it subtly). I found it easier than most interviewers who tend to do scripted, one-size fits all tests.

I always ask candidates to talk about what they’ve done (I’m in data science, so university projects typically can be relevant for day-work; standard CS might not be so lucky). If there are omissions, ellipses, I might prod a bit.

The best candidates can easily juggle between business objective, method, architectural and technical choice, how they scaled a release into marginal improvements from prototypes to a full-fledged platform. It typically takes me one question, two follow-up and 10 minutes to know they are strong. From there, I can shelter them from more technical tests, or at least apologise for the process; ask if they are comfortable with white-boarding, etc.

The worst candidates are not that different: they can sweet-talk their way, but might not be able to scale up or down abstraction. You can prod from them if they are comfortable receiving feedback (based on how they react to you re-framing the question), their learning style (based on how excited when I ask details about specific implementation).

If you are uncertain, which remains most candidates, I like to put them in front of what I have been working on recently. It gets Legal a little nervous (it really shouldn’t) but it puts them in a rare but effective situation: I might not know as much as they do. I probably have had more time to explore, but no idea that they suggest, I can dismiss: either I had the same or it’s new to me and worth trying. I’m not the most structured worker, so I often have a bug, something that could be improved but it’s a priority, some high-level conceptual concern, etc. I make sure that they go for something that excites them or the problem that I’ve identified earlier.

I rarely need more than an hour to have a clear idea, including data preparation.

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

#463

Post by Radim »

foo101 wrote: post #304
drb91 wrote: post #161

Earlier quoted context omitted.

Algorithmic ability has no correlation to the ability to write maintainable code, though. Most time at work is not spent demonstrating ability to regurgitate algorithms.

> Algorithmic ability has no correlation to the ability to write maintainable code, though. This is not true in my experience. I usually see a strong correlation between algorithmic ability and writing maintainable code. At various organizations I have worked for, I have seen that the ones with strong algorithm skills also happen to be critical thinkers who put a lot of emphasis on simple, elegant, and robust design…

I'm afraid I can also only offer anecdata. Mine is based on hiring and then working with dozens of SW engs since 2008 (my first tech lead role), plus our student Incubator and open source projects (dozens of more junior devs).

The correlation between emphasis on simple, elegant design and code and algorithmic chops is indeed uncanny.

And I'd add "clarity of articulation" to that -- being able to express your thoughts and the problem/solution structure clearly and succinctly is a great indicator as well. Huge overlap with both code maintainability and algo quality.

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

#464

Post by Annatar »

Pyxl101 wrote: post #459
Annatar wrote: post #452

Earlier quoted context omitted.

Lying on one's resume isn't acceptable anywhere, as programmers are not engineers. It's lying and resume inflation for the explicit purpose of making oneself sound more competent than one really is. If one comes to me for a job interview stating on one's curriculum vitae that she or he is a software engineer, the first thing I will demand to see is a portfolio of specifications, manuals, process flows and architectur…

On what basis are you claiming software engineers are not engineers? What constitutes being an "engineer"? For the record, the National Counsel of Examiners for Engineering and Surveying, which is the US body that regulates engineering licensure and "Professional Engineering", recognizes Software Engineering as a branch of the engineering disciplines: https://ncees.org/engineering/pe/software/ "Professional (Licensed…

An engineer gathers requirements through a formally defined process and writes a formal engineering specification which translates those requirements into actionable norms. For example: "server operating temperature shall be between -40 and +70 Celsius at 400 m above sea level and the power supply shall operate at Voltage between 110 to 240 Volts at either 50 or 60 Hz with peak load of 35 Amperes". Or: "the program shall support following options", with a detailed specification on what those options do and how they will do it. Or: "the software shall respond within 25 ms of receiving the request on port 4096. The protocol used shall be TCP". RFC documents are often good examples of system engineering and architecture.

Simply knocking in a program as a code monkey or hacking haphazardly on a program until it works in some way which isn't formally defined isn't an application of scientific theories in computer science into a practical product, which is what defines engineering.

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

#465

Post by bertil »

unclebucknasty wrote: post #282
verelo wrote: post #179

Earlier quoted context omitted.

I kind of agree and kind of dont. I have a super simple inital question I always ask in interviews: Write me a function, in any language, that takes an array (or list) of integers and returns the sum. 90% of people that can do that are decent, and sadly i'd have to say i'm shocked by how many people struggle with this question, or the follow up of "ok interesting implementation, now what can go wrong at runtime?" It'…

> 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 quirk that demanded that one uses a non-default option) but the reaction to it not working, or, in a majority of cases, the inability to search (on Google) for “what function allow me to import a csv file into a table” was incredibly telling. From there, you can have a conversation about what they did and it often leads to a more honest portrait of their previous functions. Sometimes, that led to offering them a more suitable position.

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

#466

Post by cloogshicer »

productpinata wrote: post #339

I definitely agree with some of the points (job descriptions and onboarding are generally dumpster fires, to highlight just two), but it has a little too much of a stereotypical young developer feel for my tastes. There are fine engineers out there who aren't overly concerned about the dress code, for example, but care deeply about diversity, social good, and/or benefits other than basic salary. There is so much more…

Hi, author here, thanks for your feedback. I did mention that not everyone will care about these things, but I like your point about diversity and social good. Probably things I should've included.

Looking forward to reading your post!

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

#467

Post by C1sc0cat »

floss_fulltimer wrote: post #448
Annatar wrote: post #375

Earlier quoted context omitted.

"Principal engineer"? Do you actually have an engineering degree? Have you formal education in engineering? What is system engineering? It's not just you; the entire IT industry is suffering from systemic curriculum vitae bloat. That's why the working conditions are so bad in the professional sense.

> Have you formal education in engineering? Good point. In many countries getting a degree in engineering takes way, way more effort than in computer science. Then it takes 10-15 years of work to be called "senior engineer".

And from family experience (uk) its more a case of who you know not what you know.

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

#468

Post by readingnews »

tyre wrote: post #283
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…

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…

> Those are the "smooth talkers" of the engineering world. Those are the people you can't catch just through a verbal interview.

I agree with this. I was a hiring manager, and there are those that can really talk technical, in detail. You really think they know what they are doing, how to solve complex problems, how to come up with solutions. You put a keyboard in front of them (or pencil and paper), and they go "uhh, errr, ummm." and fail miserably.

I think until you have interviewed a LOT of people, it can be hard to quickly spot this. Some people are masters at telling you how someone else solved the problem as if they solved it, but they can not solve it themselves.

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

#469

Post by cloogshicer »

iblaine wrote: post #286

This is clickbait to sell a book. "Having trouble doing the thing? The problem doing the thing is you. Buy my book for $45, then you can do the thing."

Hi, author here, thanks for your feedback. What did you think about it was clickbait? I genuinely believe that most companies can improve a lot of things when it comes to hiring. And they don't know how to do it, because they have the wrong mindset.

If something about this was too flashy, please let me know.

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

#470

Post by cloogshicer »

nayuki wrote: post #245

It's a solid, good article. But the repetitive 4 boxes to enter your email address to sign up for their newsletter, that annoyed me quickly.

Hi, author here, thanks for your feedback, I'll tone it down a bit next time.
Post reply on HN