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

#491

Post by seren » Mon, Jan 21, 2019, 12:25 PM UTC

sethammons wrote: post #158

ChuckMcM wrote: post #125

I think the article is reasonable but it suffers from the imprecision of "senior" as many things do. What is a 'senior' engineer in a startup, or at a mid-size private company, or a large public company? All of those companies have "senior engineers" but they aren't easily swapped out for each other. These are my definitions, at a startup a senior engineer is one that is broad enough in their experience to have gone…

Why should not all those be together and be the bar for senior starting at the start-up layer? I think the only big difference is working/navigating in a small or large org, no?

If you look at the both extreme, large public company and a start up, in the former case, you already have customers, a viable business model, and a legacy product. As an engineer, your first requirements would be to "not break things" going forward. Sure you want to gain some market share from competitor but you already have some momentum, otherwise your job would not exist. So you need to upgrade or add features to your product in a controlled way. Your 20 years customer might not want to have to learn a new interface just because you can deliver it.

At a start up, even if you have your first customers, you want to deliver a product or more features as quickly as possible starting from scratch. Possibly, you also want to be able to pivot totally if the first idea does not stick.

It is great if you can do well in both environment, but usually, this is different skill set, and I would even say personal inclination. You'll likely have a hard time to convince a start up engineer to work on COBOL code base on a mainframe.

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

#492

Post by mcv » Mon, Jan 21, 2019, 12:27 PM UTC

pjmlp wrote: post #439

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.

I do, in my home country it is not legal to sign off projects as engineer if not certified by the Engineering Order as such. A certain level of quality is expected, not labeling one selfs as engineers after 1 month bootcamp.

I have no idea if there are rules in my country about calling yourself an "engineer", but you can only use the title 'ir' or 'ing', both of which mean ingenieur, which translates to engineer, if you've graduated from a technical university or high-level technical school (technical college? higher trade school? 'ing' is from a level lower than a university degree).

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

#493

Post by borplk » Mon, Jan 21, 2019, 12:28 PM UTC

mastef wrote: post #379

I love how firms have an issue hiring senior engineers, when the last few firms I've spoken with deemed me "overqualified". Another buddy with longterm CTO experience had 150 applications with a 2% hit-rate. On the "better" AngelList CTO/Senior jobs we can clearly see that there's already 50-100 other applications submitted. So is this really that big of an issue as presented?

constantly complaining about the job market being tough is a strategy for companies.

they could have a 1,000 perfect candidates lining out the door willing to work for peanuts.

At that point they would adjust their expectation from "peanut" to "half a peanut" and they would still moan about "skill shortage".

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

#494

Post by lowercased » Mon, Jan 21, 2019, 12:28 PM UTC

lugg wrote: post #438

bartread wrote: post #394

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…

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…

or... nobody wants to pay to clean up the mess. i know people who will do it. I will do it, but I can't clean it up, and delivery loads of shiny new features, and do it all while trying to justify every 30 minute block of time and asking if xyz is 'really' necessary. oh, and you also need to be able to answer some real questions about your own business process, because often your existing practices are just 3000 lines of crap in a function file. when you say "it's broken" and I ask "what's the correct behaviour?" and you don't answer... it'll never get 'fixed'.

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

#495

Post by sethammons » Mon, Jan 21, 2019, 12:28 PM UTC

cookiecaper wrote: post #393

sethammons wrote: post #301

Earlier quoted context omitted.

Interesting. To clarify, you are saying that these boiler-platey languages, it is not fair to write a unit test in a 45 minute time block with access to Google? I'm not a Java guy. All the languages I've used, this would not be an issue. Again, I'm wrestling with it because it I feel it should be easy but like 80% of our candidates who chose Java struggle with it.

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 biases leak through from an interviewer on "that is a strange way to do that in language X."

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

#496

Post by pzs » Mon, Jan 21, 2019, 12:43 PM UTC

kaybe wrote: post #453

pdxww wrote: post #341

Earlier quoted context omitted.

Honestly speaking, since it's an anonymous forum, what's the difference between L5 and L7? Like if I was asked the same question - the difference between L3 and L5 - I'd say that it's just experience with a few interesting known projects that's paid so much better, while the cognitive ability is the same.

Could you give a short explanation of what this L3/L5/L7 thing is? I'm assuming you're not talking about spinal cord problems, which is the main search result.

I think [1] gives an explanation of it.

[1] https://levelsfyi.com/google-levels-salary/amp/

EDIT: found a better source

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

#497

Post by [deleted] » Mon, Jan 21, 2019, 12:45 PM UTC

kaybe wrote: post #453

pdxww wrote: post #341

Earlier quoted context omitted.

Honestly speaking, since it's an anonymous forum, what's the difference between L5 and L7? Like if I was asked the same question - the difference between L3 and L5 - I'd say that it's just experience with a few interesting known projects that's paid so much better, while the cognitive ability is the same.

Could you give a short explanation of what this L3/L5/L7 thing is? I'm assuming you're not talking about spinal cord problems, which is the main search result.

[deleted]

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

#498

Post by Novashi » Mon, Jan 21, 2019, 12:46 PM UTC

phkahler wrote: post #275

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…

Funny. I agreed with the author. It's relatively easy to gauge technical ability vs those who can pretend. I only use a simple take-home problem when I truly can't tell which type they are. The really great part is that I usually tell a faker from the resume. Maybe I should blog about this.

I want to highlight a third possibility that isn't discussed which is people who can talk about code, but can't deliver (or can't deliver well), but really want to learn how to deliver.

It's fine if you don't want to hire that person, but I'm really annoyed that they often immediately get labeled a bullshit artist in a lot of these threads.

Considering how many shitty positions there are, it's honestly surprising we don't reflexively go "oh, you never learned to do X well because you haven't been with a good company that can teach you to do X well".

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

#499

Post by henrik_w » Mon, Jan 21, 2019, 12:47 PM UTC

cloogshicer wrote: post #479

lsc wrote: post #216

Isn't it just... mostly money? I mean, if you want to hire someone good, who presumably has a good job, you have to pay better than what they are getting now. I think this is probably especially true in Europe; I mean, as far as I know, people get like a 2x-4x raise moving to silicon valley from europe. If you pay more than your local competitors, you will largely have your pick of the candidates. I mean, yes, things…

Like I said elsewhere in this discussion, I disagree. Of course, salary is very important, but I (and many people I know) would easily choose (and have chosen) a lower salary for any combination of these perks: - Work fewer hours - Work from anywhere - Work in a specific location - Work in a certain environment - Work in a specific kind of organization - Work with specific technologies - etc. People are very differen…

For me it is:

- the product is SW

- great colleagues

- challenging problems

- cool technology

- having users

- good salary

- good tools

- max 40 hours a week

- minimal bureaucracy

- working remote when needed

https://henrikwarne.com/2013/03/26/what-do-programmers-want/

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

#500

Post by iaml » Mon, Jan 21, 2019, 12:49 PM UTC

taf2 wrote: post #166

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

> I like to see how people type too... if you can’t type it’s usually easy to tell if you spend most of your time with a computer or not...

I disagree. When nobody's looking I type pretty fast, but when the whole interviewee team is looking at my screen I suddenly forget all the shortcuts and mistype a lot due to anxiety.