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

#631

Post by ams6110 » Mon, Jan 21, 2019, 9:26 PM UTC

blihp wrote: post #241

joshuamorton wrote: post #120

Earlier quoted context omitted.

Fair enough. It's to some extent a cultural thing (there's no need for explicit probation in the US since most employment is at will), but I too wouldn't necessarily like a probationary period, even though I don't foresee it actually being an issue.

In the US there often is a formal probationary period at larger companies which mainly accomplishes one thing: reduce the HR red tape if a new hire isn't working out. During the probationary period it's generally easier to make a case (i.e. little or no documentation needed) that 'they're not working out' and HR will be OK with it vs. after the probationary period, you typically have to 'document' them out of the com…

I'm in the USA, and this (probationary period) has been the case with every job I've had in the past 30 years. I've never heard of a company not doing this in fact.

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

#632

Post by charleslmunger » Mon, Jan 21, 2019, 9:27 PM UTC

mattsfrey wrote: post #566

dunpeal wrote: post #557

Earlier quoted context omitted.

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

This seems extremely off to me - from my POV who the hell has time to study algorithms and implementing data structures every time they need to find a job? Trying to make sure I can whiteboard a random CS problem from a massive set of potentials on the fly in front of observers is drastically more involved and requires much more time that serves no other purpose than facilitating interviewing, versus just spending an…

I think it may depend on how much your day-to-day work involves data structures and algorithms.

Almost any work on compilers will involve good working familiarity with graphs

Work with concurrency will tend to involve linked data structures, like treiber stacks, or modeling computations as directed acyclic graphs of data dependencies

Working in a memory constrained environment tends to involve data structures and algorithms tailored to that domain, etc.

Now it's totally true that many algorithms questions just reduce to brain teasers, or are so esoteric and interview-specialized (Find out if this linked list has a cycle in O(1) space!) that they only serve to stoke the egos of the interviewer. But I wouldn't say that using algorithms or implementing a data structure is a skill that only exists to facilitate interviewing - and being able to explain your thought process as you work is really important when making contributions to other teams' code. I try to focus my interview questions on miniature versions of problems I've actually had to solve in the course of my job. For example, the futex state machine I wrote here:

https://android-review.googlesource.com/c/platform/art/+/810...

If you subtract the interrupt and timeout handling, you have a real problem with a simple, approachable (for someone with some concurrency knowledge) solution, and you only need to know about two futex calls which have simple behavior and are easy to explain in limited time. I wouldn't ask this question of someone looking for a web development position; but then again, I don't interview those candidates because I know nothing about web development. But it's a nice question for someone who listed concurrency on their resume.

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

#633

Post by ams6110 » Mon, Jan 21, 2019, 9:30 PM UTC

mancerayder wrote: post #351

droithomme wrote: post #334

Earlier quoted context omitted.

In addition to covering all interview expenses such as travel food and lodging, candidates need to be paid for their time interviewing by the companies interviewing them. Six hour take home tests is fine, but I want $1350 for that in advance as a consultation fee, and if I hit 6 hrs and it's not done yet they can keep paying until I am done or we can just end it, no refunds. The idea that I should spend six hours doi…

It's even worse when you're a consultant. At the moment I'm faced with scheduling my fourth round with a company, and of course it's 5 hours onsite. I have the option of skipping the free lunch, they said. It's nice of them, but my monetary loss for that time (including commute) is enough to pay lunch for a number of people. All that, and they can still can you a few weeks or months into the job if you're a dud. It's…

That does sound excessive. I've never had more than 2 rounds of interview, and even at that the first round was typically over the phone and the second on-site.

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

#634

Post by davidfischer » Mon, Jan 21, 2019, 9:34 PM UTC

davidfischer wrote: post #623

ycom_j wrote: post #612

Earlier quoted context omitted.

Whew, that is a hard thing for me to read, it actually really bummed me out (apologies if this comment winked in and out of existence...wanted this to not be one giant blob). (Bear with me, gonna anxiety dump a bit here ;) feel free to skip to the end where I have a pertinent question...=) ) Background: I've worked as a high-level contributor both at the management and engineering levels for the last decade of my car…

Sorry to bum you out. That's not my goal. As one becomes more senior the hiring manager expects a candidate to do their due diligence and ask some questions beforehand rather than hopping right into the application process. For a referral, that has already happened somewhat as the candidate already presumably talked to the the referrer about working at that company. You don't have to be a referral but a hiring manage…

A couple things to add:

- The #2 source of candidates was almost universally meetups in my customer development interviews. Meeting people in person works! You don't have to be a referral although it does help.

- It's pretty easy at a small company to figure out who the hiring manager is and contact them via LinkedIn/Meetup/etc. At a big company, this can be hard or impossible but you are much more likely to know somebody at a big company who can put you in touch. Absolute worst case, reach out to the big company recruiter on LinkedIn asking for some details on a specific role and they might put you in touch directly or they'll get your questions answered some way. The recruiter 100% will talk to you. They are paid good money to find qualified people like you.

