7 ms·

One of the founders said on this forum that the anecdote which described a poor hiring experience was to them an aberration. Now that other anecdotes are comin

by mc32 5y ago

One of the founders said on this forum that the anecdote which described a poor hiring experience was to them an aberration. Now that other anecdotes are coming out of the woodwork, it seems maybe it may not be an exception but a broken internal process which needs fixing. That said, we don’t know the full picture and whether the incidence is within range or outside the range for their industry. That’s not yo say there shouldn’t be improvement. The industry and the company may very well benefit from a change in practices.

kelnos 5y ago
I treat founder anecdotes as likely untrue (though usually not maliciously). Once a company gets as large as Stripe has, leadership really has no idea what's going on with the details of running the business.
- jonny_eh 5y ago
  And yet they're still responsible. Their management style trickles down and becomes the organization's culture.
systemvoltage 5y ago
I didn’t comment on the original thread but I too had a bad experience with Stripe. They wasted my time for 3 weeks and finally ghosting me. I hope Stripe takes a deep look into how their employees reach out to people and trace down every hiring related emails. Patrick - I would start a task force for this internally and hold people accountable for being assholes. No matter how your people are busy, I rank my own time higher and wasting it pisses me off to no end.
noleetcode 5y ago
Anecdotal on my part, but I interviewed with them earlier this year. I was told by the recruiter (an internal recruiter, to be clear, not a third-party), in no uncertain terms, that their interview process did not involve "leetcode-style problems" and would, instead, be a "real world problem" close to what an engineer might be expected to solve normally. I was told (and this was reflected in the interview prep materials they provided) that bringing my own IDE and screen-sharing was the norm, although they would be prepared with a collaborative online editor as backup. It would be a collaborative session where the interviewer would work through the problem with me (obviously with myself in the driver's seat). I was reasonably excited. Finally, a tech firm that didn't cargo-cult leetcode hazing. And then came the interview. I leave it to the reader to guess at the nature of the problem (hint: it starts with 'l'). The interviewer also seemed entirely unprepared and surprised that I was prepared with my own IDE. They were also unwilling to collaborate, and unwilling to accept how I approached solving the problem (I like to write experimental pseudo-code out first as I think through things, especially when in an environment where drawing things out isn't easy. I let them know that was what I was doing and explained my thought process as I wrote it, and yet they kept interrupting and explaining that I could clean that code up... code that was not meant to be "final" or "complete"...) It was just a terrible experience from beginning to end. From the recruiter presenting an interview plan that was clearly not in line with reality, to the interviewer being unprepared for what their own interview prep materials described (BYOIDE!), to the interviewer's unprofessional and very unhelpful demeanor (if day-to-day engineering at Stripe involves being berated at every step as you prototype a solution to solve a leetcode problem before preparing to write the actual solution...well, maybe they should fix that)
- dnautics 5y ago
  Facebook was like "do you have experience using coderpad" "yes, I do... I've given interviews in it". Come time for the interview, I spend a considerable amount of time commenting out the stuff that the interviewer posted (could tell that she was looking at me like "why the hell is he doing that") into the coderpad, only to find out they had execution disabled. Fuck you, Facebook.
  - ajkjk 5y ago
    I feel like that's pretty common? In most interviews I've had/given you are not expected to write runnable code, and having to fix typos or library function names tends to be a stress-inducing distraction.
    - dnautics 5y ago
      Sure. Every whiteboard interview I have had has been like that, but the expectation with coderpad is that you write executable code. I've never taken or given an interview on coderpad that was otherwise, which is why I was shocked that was even possible as a feature on the platform. Otherwise you might as well use Google docs. Anyways there was a tooling communication problem. Clearly Facebook was new to the coderpad thing, they should have come out and said so, they should have communicated that you won't be able to execute, etc.
      - tsimionescu 5y ago
        Never used coderpad, but my experience holding (online/remote) code interviews is that even using an IDE with standard error highlighting and color coding is just a waste of time - people start concentrating on fixing typos and adding keywords, as they are conditioned by the red squigglies, and that just detracts from the point of the problem. Having people actually try to make the code runnable would make things so much worse... After experimenting with BYOIDE, we've stuck with online code style platforms (monotype fonts, no language-based Word-style auto-correct). This helps people focus on the problem, not the code itself, in my experience.

by mc32 5y ago

kelnos 5y ago

I treat founder anecdotes as likely untrue (though usually not maliciously). Once a company gets as large as Stripe has, leadership really has no idea what's going on with the details of running the business.

jonny_eh 5y ago
And yet they're still responsible. Their management style trickles down and becomes the organization's culture.

systemvoltage 5y ago

I didn’t comment on the original thread but I too had a bad experience with Stripe. They wasted my time for 3 weeks and finally ghosting me. I hope Stripe takes a deep look into how their employees reach out to people and trace down every hiring related emails. Patrick - I would start a task force for this internally and hold people accountable for being assholes. No matter how your people are busy, I rank my own time higher and wasting it pisses me off to no end.

noleetcode 5y ago

Anecdotal on my part, but I interviewed with them earlier this year. I was told by the recruiter (an internal recruiter, to be clear, not a third-party), in no uncertain terms, that their interview process did not involve "leetcode-style problems" and would, instead, be a "real world problem" close to what an engineer might be expected to solve normally. I was told (and this was reflected in the interview prep materials they provided) that bringing my own IDE and screen-sharing was the norm, although they would be prepared with a collaborative online editor as backup. It would be a collaborative session where the interviewer would work through the problem with me (obviously with myself in the driver's seat). I was reasonably excited. Finally, a tech firm that didn't cargo-cult leetcode hazing. And then came the interview. I leave it to the reader to guess at the nature of the problem (hint: it starts with 'l'). The interviewer also seemed entirely unprepared and surprised that I was prepared with my own IDE. They were also unwilling to collaborate, and unwilling to accept how I approached solving the problem (I like to write experimental pseudo-code out first as I think through things, especially when in an environment where drawing things out isn't easy. I let them know that was what I was doing and explained my thought process as I wrote it, and yet they kept interrupting and explaining that I could clean that code up... code that was not meant to be "final" or "complete"...) It was just a terrible experience from beginning to end. From the recruiter presenting an interview plan that was clearly not in line with reality, to the interviewer being unprepared for what their own interview prep materials described (BYOIDE!), to the interviewer's unprofessional and very unhelpful demeanor (if day-to-day engineering at Stripe involves being berated at every step as you prototype a solution to solve a leetcode problem before preparing to write the actual solution...well, maybe they should fix that)

dnautics 5y ago
Facebook was like "do you have experience using coderpad" "yes, I do... I've given interviews in it". Come time for the interview, I spend a considerable amount of time commenting out the stuff that the interviewer posted (could tell that she was looking at me like "why the hell is he doing that") into the coderpad, only to find out they had execution disabled. Fuck you, Facebook.
- ajkjk 5y ago
  I feel like that's pretty common? In most interviews I've had/given you are not expected to write runnable code, and having to fix typos or library function names tends to be a stress-inducing distraction.
  - dnautics 5y ago
    Sure. Every whiteboard interview I have had has been like that, but the expectation with coderpad is that you write executable code. I've never taken or given an interview on coderpad that was otherwise, which is why I was shocked that was even possible as a feature on the platform. Otherwise you might as well use Google docs. Anyways there was a tooling communication problem. Clearly Facebook was new to the coderpad thing, they should have come out and said so, they should have communicated that you won't be able to execute, etc.
    - tsimionescu 5y ago
      Never used coderpad, but my experience holding (online/remote) code interviews is that even using an IDE with standard error highlighting and color coding is just a waste of time - people start concentrating on fixing typos and adding keywords, as they are conditioned by the red squigglies, and that just detracts from the point of the problem. Having people actually try to make the code runnable would make things so much worse... After experimenting with BYOIDE, we've stuck with online code style platforms (monotype fonts, no language-based Word-style auto-correct). This helps people focus on the problem, not the code itself, in my experience.