5 ms·

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

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.
    - aqme28 5y ago
      > Every whiteboard interview I have had has been like that, but the expectation with coderpad is that you write executable code. I always say that isn't the case at the top of my interviews, because otherwise it's a handicap for people interviewing remote.
    - hamburglar 5y ago
      I give coderpad interviews all the time and absolutely do not expect them to be executable. If you write me executable code, great, but you’re probably wasting your time. We also have execution disabled in my org. It’s just a notepad that we both can see that kinda half-ass supports code highlighting and formatting. I hope I’m never asked to write executable code in it because as an editor, it’s terrible.
      - dnautics 5y ago
        IMO You should really reconsider disabling execution and just tell the candidate that executable is not expected. Writing tests and executing them is an extremely important part of my programming flow, and when I am presented with a tool that I expect to be able to actively test with, if I am unable to do so... it's "fuck you Facebook"-level frustrating. I guess it's yours hiring process, so whatever, but you could probably be filtering out people with very good and desirable programming habits. I've also had some serious problems with (senior) coworkers who "assert their code works" when it's riddled with bugs or flat out doesn't work, so maybe it's my trauma refected here > I hope I’m never asked to write executable code in it because as an editor, it’s terrible. Well, I typically offer coderpad for anyone who would rather not share their screen.
deleted 5y ago
[deleted]
acconrad 5y ago
> They were also unwilling to collaborate, and unwilling to accept how I approached solving the problem Wow. Similar thing happened to me with Stripe. It was a system design interview. I had already seen a very similar problem and aced it with Amazon. This person just kept saying "we don't have time for this, we need to get through this whole system" - wouldn't even let me finish my thought. It was arbitrary whether they wanted me to dive into a section of the system more or if I was boring them (and they did not seem excited/engaged to present this interview) and taking too long explaining my decision. Stripe was the only company I didn't pass (and I passed multiple FAANG interviews) and it was the only company who told me twice that the role I was applying for either was filled or "shifted priorities" and they would scramble to find me another role with another hiring manager. And I am certain it was because of this one system design interview that we just did not click on.
- inetknght 5y ago
  Your comment and the parent comment smell like a company utilizing the hiring process to abuse potential candidates to actually solve the company's problems without paying them.

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.
  - aqme28 5y ago
    > Every whiteboard interview I have had has been like that, but the expectation with coderpad is that you write executable code. I always say that isn't the case at the top of my interviews, because otherwise it's a handicap for people interviewing remote.
  - hamburglar 5y ago
    I give coderpad interviews all the time and absolutely do not expect them to be executable. If you write me executable code, great, but you’re probably wasting your time. We also have execution disabled in my org. It’s just a notepad that we both can see that kinda half-ass supports code highlighting and formatting. I hope I’m never asked to write executable code in it because as an editor, it’s terrible.
    - dnautics 5y ago
      IMO You should really reconsider disabling execution and just tell the candidate that executable is not expected. Writing tests and executing them is an extremely important part of my programming flow, and when I am presented with a tool that I expect to be able to actively test with, if I am unable to do so... it's "fuck you Facebook"-level frustrating. I guess it's yours hiring process, so whatever, but you could probably be filtering out people with very good and desirable programming habits. I've also had some serious problems with (senior) coworkers who "assert their code works" when it's riddled with bugs or flat out doesn't work, so maybe it's my trauma refected here > I hope I’m never asked to write executable code in it because as an editor, it’s terrible. Well, I typically offer coderpad for anyone who would rather not share their screen.

deleted 5y ago

[deleted]

acconrad 5y ago

> They were also unwilling to collaborate, and unwilling to accept how I approached solving the problem Wow. Similar thing happened to me with Stripe. It was a system design interview. I had already seen a very similar problem and aced it with Amazon. This person just kept saying "we don't have time for this, we need to get through this whole system" - wouldn't even let me finish my thought. It was arbitrary whether they wanted me to dive into a section of the system more or if I was boring them (and they did not seem excited/engaged to present this interview) and taking too long explaining my decision. Stripe was the only company I didn't pass (and I passed multiple FAANG interviews) and it was the only company who told me twice that the role I was applying for either was filled or "shifted priorities" and they would scramble to find me another role with another hiring manager. And I am certain it was because of this one system design interview that we just did not click on.

inetknght 5y ago
Your comment and the parent comment smell like a company utilizing the hiring process to abuse potential candidates to actually solve the company's problems without paying them.