3 ms·

> Exercises that try to mimic what the developer would be doing in the actual job as closely as possible. This one is critical. (the following is just inspired

> Exercises that try to mimic what the developer would be doing in the actual job as closely as possible. This one is critical. (the following is just inspired by your bullet) The job of a developer consists of problem solving something they have never encountered before (under some pressure), communicating to other developers, and demonstrating knowledge in various combinations and amounts over time. Startup developers are the hardest spots to fill and most delicate, so I tend to always think as if I'm hiring for a startup. Talking through a few whiteboard problems and talking about tools they have used (why and how) are sufficient. 30-45 minutes. I don't subscribe to adding more elements (environments, tools, test frameworks, etc). 3 people, 1 from the destination team, 1 from another team (if possible) and the immediate manager. Startups to multinational corporations, I'm still convinced this is the best way over the last 20 years. Interviews with higher management is just a redundant filter and another reason for the management to justify their existence. It's a job smell that every company has and is obviously prejudicial in every regard (trying to tease personal details or redundant workflow experience and opinions). It's a bad practice.

pytester 8y ago
>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.

pytester 8y ago

>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.