Live data from Hacker News

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

hiringengineersbook.com

661–670 of 694 posts

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

#661

Earlier quoted context omitted.

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?

On your own hardware, I'd expect you to be able to have a blank project up in minutes, so yes, I expect somebody who's not travelling to our site to be able to take 5 minutes out of their busy day to create a blank project.

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

#662

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…

Do you give them "their" tooling? I can set up a project of the type you describe in about five seconds, because I have a template for it in my IDE. The best defaults for this that I've seen are provided by IntelliJ (do you provide this in interviews? It seems legally challenging to do) and would probably take me 5-10 minutes to navigate. I think Java depends much more heavily on powerful tooling to do the heavy lift…

If they're coming in, I'll hand them a laptop with the project set up and ready to go, with IntelliJ running. If they're normally an Eclipse user I'll swap to Eclipse shortcuts and help them manage the IDE as we go.

If it's remote, I'll ask them to share their screen with me with a project set up and ready to go, having emailed them a copy of the interface we're going to implement about 30 minutes before the interview.

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

#663
post #438

Earlier quoted context omitted.

The higher you go the more compromises you have to make. That said, nobody is talking about disruption, just wisdom. It just so happens, sometimes that wisdom will tell you that shipping shit out the door in the name of delivery focus is going to cost you more than its worth in the long run. Calling them overly idealistic to justify your laziness just makes you look bad. I'd say a truly good senior can tell the diffe…

Who's talking about shipping "shit"? You are overreading by a very wide margin. I also don't appreciate being called lazy, and especially by somebody who knows nothing about my business or my team. Please try to keep your tone civil in future.

I'm not overreading, you said you prefer shipping sub optimal solutions. Sounds like to me.

I didn't call you lazy, I said that shipping in the name of delivery focus was lazy, or at least your argument about idealism was.

Fact is, shipping quality is the far more optimal solution and always will be. Making the trade off and adding technical debt is never a worthy trade long term. The only people who gain from it are you and your team. The rest of the company eventually grinds to a halt and begins taking more and more shortcuts around the code which just reinforces everything in a viscous cycle.

You might find this useful: https://youtu.be/DngAZyWMGR0

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

#664

Earlier quoted context omitted.

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

Here are some I thought of off the top of my head. These are based upon things I actually encountered. What if I were to provide a solution that executes much faster, requires less documentation, passes test automation, and is a quarter of the code but ignores the framework or standard code style? The standard DOM methods perform thousands of times faster than other options for interacting with markup. I can prove th…

A couple of these questions would be at least yellow flags for me as an interviewer or hiring manager, as they indicate a strong bias for throwing away existing systems ("ignores the framework", "rewrite the build", "original code").

There's a great quote from Lou Montulli[1]:

> I laughed heartily as I got questions from one of my former employees about FTP code the he was rewriting. It had taken 3 years of tuning to get code that could read the 60 different types of FTP servers, those 5000 lines of code may have looked ugly, but at least they worked.

Those frameworks and existing components most likely have a lot of hard-won experience embedded in them, and I would be uncomfortable hiring someone who did not appear to understand or appreciate that.

See also: Chesterton's fence[2].

[1]: https://www.joelonsoftware.com/2000/05/26/20000526/

[2]: https://en.wikipedia.org/wiki/Wikipedia:Chesterton%27s_fence

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

#665

Earlier quoted context omitted.

CS is not programming just like 99% of musicians don't have music theory degree.

Interesting analogy. I bet there's scope to twist it beyond all sensible bounds, and compare the ability of the 99% to the 1%. I suspect there's top level classical, jazz, and session musicians - who're the industry equivalent of 10x programmers. (And all the other stereotypes probably exist too, I bet there are occasional untrained but gifted musicians who can produce 10x output, but who're amazingly difficult to co…

The only problem at that level of musician ship you lose the fun and can end up with some very sterile music that's only of interest to other people who have degrees in music theory.

Btw years ago I did work with a top session guitarist (top 10 hits) who after an accident taught himself to program from his hospital bed.

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

#666

Earlier quoted context omitted.

If management is rude and naive enough to be bad at hiring, they can be expected to be equally bad at promoting and retaining internal talent. For example, there's the simple pattern of ignoring employee careers and expectations until, after the least patient ones have left, suddenly there's a lack of personnel, and the best remaining people are needed in their current dead-end role.

The mistake I see __consistently__ is that when I'm discussing an opportunity / relationship with someone who is "hiring" is that they don't realize I'm interviewing them as well. Fairly often, those who don't realize this are the same ones who will hint / complain about retention and such. They want better people but that have no idea how better people think / feel and how their approach will never get them the type…

Once I interviewed at a large fashion company for a Python programmer position. I asked to see IT offices (no way, even if I had required a second interview expressly to see them; the building layout suggested some sort of overcrowded basement), I asked about salary (matching my current one would have been a stretch), about benefits like a car (oh no, only for top management!), about training (studying their software after hours, on my own time), about lunch (internal mess hall only, and nobody can leave), about their software engineering approach (overtime, and proud of it). They unconsciously went out of their way to demonstrate a corporate culture of paranoid secrecy and to show that IT had very little consideration within the company. I tried hard to find a reason to like them, and when I found none and refused their offer I got an angry call from the manager: I wasn't "motivated". He thought I had wasted their time.

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

#667

Earlier quoted context omitted.

It's probably a great analogy because the best musicians all know basic music theory, whether they learned it in school or on the bandstand. As for the advanced theory that they teach in graduate programs, it isn't even applicable to most genres of music.

> the best musicians all know basic music theory Do you have any evidence for such a bold claim or is this just speculation?

They might know it instinctually but Funk brothers / James Jamerson (the bass player on a lot of Motown) didn't go to uni to study music.

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

#668

Earlier quoted context omitted.

> but unless it’s time actually working with your team on a real project.. I've ranted about this before on HN, but that's very much illegal in my neck of the woods. As soon as someone does useful work for you, they're an employee. YMMV but you can't expect new candidates to do actual work until you've hired them. There are plenty of programming assignments, exercises or questions you can have them do instead.

So have a basic filter, hire based on who meshes well with the team and have a trial period during which they actually get evaluated for competence. They’re technically an employee during the trial period, but with the understanding (and contractual agreement) that they will be evaluated at the end of the period and that the employment will be terminated if they do not meet the criteria.

Trial periods, too, are no longer allowed over here. They used to be permissible up to 6 months (which was an insanely long time to essentially live with the knowledge that you could basically be sacked any day). But now they're gone. Firing people isn't terribly easy either, might need to give two months notice!

Of course, the net result is that self-employed contracting is on the rise. Especially the kind where people are self-employed only in name, but really work for a single employer. The only difference is that they send an invoice at the end of the month, and the employer can terminate the contract at any point (depending on the terms in the contract, of course).

Hiring is hard. Especially so when hiring the wrong person can cost you two months' wages.

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

#669

Earlier quoted context omitted.

So have a basic filter, hire based on who meshes well with the team and have a trial period during which they actually get evaluated for competence. They’re technically an employee during the trial period, but with the understanding (and contractual agreement) that they will be evaluated at the end of the period and that the employment will be terminated if they do not meet the criteria.

Trial periods, too, are no longer allowed over here. They used to be permissible up to 6 months (which was an insanely long time to essentially live with the knowledge that you could basically be sacked any day). But now they're gone. Firing people isn't terribly easy either, might need to give two months notice! Of course, the net result is that self-employed contracting is on the rise. Especially the kind where peo…

> Trial periods, too, are no longer allowed over here.

Ouch. That does make it really hard, impossible even, to make sure you get a good fit.

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

#670
post #526

Earlier quoted context omitted.

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.

Absolutely. Pretty much everything we do can be improved with practice.
Post reply on HN