3 ms·

>Talking through a few whiteboard problems and talking about tools they have used (why and how) are sufficient. I've done interviews with a whiteboarding "tell

>Talking through a few whiteboard problems and talking about tools they have used (why and how) are sufficient. I've done interviews with a whiteboarding "tell me about stuff you've worked on" component followed by a test. It thought it gave a weak signal about the skills of the candidate. I canned it eventually because the test gave a very strong signal and it wasn't telling me anything the test didn't. >Interviews with higher management is just a redundant filter and another reason for the management to justify their existence. I agree. I had suspicions in a previous company that this upper management "team fit" interview was adding a race/nationality filter that ended up with good candidates getting dropped.

ArchTypical 8y ago
> https://medium.com/@alexgolec/google-interview-questions-deconstructed-the-knights-dialer-impossibly-fast-edition-c288da1685b8 https://medium.com/@alexgolec/google-interview-questions-dec... I'm really frustrated when these kind of problems are presented as "whiteboard" problems. It's not constructive and discouraging to potential employees. When something as simple as "implement X without using Y" or "fix this program with pseudocode" are practically useful experiments and more indicative of what developers are doing to be doing ALONE every day. If there's inefficiency, code reviews and planning and integration all reveal that and you can pull in specialized resources if you really need it.