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

551–560 of 694 posts

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

#551

Post by gerbilly »

bartread wrote: post #394
aprdm wrote: post #288

Earlier quoted context omitted.

This is a good post. Have been in the UK startup environment it was crazy how many companies got funding but didn't had a strong senior in their software department. Because of this their hiring process was aimed to hire more "strong juniors" even tho they didn't realize it. 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 be…

> 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? Just hire a junior and keep on going as usual.

Delivery focus is good, till you realise that it's often just delivering status quo for years on end.

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

#553

Post by jenscow »

C1sc0cat wrote: post #520
jenscow wrote: post #511

Earlier quoted context omitted.

Yes, I've learned that the hard way. Provided they give you payment in lieu of notice, they don't need much of a reason to let you go. Myself and a co-worker were once let go for "performance reasons" at 10 months - just after project completion (successful). It was beyond my probationary period, and no issues where raised in the 2 performance reviews. Their notice period was just 1 month. We were effectively cheap c…

Rather than just make you redundant on statutory terms - doing you on performance risks an industrial tribunal.

Not for less than 2 years: https://www.gov.uk/dismissal/what-to-do-if-youre-dismissed

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

#554

Post by paulcole »

stephenr wrote: post #368
paulcole wrote: post #309

Earlier quoted context omitted.

Here’s my answer: I have no interest in living so far away from a major urban center that I could have 10 acres. I have no interest in doing anything with land, farming, maintenance, whatever. My life is very simple and I’ve never lived in an apartment bigger than 600 square feet. The idea of 10 acres is insane to me.

What the shit. My carport is close to 680 sq.ft. I’ve lived in places smaller than that when I was young but that was necessity not choice.

I’m in my late 30s and I’ve never even driven a car. What would I do with a carport lol. It’s just a different mindset, I guess. I don’t have a ton of shit and just enjoy the minimal upkeep, simplicity, and other benefits of living in a small urban apartment.

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

#555

Post by IggleSniggle »

sheikheddy wrote: post #544
throwawaymath wrote: post #519

Earlier quoted context omitted.

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.

Writing more code is, indeed, the solution. This may feel challenging or even impossible because it takes away time from doing the research of actually understanding why everything works. Ie, due to time constraints, you may need to implement things more often without understanding how they work. This might make you less good at talking about solutions, but on the other hand better at actually providing them.

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

#556

Post by chiefalchemist »

HelloNurse wrote: post #401
chiefalchemist wrote: post #48

Earlier quoted context omitted.

> "Treat me with enough derision and pressure off the bat and I guarantee I'll fail your test even though I do fine at other companies." If only more companies realized who they are able to hire is a function of how they hire. And it starts with the job / opportunity / role description. As a side note, it seems to me, all this friction in hiring (senior level talent) makes a good case for developing and promoting fro…

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 of people they need.

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

#557

Post by dunpeal »

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…

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 would I do it?

I don't need to do any of that for the top employers in the market. Why would I spend hours of my time, and precious coding time, especially on some small company I never heard of before?

I haven't done that in years, and doubt I'll ever do it again. The only way you could get me to do it is if I was desperate for a job.

By requiring this sort of time and effort from candidates, you are screening out the best ones, those who can get multiple offers from great employers without jumping hoops for you.

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

#558

Post by mlthoughts2018 »

bloomer wrote: post #237
mlthoughts2018 wrote: post #224

Earlier quoted context omitted.

You’ll get hit with a DMCA takedown notice if you do that.. most companies protect interview questions they ask and solutions to them quite severely.

There is no way to copyright someone else's work. Whoever produced the solution owns the copyright.

This is not true. If the problem statement itself is a unique creation, and the solution is publicly viewable and gives details on the question itself, the question writer may have the copyright even if you signed no NDA when solving it. Even if not, if a company wants to sue you to try to keep their interviewing IP private (as they see it), they can tie you up in court at a trivial cost to themselves but a life destroying cost to a lone developer.

Source: I once had a dragged out legal dispute with a company that used a GitHub DMCA takedown to tell me to remove a public repo in which I solved their takehome challenge (I had signed no NDA or otherwise any type of agreement of any kind prior to solving it).

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

#559

Post by tomjen3 »

patio11 wrote: post #160
captain_crabs wrote: post #32

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…

Wouldn't you also need to check that the person wasn't an asshole and could show up on time? Or is this only the technical part of the interview?

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

#560

Post by gerbilly »

austincheney wrote: post #319
mandeepj wrote: post #308

Earlier quoted context omitted.

> Are things in place to make the job easier? Seniors don’t need easier and this is a huge turnoff. What? It requires a special craft to design simpler components. Most of the people don't even see it. This is where your senior skills will shine when you'll make it work like a charm as compared to the previous state. If you don't see the friction or can't reduce it then please take the first exit out.

I think you are conflating simple and easy. They aren't the same. Simple suggests less code, fewer pieces, and a shorter path between code and solution. Easier suggests least effort and less to look at. Simple isn't easy. The primary difference between simple and easy are decisions. A good senior will spend more energy on considerations for appropriate decisions than the actual work.

> I think you are conflating simple and easy.

I like to state it as complex vs. difficult.

Finding a bug in ten thousand lines of crappy VB code code is 'difficult', but not fun.

Writing an space/time efficient implementation of level set topology optimization is complex.

Senior developers usually love complex problems, but hate merely difficult problems.

Post reply on HN