Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Here's the best approach I've seen yet to the take home interview (and interviewing software engineering candidates in general).

Here's a git repo, a problem statement and a slack channel to ask questions. You can use any tools you like and spend as much time as you like on the project for the next week.

----

Employer's perspective: You get to see some code, see how they approach a problem, see how they use their tools, and get a sense for what it's like to work with them.

Candidates's Perspective: You get to use the tools you're already comfortable with, you can set your own pace, and you get a sense of what it's like to work with the team.



I really like the idea of adding a Slack channel to the problem statement. I always have questions, and channeling them through a recruiter via email is a pain.

A lot of take home problems are very unrealistic, so it's difficult to make the trade-offs that you'd normally make when trying to ship software. Being able to ask someone on the team what their intentions are would be super helpful.

My pet peeve is front-end tests that ask you to write maintainable code, but you're not allowed to use any libraries. So instead you have to create your own tiny MVC/templating/helper libraries just for the project - but obviously they won't be as good as something you've spent more than 4 hours on.


Unless the task was to write an MVC or helper library I'd be concerned the candidate wasn't using a library of some sort. It's really interesting getting a sense of where someone spent their time on a project - asking the candidate that question has been the turning point in the discussion because it a.) tells you if they actually wrote the code and b.) gives you a closeup view on how the person thinks




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: