A developer's guide to interviewing
1. How do you know what to work on each day?
The purpose of this question is to identify dysfunction. I want to get answers from 2 or 3 engineers. If company leadership says they follow a certain process, but the engineers don't talk about the process, that's a sign of dysfunction. If you get different answers from different engineers, that's another sign of dysfunction.
In a high quality team, I get consistent answers to this question. Every developer knows the process, and the process is light weight enough to be supportive of the engineers rather than oppressive to them.
Example of a good answer (there are many others): "We do N-week sprints wherein each engineer commits to a set of features and bug fixes to deliver. Each day we report progress on our commitments to each other. We have an amazing product manager who interfaces with customers to help us prioritize features and bug fixes."
Example of a bad answer (there are many others): "I come into the office and see what fires are burning. Most days, I get interrupted with an emergency."
Notice I don't mention "Scrum" or any other specific methodology. I'm much less interested in the labels the company uses for their engineering process than the actual day-to-day "how stuff gets done".
2. What do you use for revision control?
Good tooling is a strong indicator of a good team. If a team is using an ancient revision control system, they are probably using a bunch of other outdated tools. Furthermore, they probably don't value the efficiency gains that can be achieved by investing in good tooling.
Read full article from A developer's guide to interviewing
No comments:
Post a Comment