sbsi dhudbe
euidbt
Guide to scaling engineering organizations
11–20 of 148 posts
Re: Guide to scaling engineering organizations
#12This is the same process as with many other millennial-focused companies in SF.
ewqlly
Re: Guide to scaling engineering organizations
#13Judging 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.
yea i agrew
Re: Guide to scaling engineering organizations
#14>> 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-...
you r wrong
Re: Guide to scaling engineering organizations
#15Earlier 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…
What does this have to do with Stripe? They're pretty clear on this point: "Our questions seek to understand how people approach real world problems, rather than testing for esoteric skills you might demonstrate on a whiteboard."
Re: Guide to scaling engineering organizations
#16Earlier 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.
I've worked in companies that struggle to hire any candidate, let alone top candidates. Stripe is amongst the top employers. The vast majority of smaller shops (banks, b2b software companies, agencies) just need to staff up and would rather hire and fire than miss out on a good candidate.
Re: Guide to scaling engineering organizations
#17Earlier 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…
What does this have to do with Stripe? They're pretty clear on this point: "Our questions seek to understand how people approach real world problems, rather than testing for esoteric skills you might demonstrate on a whiteboard."
I'm referring to the long interview process, where there are two phone interviews and a day-long in person interview. It sounds like Stripe are trying to break the cycle of irrelevant questions during interviews, but it doesn't change the fact that a day-long interview is exhausting.
Re: Guide to scaling engineering organizations
#18Judging 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.
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 and false negative)
Re: Guide to scaling engineering organizations
#19Earlier 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.
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 the paid out wages (this is the case with most large scale employers in the US like retail, sales, etc).
FAANGS may have the funds together to hire out probably the rest of the entire software developer market but it doesn’t do them as much good to have laggards that can’t pass a FizzBuzz test. Sure works for a lot of defense contractors’ business models though, especially if the candidates are cleared.
Re: Guide to scaling engineering organizations
#20>> 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-...
I'm sure there are a lot of Google engineers willing to circulate an internal memo discussing the shortcomings of the IAT. After all they're a data-based company, right?