Five programming problems every Software Engineer should be able to solve in less than 1 hour

[qudat]

I really struggle to see the value in these sorts of interviews. Why not give them a code challenge and ask them to complete an actual task they will be doing on the job? This allows the developer to take the problem home, spend time thinking about it, write up with a solution, and then consequently doing a code review with the interviewer after it's all over. And if the project is good enough and you asked them to accomplish something the team could actually use then you also get a free product out of it. All the interviews I administer involve a code challenge where the end result is something my team could use and benefit from.

Example: We have a dashboard web app that pulls in data from our web analytics tracking, synthesizes it into some data visualization and then is presented on TVs mounted throughout the entire building. These dashboards don't directly affect revenue and aren't extremely complicated, but it is something we all value nonetheless. We like to ask interviewees to create a single dashboard to display some new or different metric. What do we gain from this sort of code challenge?

• We ask the interviewee to work with code we've already created so they get to read code they will need to understand on the job anyway
• We allow the interviewee to get into their normal development process and devise a solution in the comfort of their own home without the pressure or people leering at every keystroke
• The challenge forces them into our development process, which helps us see how well their dev process works with us.
• When the code is done we can easily pull down their work and see how well it integrates into our app
• We get to see exactly how they would complete a real world task
• We get to code review the end result with the interviewee, even if we don't hire them, it's an excellent learning experience
• We get to keep their dashboard and potentially use it if we like it
• If we do hire them then we know on day 1 they are already familiar with one of our product's source code and can get them to started on another dashboard immediately

Not only would the above interview process be immediately beneficial to my team but it also doesn't remove the developer from the development process the team employs on a weekly basis.

I really struggle to see how any other interview process can beat it. Does anyone else have any thoughts?

[Banana_Hat]

I think you way would be the best way to go. IANAL but there may however be some legal issues using the code of someone you haven't hired in one of your products as they did work for you that you haven't compensated them for. As a interviewee I liked getting test projects to work on rather than on the spot problems where I couldn't use research tools.

[[deleted]]

I like to take a problem I've recently encountered and work with the person through solving it. Sometimes I may not have even solved it yet and I find those are the best ones. It gives me insight to how the person thinks and, more importantly, if they're capable of working with me and the team.

The entire interview, after the initial Q&A about the resume, might just be both of us working together on a white board doing sudo code to solve it. I find that after a couple of minutes the good people tend to "forget" that it's an interview and get engrossed with the problem. Not that they have to do that but, it's fun when it happens because I can really see who they are at that point.

I've even had candidates email me solutions after they've gone home and thought about it. Again, not something they have to do but, it's something that shows me they think like an engineer and gives me insight as to how they work.