4 ms·

I think the assumption that white board coding is the worst way needs a bit more evidence. Certainly it sucks from some people, but also, some developers would

by jboy55 11y ago

I think the assumption that white board coding is the worst way needs a bit more evidence. Certainly it sucks from some people, but also, some developers would be very very uncomfortable casually talking with their prospective employer about things to prove they are smart. We do white board coding, but failing a white board coding isn't an automatic no, it just goes into the pool of info we know about the person. But what I look for in a white board coding isn't someone remembering some obscure coding or that they write perfect syntax, but just to see how they can take an algorithm and turn it into code and whether they can step through their code. All this bias against white board coding is kind of like a violinist saying I hate auditioning because the pressure of auditioning is nothing like playing in the orchestra. Yes its not, but its not unreasonable to have someone hear what you sound like live.

tjl 11y ago
There's a big problem with that analogy. With auditioning, you're doing the same thing you'd do professionally with basically the same tools. But, with whiteboard coding, you're doing it in a completely different environment. When I'm coding, I'm on a computer where I have access to a variety of tools and resources. Plus, you generally don't have someone evaluating you on the spot when you're coding. You have time to reflect. With a musician, you'll be performing and evaluated live which is very similar to an audition. I hate the live coding exercise because I like to work how I was taught (back in the 80s). If I'm trying to implement an algorithm, I write pseudo-code then turn that into the appropriate language. I can rely on my editor to help with the syntax as I turn that pseudo-code into a actual code.
- jboy55 11y ago
  Late reply. I am fine with pseudo-code in the coding question. I just want to know that the candidate can visualize an algorithm and get it into something concrete. Then be able to step through the code and tell me how the state of the machine will change. I could do this by just giving out a sample code and asking people to step through it, but I've seen difficulties with taking a spoken algorithm and turning it to code and I want to test that. I have seen some correlation between those struggles in interviews (its not a hard fail to fail the coding question) and in real life. I've discussed an approach with a coworker, then have them fail to write that into code that does what we discussed, just like they did in the interview. I have thought about bringing in a computer but I feel there's an added stress to typing correctly with someone in the room. Our phone screen coding question (really really simple) is done on a collaborative web environment, but that's a really simple 5 minute question.

by jboy55 11y ago

tjl 11y ago

There's a big problem with that analogy. With auditioning, you're doing the same thing you'd do professionally with basically the same tools. But, with whiteboard coding, you're doing it in a completely different environment. When I'm coding, I'm on a computer where I have access to a variety of tools and resources. Plus, you generally don't have someone evaluating you on the spot when you're coding. You have time to reflect. With a musician, you'll be performing and evaluated live which is very similar to an audition. I hate the live coding exercise because I like to work how I was taught (back in the 80s). If I'm trying to implement an algorithm, I write pseudo-code then turn that into the appropriate language. I can rely on my editor to help with the syntax as I turn that pseudo-code into a actual code.

jboy55 11y ago
Late reply. I am fine with pseudo-code in the coding question. I just want to know that the candidate can visualize an algorithm and get it into something concrete. Then be able to step through the code and tell me how the state of the machine will change. I could do this by just giving out a sample code and asking people to step through it, but I've seen difficulties with taking a spoken algorithm and turning it to code and I want to test that. I have seen some correlation between those struggles in interviews (its not a hard fail to fail the coding question) and in real life. I've discussed an approach with a coworker, then have them fail to write that into code that does what we discussed, just like they did in the interview. I have thought about bringing in a computer but I feel there's an added stress to typing correctly with someone in the room. Our phone screen coding question (really really simple) is done on a collaborative web environment, but that's a really simple 5 minute question.