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.

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.

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.

> Having people actually try to make the code runnable would make things so much worse...

I’m not sure I follow here. For me, programming is an iterative process: write a small chunk, test it out, write the next bit, and so on. Not being able to execute code seems like it would make that process harder, and force interviewee to essentially come up with the code “fully formed” all at once, which is hardly a useful or realistic skill.

I've never run into this as a hirer. I don't test to see if a candidate can implement an algorithm from memory. In my test, I describe the steps for the algorithm and see if they can "follow the spec". I find most candidates (even seniors) can't, they can't help but make it 'more complicated than the spec asks for'.

Neither do I. I want to see how they work through the problem, focusing on the problem. The IDE takes their focus away in my experience, they start correcting the squiqlies and adding extra bits of syntax that don't matter in a pseudo-code setting (such as adding closing brackets they forgot earlier) to avoid auto-spacing issues and so on.

It may take a bit of extra time but one other positive of coderpad I found is that because it offers library-level auto-complete I noticed people relax a bit since they are not afraid I will ding them for not knowing some common method name or syntax.

To me that's exactly the problem: I don't care if they call it sort or orderBy and so on, and I make this abundantly clear. Them spending time and mental energy to change the order of params or other things like that distracts from the core issues we are trying to solve together.

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.

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.

> IMO You should really reconsider disabling execution

Not my call; it’s an org-wide setting (we use coderpad with SSO that lets the company control some of the settings).

If someone suggested using their own IDE and screen sharing instead, I would 100% let them do it.

nice! Yeah, I much prefer using my own IDE over coderpad.

Strong disagree; every coderpad interview I've given or received specifically did _not_ write executable code, and that was either explicitly communicated or just assumed by everyone involved.

> Otherwise you might as well use Google docs. Coderpad has other useful features like syntax highlight, autocomplete (I think?), and the private interviewer notepad with timestamps.

> 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.

When interviewing for Facebook, I was made aware ahead that it won't be executable. Still used CoderPad.

Whenever I use coderpad I make sure to mention the code execution to my applicants and give them a choice of using it vs. just pseudocode and collaborative editing. But most of the time people appreciate the feature and like using it.

when was this? I'm pretty sure facebook explicitly mention this in their preparation email now.

Last October.