this post was submitted on 09 Jan 2025
25 points (96.3% liked)
Experienced Devs
4032 readers
6 users here now
A community for discussion amongst professional software developers.
Posts should be relevant to those well into their careers.
For those looking to break into the industry, are hustling for their first job, or have just started their career and are looking for advice, check out:
- Logo base by Delapouite under CC BY 3.0 with modifications to add a gradient
founded 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
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?