Hey, one of the authors here. While there is some prior art we (me and gravyboat, the other author) felt that this is an improvement upon what's out there, especially the part where it's collaborative with the community as a GitHub repo. With HN hosting the monthly "Who is hiring" threads we'd like to see more companies be more open about these things and realize that quality of life for people in the technical line of work isn't just about what perks the company provides, but also about how painless it is to be an individual contributor.
It's a cliche that we all want to change the world, but there's a bit of truth in it. If as an employee I have to fight against your ancient development environment and painful deployment model to get my code changes into production while being chained to a desk, I probably don't want to work at your company.
If I would have known to have asked these questions I might not have had some of the jobs I've held. My hope is that by sharing some of that experience the junior people can avoid trial by fire in less than optimal work environments by asking the right questions, and that table stakes for companies to attract talent will be to have great answers to these questions.
To make it clear, these are questions for the interviewee to ask the interviewer.
They are also designed for an candidate in a job working with many other developers, and deploying primarily web-based software in an IT-heavy environment.
If you are hired as the sole software developer for a non-programming group, then most of the questions make no sense. For example, I mostly work with chemical research groups, where there is no mandatory code review as I am the only developer, and where the deployment is to install to /usr/local/bin .
Also, '100% test coverage' is a meaningless goal. It's trivial to force 100% coverage, and does that mean line or branch coverage? Coverage testing is a way to find where you need more test, but it mustn't be the end goal.
Hey, thanks for taking a look. This is spot on. Most of the technical questions are aimed at startups / software shops that are hiring for growth / large enterprise companies with tons of IT. They become less relevant if you're the sole IT guy in a non-software shop. There still are a number of questions we feel are relevant to any position that are important to ask such as health care provider, retirement fund, etc. If you have any suggestions for questions to add we'd love to hear them. The removal of questions (ex. the test coverage) we put more consideration into. I think questions like that are valuable to the extent other people find it valuable. Certainly if no one thinks test coverage is a good question to ask then we'd remove it. Thanks for the feedback.
3 comments
[ 3.3 ms ] story [ 17.3 ms ] threadIt's a cliche that we all want to change the world, but there's a bit of truth in it. If as an employee I have to fight against your ancient development environment and painful deployment model to get my code changes into production while being chained to a desk, I probably don't want to work at your company.
If I would have known to have asked these questions I might not have had some of the jobs I've held. My hope is that by sharing some of that experience the junior people can avoid trial by fire in less than optimal work environments by asking the right questions, and that table stakes for companies to attract talent will be to have great answers to these questions.
They are also designed for an candidate in a job working with many other developers, and deploying primarily web-based software in an IT-heavy environment.
If you are hired as the sole software developer for a non-programming group, then most of the questions make no sense. For example, I mostly work with chemical research groups, where there is no mandatory code review as I am the only developer, and where the deployment is to install to /usr/local/bin .
Also, '100% test coverage' is a meaningless goal. It's trivial to force 100% coverage, and does that mean line or branch coverage? Coverage testing is a way to find where you need more test, but it mustn't be the end goal.