Guide to scaling engineering organizations • Hacker News Board

Re: Guide to scaling engineering organizations

#51

Post by paulie_a » Wed, Dec 05, 2018, 5:28 PM UTC

Fede_V wrote: post #40

ainiriand wrote: post #38

Some time ago I went to the Dublin open house because they were opening news teams here and one of the positions was backed api engineer. Considering that I've been doing the same for almost 10 years and that I got personally invited to the event I decided to apply to the role. They rejected me even before having a personal interview. I wonder what is happening behind the scenes but it was very demoralizing. Was anyt…

In my experience, it's incredibly difficult to get a strong positive signal from a CV. You can definitely find red flags (my favorite example: people describing themselves as experts deep learning with 1 year of experience and zero publications) - but, after removing the obviously unqualified, the next steps have very low accuracy. Honestly, it might have just been a sourcer/recruiter fuck up. If you can at all, ask…

Honestly I dont that is true regarding CV, sure you can filter some extremely easily but its also pretty easy to see the good candidates even if there resume is terrible. Following up with a phone call will confirm it. And rarely result in an inept candidate. No offense to recruiters because they put in the work of sorting. But finding quality candidates to actually interview, those are easy to spot.

Re: Guide to scaling engineering organizations

#52

Post by alexhutcheson » Wed, Dec 05, 2018, 5:30 PM UTC

ppeetteerr wrote: post #22

devonkim wrote: post #19

Earlier quoted context omitted.

I wouldn’t say ANY company necessarily. A lot of companies even in IT are body farms and low wage, expendable (but still necessary) labor is their lifeblood where they trade off quality for more volume. Employee turnover doesn’t matter much besides in the highest ranks in that case either. A “bad” hire in such companies is one that causes such irreparable harm that it costs the company more in reputation / brand than…

You don't have to be a body farm to justify someone considered a "false positive" at a large employer. Most companies outside of the top employers have a hard time staffing up. They might just want someone to fix their bugs, not someone aspiring to invent the next Kubernetes.

Unless you have clearly defined separate roles, titles, career ladders, etc. for the "bug fixers", this isn't a recipe for success. You would end up with an underclass of employees that are unhappy that they don't have the same career opportunities as others in their role, and a bunch of unhappy managers who are given the difficult task of enforcing this division.

If you just need someone for narrowly-scoped tasks like fixing specific bugs, it might be better to hire a contractor, so the role expectations can be well-defined and agreed to up front.

Re: Guide to scaling engineering organizations

#53

Post by zoba » Wed, Dec 05, 2018, 6:25 PM UTC

I really enjoyed this post, but, I would’ve liked to see more information about engineering team size when these things happened.

For instance, the idea of “rotations” doesn’t make as much sense when there are 5 engineers versus 100. There were several instances where I would’ve liked to have known team size as a benchmark.

Re: Guide to scaling engineering organizations

#54

Post by jmcomets » Wed, Dec 05, 2018, 6:27 PM UTC

scarejunba wrote: post #43

Nice post, guys. Would you mind saying what you mean by 'lurking'? In all my life on the Internet, it's a positive thing when joining a community. You're invisible to everyone and just read. Why should people not do this? It seems harmless to be in read-only mode.

I understood the use of "lurking" as "commenting unproductively in a channel". Although I may be mistaken, it makes a lot of sense to avoid such toxic behavior.

Re: Guide to scaling engineering organizations

#55

Post by mlthoughts2018 » Wed, Dec 05, 2018, 6:44 PM UTC

zoba wrote: post #53

I really enjoyed this post, but, I would’ve liked to see more information about engineering team size when these things happened. For instance, the idea of “rotations” doesn’t make as much sense when there are 5 engineers versus 100. There were several instances where I would’ve liked to have known team size as a benchmark.

Rotations also don’t make sense for product or domain specialists, or people with career aspirations to focus on one specialization. As an ML engineer, I would quit immediately if I had to go through a rotation doing web development. But if you ask me to do occasional web development to deliver my ML product to customers, I’ll do it whole heartedly and solve it very fast.

Re: Guide to scaling engineering organizations

#56

Post by mlthoughts2018 » Wed, Dec 05, 2018, 6:48 PM UTC

avip wrote: post #8

ppeetteerr wrote: post #4

Earlier quoted context omitted.

I've heard somewhere that companies like Stripe would rather have false negatives than false positives in hiring.

That's the logical tradeoff for any company. Bad hires create an incredible amount of damage that can sink a whole team. It is x10 better to have no hire than a bad one.

This is repeated so much but it’s just wrong. Companies are usually very socially toxic places, and the definition of “bad hire” is usually subverted to mean “does not capitulate to our bad monoculture.” It has nothing to do with hiring positive people, skilled people, etc.

Re: Guide to scaling engineering organizations

#57

Post by ownagefool » Wed, Dec 05, 2018, 6:50 PM UTC

jmcomets wrote: post #54

scarejunba wrote: post #43

Nice post, guys. Would you mind saying what you mean by 'lurking'? In all my life on the Internet, it's a positive thing when joining a community. You're invisible to everyone and just read. Why should people not do this? It seems harmless to be in read-only mode.

I understood the use of "lurking" as "commenting unproductively in a channel". Although I may be mistaken, it makes a lot of sense to avoid such toxic behavior.

Weird, it's always meant reading and not posting to me, such as the parent suggested.

Re: Guide to scaling engineering organizations

#58

Post by o_____________o » Wed, Dec 05, 2018, 6:53 PM UTC

syntaxing wrote: post #29

I really enjoy reading Stripe's posts. I remember they posted one about APIs and it was super fun to read [1]. Though to be honest, I think a title of "Guide to scaling software engineering organizations" seems more appropriate. I dread of a day where it's the norm for foundational engineers to have a similar interview structure as software engineers now. [1] https://stripe.com/blog/api-versioning

What is a "foundational engineer"?

Re: Guide to scaling engineering organizations

#59

Post by bit_logic » Wed, Dec 05, 2018, 7:10 PM UTC

Probably the most important these days: don't blindly follow the interview process of big tech companies. They have an almost endless queue of very good candidates. Any other company has the exact opposite problem. They treat their candidates poorly (ridiculous whiteboard algorithm questions) and don't really care about losing good candidates. Other companies can't do this, they are lucky to even get good candidates applying.

Re: Guide to scaling engineering organizations

#60

Post by repsilat » Wed, Dec 05, 2018, 7:10 PM UTC

ainiriand wrote: post #38

Some time ago I went to the Dublin open house because they were opening news teams here and one of the positions was backed api engineer. Considering that I've been doing the same for almost 10 years and that I got personally invited to the event I decided to apply to the role. They rejected me even before having a personal interview. I wonder what is happening behind the scenes but it was very demoralizing. Was anyt…

Better a rejection than complete radio silence, though.

I went through a job hunt a couple of months ago. CV screening was by far the most stringent part of the process for me. I passed all of my phone screens and got offers from most of my on-sites, but getting an interview from an application was a crapshoot. Thankfully most rejections at that stage were prompt and unambiguous (though as you say, not helpful/informative.)

Lyft was an exception, though. Their application page said something along the lines of "We respect your time, so we won't respond back if you don't make the cut." Pretty ironic, not responding back is about the most disrespectful thing they can do at that point in the process -- certainly worse than a curt "fuck off".

(By contrast I loved Stripe's interview process.)