| I'd say homeworks are good. In a mix. In fact the process should be a mix. It's hard to get it right. You can find out if they copied the homework. There should always be a follow up talk about it. They should be able to explain the details. Ask them to add some functionality on spot. They have working code they should be familiar with and you can work with that. You want to test their approach more than anything. Bug fixing is hard to prepare right. If you have a clear cut position, that would eliminate part of bullet one. I'd argue that they should not be asked to find the bug. Only to fix it. It does not have to be the same bug. I'd argue for a pool they can pick from. You should be testing how they approach the problem and how they go about solving it. Heck you can debug and outline a fix for something you can't really code yourself, I know I did. Pairing with someone from the team they'd work in could also provide some insight into the dynamic. I agree there is no cookie cutter way for homework and bugs. That's why they need to be in a mix, well prepared and supervised. |
That doesn't prove anything. They could've hired a senior developer to help them and explain the concepts in detail.
> Ask them to add some functionality on spot. They have working code they should be familiar with and you can work with that. You want to test their approach more than anything.
The more 'real-world' this is, the more it's going to be biased towards those that have experience in a particular stack or with a particular type of development. Which isn't necessarily bad (it could even be good!), but it may be if you want a more agnostic interviewing process.