- While I said earlier it isn't a numbers game and you should only apply to roles/companies where you're a fit, to some degree it is a numbers game. Sometimes jobs are posted to a company website and the role isn't really available. Maybe they already have a candidate in mind. If you apply to ~3-4 jobs and don't hear anything, that isn't super uncommon. However, most people feel obligated to actually give you a direct answer if you contacted them directly.

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

#635

Post by fgandiya » Mon, Jan 21, 2019, 9:48 PM UTC

asaph wrote: post #545

jimmaswell wrote: post #543

Earlier quoted context omitted.

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.

Their response reminds me of the Monty Python sketch about the speed of an unlaiden swallow.

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

#636

Post by monksy » Mon, Jan 21, 2019, 9:54 PM UTC

le-mark wrote: post #630

monksy wrote: post #563

Earlier quoted context omitted.

Ask them about the challenges which they've faced when using x, y framework. Ask them why they prefer one framework to another. Ask them how they view testing Walk through with them on a simple whiteboard problem and ask them where they would write test cases. Watch for the amount of detail they give you. That will give you an indication of what kind of a developer and how deeply they go into problems.

It's even simpler, "tell me about a challenging bug you've vanguished, what it was and how you solved it." People in the trenches love to tell war stories. I do.

For me it tells me a lot about how a person goes about solving the problem, how they're going to avoid it later (if the are), context about the conditions that the person worked in, where their interest lies, and what motivates them.

If their answer involves "well I searched around stackoverflow a lot and asked there" that's a no go for me.

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

#637

Post by bigiain » Mon, Jan 21, 2019, 10:18 PM UTC

jjeaff wrote: post #298

drb91 wrote: post #292

Earlier quoted context omitted.

Well, unambitious seniors are a good bet on who not to hire. They’ll only work what you pay them for, those lazy bastards!

I think I've read in quite a few places that most great programmers are essentially lazy.

"We will encourage you to develop the three great virtues of a programmer: laziness, impatience, and hubris." -- LarryWall

Laziness: The quality that makes you go to great effort to reduce overall energy expenditure. It makes you write labor-saving programs that other people will find useful and document what you wrote so you don't have to answer so many questions about it.

Impatience: The anger you feel when the computer is being lazy. This makes you write programs that don't just react to your needs, but actually anticipate them. Or at least pretend to.

Hubris: The quality that makes you write (and maintain) programs that other people won't want to say bad things about.

(That quoite's originally from Programming Perl 1st edition in 1991, the explanations I think didn't show up until edition 2 in '96 or so...)

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

#638

Post by candybar » Mon, Jan 21, 2019, 10:24 PM UTC

mattsfrey wrote: post #566

dunpeal wrote: post #557

Earlier quoted context omitted.

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

This seems extremely off to me - from my POV who the hell has time to study algorithms and implementing data structures every time they need to find a job? Trying to make sure I can whiteboard a random CS problem from a massive set of potentials on the fly in front of observers is drastically more involved and requires much more time that serves no other purpose than facilitating interviewing, versus just spending an…

Most of the top employers in the market have similar types of interviews so you have to study anyway unless you want to rule out all of them and any time spent preparing for such interviews amortizes across all of them. Meanwhile, a take-home test is almost always a one-off and takes much longer on a marginal basis and rarely is even used to make the final decision - every time I've done a take-home, I've also had to go through the full interview loop.

Also, "an hour of my time programming a solution to a problem" is likely not an actual work-sample/take-home - it's likely a replacement for a phone-screen that doesn't require an engineer to conduct, thus can be given to many more people to keep the top of the funnel large. The only time I've done a real take-home in less than 10 hours, it was rejected for not being polished enough.

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

#639

Post by bigiain » Mon, Jan 21, 2019, 10:29 PM UTC

BrissyCoder wrote: post #423

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 don't know how much experience you have as a professional developer but I can barely remember the problems I solved last week let only any interesting ones I've solved in the past 10 years.

I have maybe half a dozen really interesting stories, and maybe a dozen or two interesting but only to the right crowd stories - from a career spanning a bit over 24 years. And a bunch of war stories about why we shouldn't do things that way, because of the problems we discovered trying that in 1998 or 2003... (And occasionally the "we should try that again because it didn't work back when our colocated production servers had 486's and 320Mb disks - but it'll probably work just fine as a mobile app now"...)

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

#640

Post by dleslie » Mon, Jan 21, 2019, 10:32 PM UTC

jenscow wrote: post #511

C1sc0cat wrote: post #429

Earlier quoted context omitted.

Also the UK the first 2 years are effectively at will

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…

The norm where I am, in BC, is two weeks for notice. It increases slightly the longer you're employed.