How can I identify companies that have good work cultures where code doesn't have to be refactored all the time?
How can I prevent myself from putting myself in a job where I have to recode an entire code base after a long amount of time on a product?
More specifically, how do I identify good teams that have working styles where you aren't having to refactor an entire codebase and have a frustrating work environment? In the past, I've heard that at companies like Netflix that people can just code in whatever language they want, then when folks sometimes regroup/resync with a larger product team, one team in a particular language will win, leading to large parts of other specific devs on the team to hate it because they have to refactor their code.
How does one come up with certain criteria (and follow through with it) as they interview for jobs and specific companies about working styles on preferences of code base, tools, frameworks?
What other core principles and criteria folks consider as they're interviewing other people (not just the company interviewing for a role) that they should consider as a part of the dev culture, structure when it comes to these types of things so I don't make the same type of mistake?
And yes, I know people refactor code bases (ex. legacy projects, cleaning out whatever tech debt folks have), which people tend to hate because it's a lot of work--and that it's still bound to happen and unavoidable, but how can we eliminate cultures we dislike that are refactoring code bases as a result of a dysfunctional tech team? I want to avoid having terrible experiences at a future company I work (similar to an hackathon experience I had recently working on a small MVP can be frustrating when folks are not aligned / on the same page for things that might take to long to complete or have to refactor completely if they are not communicating well or upfront from the beginning).
Discussion
(3 comments)- 2
4 months agoTech Lead @ Robinhood, Meta, Course HeroInteresting, I didn't realize that Netflix did that. I imagine that doesn't apply to every team though, and it probably happens rarely. Migrations are extremely expensive. Personally, I would recommend that 95%+ of engineers take a Netflix offer if they were to get one.
In terms of figuring out this exact signal, it's pretty tricky as it's kind of specific. I don't think there's some subtle way to do it. You will probably just have to ask upfront about the dynamics of their codebase, its technical debt, and any refactoring/migration efforts they've done in the past + are planning for the future.
If you want to play it really safe though, join a startup. Startups simply don't have the time to mess around with painful, massive refactors. They need to keep shipping great features to the end-user or die. That's not the case for FAANG.
Here's a good thread about finding other red flags in interviews: "How possible is it to spot red flags about toxic culture during the interview?"
- 14 months agoEng @ Taro
Hmmm, you could be very blatant about it and ask about how the codebase has evolved over time. Many companies significantly transform their code bases as a result of poor preexisting coding patterns or have to switch frameworks/programming languages for performance gains, so I don't think it would be that offensive to the interviewer if you asked this question. The answer could provide some valuable insights about how engineering leaders thought about the future when making the decision.
If they do hint at a refactor, you can ask about what the initial goals were with the refactor and whether they ended up achieving those goals. The answers will usually give you a good sign about whether a refactor was justified or not.
- 0
4 months agoSenior Software Engineer [OP]Taro CommunityThanks this is really helpful, constructive and actionable feedback. I appreciate your comment.
