3 ms·

1) A test that tries to mimic what the developer would be doing in the actual job as closely as possible. This is what most interviewers fail at - they seek out

1) A test that tries to mimic what the developer would be doing in the actual job as closely as possible. This is what most interviewers fail at - they seek out stupid proxies like whiteboarding rather than simply trying to mimic real life. 2) > 45 min < 3 hours long pairing test or test otherwise done in the presence of the interviewer. 3) Minimal setting up development environments, frameworks or test environments. No boilerplate should be required during the test. 4) The test is improved iteratively. Catch bugs during each interview process and fix them in subsequent interviews.

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

ArchTypical 8y ago

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