3 ms·

There are different approaches, but you can come up with any simple programming task. Doubts are fine, so just run them through some of your existing engineers,

There are different approaches, but you can come up with any simple programming task. Doubts are fine, so just run them through some of your existing engineers, especially those you think are really good. If people you consider excellent engineers fail them, then it's back to the drawing board. That's an exercise I do for hiring in general. For example, every time a hiring process change is proposed, I run it through my existing engineers, and make sure I would have hired them by this process. For example, in a place that was starting to get a lot of great candidates, someone proposed tightening the education requirements of the preliminary screen. I quickly observed that would have disqualified one of my best performers, who didn't have a CS degree at all. The proposition was therefore struck down.

PopeDotNinja 8y ago
> There are different approaches, but you can come up with any simple programming task. My challenge internalizing this phrase is that I have a hard time latching onto the idea of simple. It's a highly subjective measurement. For example, if I ask an to implement FizzBuzz & they can't do it, to my satisfaction, are they a not worth hiring? I suppose it depends on what satisfies me. If my criteria for hire/no-hire is whether they wrote concurrent & streaming FizzBuzz, maybe my expectations are unrealistic. If I'm expecting someone to write FizzBuzz in as few characters as possible, am I going to flunk anyone who implements a verbose concurrent & streaming FizzBuzz? Is there a case where it makes sense to hire someone who implements Enterprise FizzBuzz? I may struggle myself with keeping things simple, so there's that to consider :)