Hacker News Reader

This is an interesting perspective. I know that whiteboarding is the worst possible technique to personally face in an interview because of how my thought and creative processes work. Mostly I come to a new problem, explore it a bit, let myself do some background processing while I do something I know how to do in my sleep and then tackle the new problem. This is way more productive for me than dealing with the problem straight up where I would take the same about of time getting frustrated with the new problem while not doing anything productive.

Also I tend to work based on reference. I know a lot of computer science theory that I do not retain in RAM (so to speak). A little refresher on a topic brings a whole new set of knowledge into play than if it's just me and a whiteboard. I really don't mind doing interview coding exercises in my own time because it is much more natural and I think a fair representation of my abilities in the real world.

> Yes, it's brutal, and a bit ruthless, but effective.

I'm not saying that people who don't work out should not be let go, and I'm certainly not saying that you "owe" people anything. It's a business and not a charity. (Just remember that this goes the other way as well; people who show loyalty to some company are doing themselves a great disservice, in my opinion. I work for money. I'm passionate and will do great work, but I'm a mercenary.)

That being said, I would be very hesitant to go work at a place known to err on the side of just hiring someone and kicking them to the curb if it doesn't work out. Why? Because it can say a great deal about the management at that company, and how they will treat me. I also have no interest in being hired unless you are confident that I'm a great fit. I don't want anyone to take a chance on me. I want people to be delighted to hire me over someone else.

I guess I have the opposite stake on this. I'm a junior dev and I've been interviewing multiple times a week for the last month and a half. I've gotten better at interviewing but I still mess up on something and remember later on what the answer was. Now I get passed on the job because I failed the interview. I would rather an employer take a little chance on me and let me prove that I'm a competent developer and a hard worker. I would rather prove that on the job instead of in an interview.

Edit fixed some typos.

You are forgetting that the ability to fire people for performance are very limited in many situations. That places some constraints on it. For example, in many countries it's very hard to fire someone for performance reasons. The same also applies everywhere, for first hires in young companies. You just can't make a mistake.

Discovering that someone is a poor programmer after you actually learn first hand that they are, may be a solution to the problem of aquiring a good team long term in a medium or large company, but it's not a solution to the problem of minimizing the risk of hiring ONE bad programmer.

Whiteboarding is fine in limited amounts.

Something like:

Here are two tables. How would you improve their design?

Now select all XYZ from them.

Now, here is a list/array of items and some search input, return a list/array with only those that match.

Finally, Fizzbuzz.

Total time of 5 or so minutes, and it will quickly eliminate those who have high charisma but no actual skills. This part can be replaced via a github account or such, but not everyone has one (or one they are willing to share with an employer/professionally tie their identity to).

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.

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.

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.