Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Guide to scaling engineering organizations

stripe.com

Post reply on HN
Print view View original

21–30 of 148 posts

Re: Guide to scaling engineering organizations

#21

Post by patio11 »

ppeetteerr wrote: post #7
mebassett wrote: post #5

Earlier quoted context omitted.

What makes you think that? the article suggests a phone call with a recruiter, a video call with a tech team, and an onsite interview. 2 phone calls and an onsite doesn't seem like an excessive amount of interviews.

If you've ever done an onsite interview, you'd understand what a gruelling experience 6 hours of whiteboard problem solving really is. The worst part, of course, is that these exercises are completely irrelevant to the work most candidates will do on a day to day. That alone feels like a joke. Not to mention that you will be judged by people who also don't care about how well you balance a tree but are forced to anyw…

(I work at Stripe and, while I don’t do engineering interviews, have strong views on the topic, which may or may not be equivalent to our views. I believe the following is substantially accurate regarding factual representations.)

We don’t do whiteboard interviews for coding. If we have a coding interview, candidates can do it on their choice of their machine or a loaner machine from us with one of a few environments installed.

Most interview loops have approximately two 45 minute coding interviews. The other interviews might focus on (depending on job/seniority/etc) design, architecture, product sense, industry knowledge, communication style, etc. (Each interview tests one cluster of skills against a rubric, as explained in the linked article.)

Re: Guide to scaling engineering organizations

#22

Post by ppeetteerr »

devonkim wrote: post #19
avip wrote: post #8

Earlier quoted context omitted.

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.

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.

Re: Guide to scaling engineering organizations

#23

Post by ppeetteerr »

patio11 wrote: post #21
ppeetteerr wrote: post #7

Earlier quoted context omitted.

If you've ever done an onsite interview, you'd understand what a gruelling experience 6 hours of whiteboard problem solving really is. The worst part, of course, is that these exercises are completely irrelevant to the work most candidates will do on a day to day. That alone feels like a joke. Not to mention that you will be judged by people who also don't care about how well you balance a tree but are forced to anyw…

(I work at Stripe and, while I don’t do engineering interviews, have strong views on the topic, which may or may not be equivalent to our views. I believe the following is substantially accurate regarding factual representations.) We don’t do whiteboard interviews for coding. If we have a coding interview, candidates can do it on their choice of their machine or a loaner machine from us with one of a few environments…

Thanks for clarifying mate. It's nice to hear your company is changing the status quo.

Re: Guide to scaling engineering organizations

#24

Post by bhuga »

gadders wrote: post #3

>> In addition to building clear rubrics, we began unconscious bias training to maintain consistency and objectivity. Is that still valid? I thought the tests to support this concept had failed to be replicated? http://nymag.com/intelligencer/2017/12/iat-behavior-problem.... https://www.thecut.com/2017/01/psychologys-racism-measuring-...

Unconscious bias is not implicit association. Unconscious bias is rationalizing decisions based on the candidate's personal characteristics as something else. Studies about unconscious bias readily replicate, i.e. https://hbswk.hbs.edu/item/minorities-who-whiten-job-resumes...

Most training to overcome unconscious bias is about defining criteria before you see a candidate. If, before you view resumes, you've written down "We want someone with a master's degree and 4 years of experience in field X," you're much less likely to pass over a qualified resume, regardless of the candidate's personal characteristics.

Re: Guide to scaling engineering organizations

#25

Post by sigi45 »

ppeetteerr wrote: post #7
mebassett wrote: post #5

Earlier quoted context omitted.

What makes you think that? the article suggests a phone call with a recruiter, a video call with a tech team, and an onsite interview. 2 phone calls and an onsite doesn't seem like an excessive amount of interviews.

If you've ever done an onsite interview, you'd understand what a gruelling experience 6 hours of whiteboard problem solving really is. The worst part, of course, is that these exercises are completely irrelevant to the work most candidates will do on a day to day. That alone feels like a joke. Not to mention that you will be judged by people who also don't care about how well you balance a tree but are forced to anyw…

At least for Google i have to only hit the same bar as everyone else and will get an offer.

In all other companies i have to hit team specific bars.

Re: Guide to scaling engineering organizations

#26

Post by wlll »

beagle3 wrote: post #18
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.

Most definitely. A false positive often has negative contribution to the overall training (at the very least taking time from current members without giving back, but often also creating new problems). A false negative has zero cost (and zero benefit). I think it's a no-brainer that false negatives are much preferred to false positives in the overall tradeoff (and ... there is always a tradeoff between false positive…

While I agree with the sentiment, this isn't entirely true:

> A false negative has zero cost (and zero benefit).

False negatives means that your hiring process is longer, more difficult, more costly, and you therefore find it harder to grow, or to replace people who leave.

It may well be that avoiding false positives in general is better for the business, but it's not as clear cut as you make out I believe, it's a balance.

Re: Guide to scaling engineering organizations

#27

Post by jonathanoliver »

beagle3 wrote: post #18
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.

Most definitely. A false positive often has negative contribution to the overall training (at the very least taking time from current members without giving back, but often also creating new problems). A false negative has zero cost (and zero benefit). I think it's a no-brainer that false negatives are much preferred to false positives in the overall tradeoff (and ... there is always a tradeoff between false positive…

A false negative has zero realized cost. I would say there's missed opportunity cost.

Re: Guide to scaling engineering organizations

#28

Post by hoorayimhelping »

These are all great points and there are some good nuggets in this article but I feel like it misses the main issue with recruiting. The shortcoming in my experience, is hardly ever in the process, it's in the people who work in recruiting. When setting up pipelines, most of the people I worked with knew what we had to do - the points in this article are pretty obvious.

What isn't obvious is how to find the right people to help us do that, or how to avoid the wrong people. Because the wrong people on the recruiting side of things can easily drag down the entire organization very quickly. I've only worked with a handful of recruiters that were actually worth anything - I'd like to see more about how to find them, what qualities to look for, and how to vet them.

Building a process that doesn't suck is like bread and butter for day-to-day for a lot of engineers. A lot of us have been part of working recruiting pipelines and we've seen how it's supposed to work. It's usually pretty straightforward - what wee don't know is how to kickstart it with the right people. I'd love more information on the softer part of it, and the part that is often invisible to people iterating on the process - the specific contributions of individuals to get it up and running.

Re: Guide to scaling engineering organizations

#29

Post by syntaxing »

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

Re: Guide to scaling engineering organizations

#30

Post by mandeepj »

ppeetteerr wrote: post #4
stevoski wrote: post #2

Judging by the article, you need to go through a _lot_ of interviews before Stripe makes you an offer. I wonder if they miss out on whole groups of job candidates because those candidates have good job prospects that don't involve this gruelling slog. Of course, Stripe does seem to have an excellent team.

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

> Stripe would rather have false negatives than false positives in hiring

That's the case with Amazon and Google also.

Post reply on HN