|
I thought it was rare too until I started interviewing a lot. Yes, these candidates would typically be able to explain their involvement with previous projects, to give a technical overview of what they'd done. They would totally pass my bullshit filter. I thought I had a well-tuned bullshit filter. I was wrong. The programming problems are typically very simple, an order of magnitude simpler than an algorithm or design question that might be a part of the same interview. I don't want to give specific examples, but maybe implement one of a standard algorithms on an array or a tree (I'm not talking balanced trees, way simpler). Maybe do something that requires a nested loop and some bit-twiddling, or careful thinking about entries in a two-dimensional array, or a bit of smarts to hold some sparse data - but again, nearly trivial from the algorithmic point of view. There are many possibilities. What you want to check is whether the candidate can think through their own code, whether they know to check for edge cases, whether they think of test cases, how they deal with off-by-1 possibilities, how they debug their own code, do they have a reasonably clear style. What you tend to see when a candidate fails such an assignment is people who don't remember the mask to fill a byte with 1's, who can't get a nested loop right because they can't seem to keep two counters in their head at the same time, who don't have the instinct to check for an off-by-1, who can't trace through their own code visually with sample arguments, etc. etc. Sometimes they had just impressed you a lot a few minutes before with a nice technical summary of what they did in their previous project. |