Comment by kaspiCZ | Hacker News Reader

Comment by kaspiCZ | Hacker News Reader

Parent Full thread

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.

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

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.

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

I fail to see how that particular point can ever be a negative for the hiring company. If you need specific skills, you dictate the environment. If you want the candidate to bring his own skills, just tell him to pick his favourite tools.

What I always prefer is a take-home programming assignment, and then present the results to a group of developers. You need to be able to explain what you did and answer questions about it.

I can explain the details of Dijkstra's algorithm. Does that mean I invented it?

There is a world of difference between "created something" and "can explain it in detail."

Reply on news.ycombinator.com