News for hackers. Stuff that matters.
Re:Guide to scaling engineering organizations by stevoski on Wednesday December 05, 2018 @09:46AM (#18608584)
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.

Re:Guide to scaling engineering organizations by ppeetteerr on Wednesday December 05, 2018 @09:51AM (#18608645)
I've heard somewhere that companies like Stripe would rather have false negatives than false positives in hiring.
Re:Guide to scaling engineering organizations by avip on Wednesday December 05, 2018 @09:59AM (#18608715)
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.
Re:Guide to scaling engineering organizations by devonkim on Wednesday December 05, 2018 @10:11AM (#18608843)
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 by ppeetteerr on Wednesday December 05, 2018 @10:15AM (#18608880)
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 by alexhutcheson on Wednesday December 05, 2018 @12:30PM (#18610398)
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 by devonkim on Wednesday December 05, 2018 @03:21PM (#18612114)
Every company I’ve seen that needed people dedicated just to fix bugs was in a downward spiral with maintenance mode software. Those organizations outside really slow moving but well financed bureaucracies are disappearing rapidly as investors pull money by divesting or selling to larger companies that wind up casting off the unprofitable / non-growing lines of businesses they acquired.

It’s pretty evil IMO to hire people as FTEs into such organizations when you are probably better off with consultants that are at least used to short term gigs.

Re:Guide to scaling engineering organizations by djg321 on Wednesday December 05, 2018 @04:23PM (#18612710)
Just out of curiosity, what is an example of a tech firm that would be considered a "body farm"?
Re:Guide to scaling engineering organizations by devonkim on Wednesday December 05, 2018 @06:10PM (#18613704)
Most of the services organizations that exist within enterprise tech companies scales very poorly and is supported by a high-margin software product or two. But the usually cited companies are Infosys, Capgemini, Wipro, Accenture. To make their businesses more sustainable / profitable they overwhelmingly favor labor cost arbitration and oftentimes aim at non-tech companies that still don't consider IT or software strategic to their business.

Then there's the "unintentional" body farms that organize due to structural reasons of massive funding combined with labor structure dictated to support a massive enterprise. Within defense, almost all the major defense contractors like Northrop, Lockheed, General Dynamics, and maybe Palantir these days (the bar for hiring is higher overall there, but not quite the full story) fight for huge, bloated Pentagon budgets that resembles VC funding except with military officers as partners and minimum headcounts are usually specified in contract vehicles. You'll oftentimes see at least n PhDs on staff, m veterans, p program managers, etc. as competitive factors for getting a contract ahead of other companies because with too small of a company it's deemed a risk to the government (people do take vacation, get into accidents, etc.). While there's been some efforts to make the RFP process better aligned towards outcomes, everything I've heard since I left the community has not been encouraging.

Re:Guide to scaling engineering organizations by mlthoughts2018 on Wednesday December 05, 2018 @01:48PM (#18611182)
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 by jhpriestley on Wednesday December 05, 2018 @02:26PM (#18611585)
Why are bad hires so damaging? I've encountered very unskilled coworkers, they didn't do any serious damage, just wasted some people's time and money.

I'd actually say the opposite: standout engineers can be very valuable, I'd rather work on a team with a couple lemons and one really good engineer than 3 middle of the road engineers. So I think that false negatives can be damaging, especially because it's probably the best people with the most options who won't bother with an excessive interview gauntlet.

Re:Guide to scaling engineering organizations by louthy on Wednesday December 05, 2018 @03:30PM (#18612202)
Unskilled is a problem of course, but with an unskilled, but ambitious individual, they can be mentored. In my mind a bad hire is someone that has a negative drag effect on the psychology of the work environment or the project.

I had one hire who was brought in as a junior dev, thought he was better than he was and that he didn't deserve to do the grunt work he'd been assigned, and then proceeded to constantly bitch about anything he could. He was so negative that when he finally moved on I was super relieved.

That psychology of "why even bother" can just sink into people's subconcious and become problematic. It's hard to spot who's going to be like that at an interview though.

Re:Guide to scaling engineering organizations by Shaanie on Wednesday December 05, 2018 @03:30PM (#18612199)
Lemons can significantly impede a team's velocity and, more importantly, the team's overall happiness. It's difficult to enjoy and take pride in your work when the code base either looks like shit or require that you spend most of your time reviewing/cleaning up the mess the lemons create.

Will your standout engineers enjoy working with the lemons?

Re:Guide to scaling engineering organizations by vonmoltke on Thursday December 06, 2018 @07:47AM (#18617549)
I could substitute "the business" for "lemons" above and describe many (most?) companies. In that case, what effect are these lemons really having?
Re:Guide to scaling engineering organizations by avip on Wednesday December 05, 2018 @02:48PM (#18611768)
Not sure your 'lemons' qualify as 'bad hires'. I've refrained from defining, as it requires context, but the 2 pillars of badhirism are negative productivity and negative attitude. Being "unskilled", by itself and in void, does not imply a bad hire IMO. We are all "unskilled" occasionally.
Re:Guide to scaling engineering organizations by inimino on Thursday December 06, 2018 @03:33PM (#18621917)
Mostly because of bad management and an inability to fire people even when it is clear that they should.

Generally a hiring process is a good hint to the dysfunctions of a team before you join. Panic about bad hires and a quintuple-filtered pipeline is a good sign of weak management and a structural inability to fire.

Re:Guide to scaling engineering organizations by ChrisCinelli on Thursday December 06, 2018 @07:10AM (#18617307)
Intuitively I wanted to say "Yes 1000 times, unless you REALLY need to hire NOW, the effects of a bad hire are going to be a lot more negative than a no hire".

But what about a very good hire that you end up missing that has been a very expensive mistake?

I think we have a pretty high bias here. Organizations can see the effect of a bad hire and have more data on what went wrong during the hiring process, retrospect why that person passed and put more "tests" to prevent to repeat the mistake. But organizations can never measure the differential between the impact on the company of a candidate that was not hired and the present condition. There is simply no data about the impact that that person could have had.

I heard a few detailed stories on "the guy that should not have been hired" and I can add my own stories. But the stories on the cool people that should have been hired are brief and rarely go beyond "I thought that guy was very smart."

So I think we should make sure we check our hiring processes against negative positives. How? To be continued...

Re:Guide to scaling engineering organizations by lawn on Wednesday December 05, 2018 @02:24PM (#18611546)
It's missing nuance.

For most companies missing out on an excellent hire is worse than hiring someone subpar.

Re:Guide to scaling engineering organizations by ppeetteerr on Wednesday December 05, 2018 @10:08AM (#18608804)
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 by rizzom5000 on Wednesday December 05, 2018 @10:56AM (#18609364)
Maybe, but hire and fire is also a great way to show the team that you don't know what you're doing as a hiring manager; not to mention how firing a team member, who may be incompetent but still well-liked, affects morale. Then, there is the problem where you fail to fire when you should. To me, this is just not a good way to build an effective team.
Re:Guide to scaling engineering organizations by ppeetteerr on Wednesday December 05, 2018 @11:59AM (#18610089)
No one is saying you should hire and fire a ton of people, only that rejecting good candidates for most companies is not possible given how difficult it is to find them. Talk to any recruiter and they will tell you that finding good (not great, just good) candidates is often a struggle.
Re:Guide to scaling engineering organizations by inimino on Thursday December 06, 2018 @03:39PM (#18621964)
> hire and fire is also a great way to show the team that you don't know what you're doing

It's an expensive (painful) signal that you actually do know what you need to do and are capable of it.

Re:Guide to scaling engineering organizations by sheepmullet on Wednesday December 05, 2018 @03:54PM (#18612438)
> I've heard somewhere that companies like Stripe would rather have false negatives than false positives in hiring.

The top tech companies can reject 10 good candidates for every 1 that they hire because there is a massive surplus of engineers who want to work for these companies and so time to hire for them is actually reasonable.

99% of tech companies don’t have the overwhelming surplus of good applicants to make this work. So when they try they see time to hire jump from 4-8 weeks all the way up to 6-12 months without any real decrease in false positives.

Re:Guide to scaling engineering organizations by beagle3 on Wednesday December 05, 2018 @10:10AM (#18608837)
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 by wlll on Wednesday December 05, 2018 @10:18AM (#18608923)
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 by sheepmullet on Wednesday December 05, 2018 @04:01PM (#18612493)
> 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.

Exactly! If a couple of people on my team of six leave and they can’t be replaced for 6-12 months then I’m going to quit as well.

There will be more pressure on the remaining team to produce and most of the interesting long term work will be put on hold.

Re:Guide to scaling engineering organizations by jonathanoliver on Wednesday December 05, 2018 @10:19AM (#18608941)
A false negative has zero realized cost. I would say there's missed opportunity cost.
Re:Guide to scaling engineering organizations by beagle3 on Thursday December 06, 2018 @03:31AM (#18616315)
Yes. But a false positive has negative realized cost AND missed opportunity cost; I was implicitly subtracting the missed opportunity cost as it appears in both, but it should be stated explicitly - Thanks.
Re:Guide to scaling engineering organizations by mandeepj on Wednesday December 05, 2018 @10:26AM (#18609023)
> Stripe would rather have false negatives than false positives in hiring

That's the case with Amazon and Google also.

Re:Guide to scaling engineering organizations by ummonk on Wednesday December 05, 2018 @11:52AM (#18610012)
I was under the impression that for junior hires amazon has a low hiring bar but is aggressive in firing afterwards.
Re:Guide to scaling engineering organizations by mebassett on Wednesday December 05, 2018 @09:53AM (#18608656)
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.

Re:Guide to scaling engineering organizations by stevoski on Wednesday December 05, 2018 @10:01AM (#18608742)
The onsite interview is further broken down into 5-6 interviews, according to the flowchart in the article.
Re:Guide to scaling engineering organizations by ppeetteerr on Wednesday December 05, 2018 @09:57AM (#18608693)
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 anyway due to the archaic method of evaluating technical candidates.
Re:Guide to scaling engineering organizations by patio11 on Wednesday December 05, 2018 @10:12AM (#18608856)
(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 by ppeetteerr on Wednesday December 05, 2018 @10:16AM (#18608893)
Thanks for clarifying mate. It's nice to hear your company is changing the status quo.
Re:Guide to scaling engineering organizations by ummonk on Wednesday December 05, 2018 @11:57AM (#18610065)
This actually seems to be the norm at most startups. Coding exercises on laptop, and design and behavioral interviews.

I’ve mostly seen algorithm / data structure questions at megacorps, which are probably too big with too much inertia to quickly reform their processes.

Re:Guide to scaling engineering organizations by julianozen on Wednesday December 05, 2018 @10:38AM (#18609164)
I actually recently interviewed at Stripe (did not receive an offer) and though the day was long, Stripe question’s were very fair and relevant to the job. This was true from my first phone call to all my onsite questions. I was very impressed by the preparation they had put into their interview questions.

So if you work at Stripe and are reading this, good work improving interviewing process

Re:Guide to scaling engineering organizations by digaozao on Wednesday December 05, 2018 @08:02PM (#18614441)
Can you give examples of the questions?
Re:Guide to scaling engineering organizations by julianozen on Wednesday December 05, 2018 @10:26PM (#18615118)
Sorry! Unfortunately I don’t think that’s be fair to them or other candidates.

To be honest, I’m not even sure how they’d interview me again. It seems like it’d be a lot of work to have multiple versions of their interviews and at this point I know the answers to everything they showed me

Re:Guide to scaling engineering organizations by romanhn on Wednesday December 05, 2018 @10:04AM (#18608776)
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 by ppeetteerr on Wednesday December 05, 2018 @10:10AM (#18608833)
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 by sonnyblarney on Thursday December 06, 2018 @12:41AM (#18615707)
What one does on a whiteboard is not very esoteric.
Re:Guide to scaling engineering organizations by sigi45 on Wednesday December 05, 2018 @10:18AM (#18608919)
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 by cbhl on Wednesday December 05, 2018 @11:08AM (#18609502)
From what I've heard of Stripe, this is a non-issue for them. Like Google/Facebook, their brand and compensation are strong enough that they have enough candidates at the top of the funnel. Plus they have specialized processes to explicitly reach groups of candidates that they're worried about missing (hiring through Triplebyte; posting on top universities' job boards; diversity programs like offering job interviews at Grace Hopper).