I had to shorten the title, but some of the information you say is missing is actually covered on the question.
Anyway, I just thought of adding this question today because I actually was asked a variant of this in an interview (no mention about code style docs), and the interviewer was not happy with my answer which was something like “Whatever style decision is important should be covered in the style guide. If you don’t have a style guide, then I’d assume that this is not really important for the team, and I rather focus my review on things that really matter. Is the code testable? Is it maintainable? Is the code being introduced completely different from what we have before or are we consistent with our inconsistencies? All in all, I’d rather spend time working on new features and shipping than arguing over style preferences.”
Your answer doesn’t give confidence that you care about how the code looks. Could imply that you’re sloppy. Some people are very opiniated about style and think it matters a lot. They would be unhappy with people who say it doesn’t really matter.
They’d likely welcome fixes or comments on style. Other people would be very angry if you held up their PR with such trivialities.
I had strong style preferences when I was younger, but after working on so many projects with different styles I really don’t care anymore about any particular style. I just make sure to seamlessly match the style of the code around it.
I work with Python. Usage of formatting tools (black, ruff) are widely adopted. Part of its Zen is “there should be one way to do it”, most of its idioms are widely adopted and if you ask anyone about an example of a PEP, they will respond with “8”.
That is to say, “how python code should look” is somewhat of a solved problem. Any occasional differences that might show up in a codebase are likely to be minor that are simply not worth arguing for.
I think that the interviewer was mostly looking for an answer where I could talk about how I deal with conflict. But to be honest if that was the case I would be either more straightforward about the question, or I would try a different scenario with something that might happen more frequently.
I had to shorten the title, but some of the information you say is missing is actually covered on the question.
Anyway, I just thought of adding this question today because I actually was asked a variant of this in an interview (no mention about code style docs), and the interviewer was not happy with my answer which was something like “Whatever style decision is important should be covered in the style guide. If you don’t have a style guide, then I’d assume that this is not really important for the team, and I rather focus my review on things that really matter. Is the code testable? Is it maintainable? Is the code being introduced completely different from what we have before or are we consistent with our inconsistencies? All in all, I’d rather spend time working on new features and shipping than arguing over style preferences.”
Your answer doesn’t give confidence that you care about how the code looks. Could imply that you’re sloppy. Some people are very opiniated about style and think it matters a lot. They would be unhappy with people who say it doesn’t really matter.
They’d likely welcome fixes or comments on style. Other people would be very angry if you held up their PR with such trivialities.
I had strong style preferences when I was younger, but after working on so many projects with different styles I really don’t care anymore about any particular style. I just make sure to seamlessly match the style of the code around it.
I work with Python. Usage of formatting tools (black, ruff) are widely adopted. Part of its Zen is “there should be one way to do it”, most of its idioms are widely adopted and if you ask anyone about an example of a PEP, they will respond with “8”.
That is to say, “how python code should look” is somewhat of a solved problem. Any occasional differences that might show up in a codebase are likely to be minor that are simply not worth arguing for.
I think that the interviewer was mostly looking for an answer where I could talk about how I deal with conflict. But to be honest if that was the case I would be either more straightforward about the question, or I would try a different scenario with something that might happen more frequently.
You’re hired!
Great! When can I start?