Live data from Hacker News

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

hiringengineersbook.com

311–320 of 694 posts

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

#311

Earlier quoted context omitted.

I guess you could say that. I suppose you do sort of feel a little stressed during the trial period but I've never seen anyone fail it and it applies at every company, so there's no escaping it anyway. When it was introduced some people got quite upset but I can't really say I think it's had a bad effect. I guess from the companies perspective if they realize they made a grave mistake they can back out of the hire, b…

> I suppose you do sort of feel a little stressed during the trial period but I've never seen anyone fail it and it applies at every company, so there's no escaping it anyway. I'm not sure what you mean by "it applies at every company". Getting hired and then fired a week later is virtually unheard of. This is not a fear I have, at all. But if you told me it's probationary, that is totally a fear I'd have, I'd get pa…

By "it applies at every company" I mean it's part of the contract no matter where you work because by law the employer is allowed a 90 day trial period, so they all put it in the contract, so one offer is just as real as the next and it's just something you have to go through and yeah I guess it's probationary in nature.

Not everyone likes it or agrees with it, and I can only comment on the software industry here and not other industries but it's not the end of the world and the sky doesn't at all fall. When they introduced it a lot of people tried to make arguments like it would be abused etc and as far as I can tell there hasn't really been any drama. YMMV depending on country.

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

#312
post #47

Earlier quoted context omitted.

The best interview I ever had was a 2-hour onsite work sample, followed by 1/2 an hour discussing what I'd come up with. I was offered the job the next day. Surely most people would prefer this to whiteboard tasks?

The best interview I had was a few hours of friendly conversation about the details of my resume. Then I was hired under probation, as everyone there was, and the understanding was that I could be easily dismissed if it was clear that I wasn't working out.

I had perhaps the most amazing interview experience recently where it was an open discussion. It wasn't a technical drill down but more a Q&A where you discuss topics relevant to the area you claim to have knowledge of and how it relates to the job you're interviewing for. It was the complete opposite of code this technical problem and a missing semicolon will get you a flat out rejection.

What clicked was I was finishing their sentences and knew precisely what they were asking. It was an incredibly rewarding experience which led to a same day offer.

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

#313
post #221

Earlier quoted context omitted.

But are architects supposed to write code? The example you give is embarrassingly simple and anyone should be (expected to be) able to write code for it. But aren't architects designing architecture. I don't think the architect or anyone in his team at my previous organization's IT dept could write code, but he could design system architecture.

How can you design something that needs to be implemented in code if you yourself can't write code? If you can't produce in the trenches, what makes you qualified to dictate what those that are in the trenches are doing?

Difference of terminology I guess, but I worked at a Pharma company and I am talking about the Enterprise Architect, so maybe not the same kind of architect you are talking about. He and his team made decisions related to tech stack. They never made software design decisions. Over at the Pharma company IT higher ups weren't technical anyway.

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

#314

Earlier quoted context omitted.

> The current cargo-culted trend of take-home problems is a scourge I hire based on take-home problems. But then again I don't have candidates whiteboard. I give candidates time to produce something in the comfort of their own environment that goes beyond solving puzzles on the fly and is actually a reflection of the work people will do day-to-day.

> I give candidates time to produce something in the comfort of their own environment that goes beyond solving puzzles on the fly and is actually a reflection of the work people will do day-to-day 100% this.I find whiteboarding to be the actual scourge, as it involves unrealistic pressure in an unrealistic scenario. It reminds me of tests that inadvertently just test whether people are good test-takers versus assessi…

I see whiteboarding as a skill that is very useful in presenting or defending design ideas. I've had several cases where I used a whiteboard to layout a design interactively to an audience in a design review. I find I am at my best when I have marker in hand as it gives me control of the conversation.

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

#315

Earlier quoted context omitted.

>It does always amaze me that literally what you learn in HR 101 in an undergraduate management curriculum is controversial. The r^2 of a ton of different methods for predicting job performance is something large companies are highly incentivized to get studied by academics (and they do). Large companies are not "highly incentivized" to optimize they're hiring process. Once a certain throughput is achieved, there's v…

Microsoft and Google do not collectively hire that many people and are not who I am talking about. “Brain-teaser” type questions are explicitly not work-sample tests and, yes, have no correlation with job performance.

The number of people that they collectively hire is irrelevant. They have an outsized influence on interview practices industry wide.

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

#316

Earlier quoted context omitted.

SF has decent public transit. Disliking public transit is fine, but ignoring it is something else entirely. Muni and Bart do make it possible to get around most of SF without walking or using uber/lyft. And, given where I live, my medical, grocery, and a significant chunk of my social needs are truly within walking distance. The only one that isn't is work, and that would be accessible via public transit if I was wil…

Disliking public transit is fine, ... and is something I didn't write, nor feel. The parent comment asserted walkability . If your environment is walkable , that means you don't need transit/carshare for everyday needs. Carson City has 4 bus routes Again, walkable means walkable without transit. My father lived there with daily needs within walking distance. SF is not only not the "only" walkable city, SF isn't gener…

Walkability in the city-planning sense is defined by "lack of need for a car". Improved public transit improves walkability (see the walkability scores on pretty much any site ever), as does mixed use development.

Carson City has a walk score of 34 (although apparently there's a 4 block area in downtown that gets up to the mid 70s). SF has an average of 86. My apartment scores 99. Like I said, there isn't a genuine comparison to be had.

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

#317
post #233
post #221

Earlier quoted context omitted.

How can you design something that needs to be implemented in code if you yourself can't write code? If you can't produce in the trenches, what makes you qualified to dictate what those that are in the trenches are doing?

This reply applies to several here. I know a few architects (as in for buildings and civil structures) who wouldn't be able to pour a foundation, frame a wall, or run plumbing properly. They're working at a different level of abstraction and are concerned with different problems. Or to put it another way, if you can code does that mean you should be able to design a CPU, even a very basic one? After all, how can you…

I think this is a linguistic strawman.

Civil Architect is to Builder as Software Engineer is to Datacenter Technician. Software architect is to software engineer as partner at an architecture firm is to architect, or something.

You don't expect a plumber[0] or a building constructor[1] or a civil engineer[2] to become an architect[3], they're different degrees or certifications. A software architect is normally considered a software engineer who works at a grander scope of design. That doesn't map correctly.

[0]: http://dlca.vi.gov/businesslicense/steps/mppcrequirements/

[1]: https://bc.gatech.edu/master-science-building-construction-a...

[2]: https://arch.gatech.edu/bachelor-science-architecture

[3]: https://ce.gatech.edu/academics/undergraduate/bsce

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

#318

Earlier quoted context omitted.

>It does always amaze me that literally what you learn in HR 101 in an undergraduate management curriculum is controversial. The r^2 of a ton of different methods for predicting job performance is something large companies are highly incentivized to get studied by academics (and they do). Large companies are not "highly incentivized" to optimize they're hiring process. Once a certain throughput is achieved, there's v…

Microsoft and Google do not collectively hire that many people and are not who I am talking about. “Brain-teaser” type questions are explicitly not work-sample tests and, yes, have no correlation with job performance.

IQ does correlate with work performance, and SAT tests are IQ tests. Brain teasers are an attempt at seeing how well/quickly your brain works to solve problems, is a rudimentary IQ test.

The problem is that requiring IQ tests for employment introduces liability that employers do not want.

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

#319

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…

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

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

#320

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…

Are things in place to make the job easier? Seniors don’t need easier and this is a huge turnoff. What? I feel like you have a very narrow-minded idea of what sr engineers want.

I differentiate between simple and easy. They aren't the same.
Post reply on HN