While I have had a few great individual colleagues over the years, I've never worked with a great overall team or engineering department.<p>If you have successfully found a great workplace for you as an engineer, how did you do it?<p>For me, "great" means a team that consistently values quality, puts reasonable effort into application design and maintenance, and makes thoughtful decisions related to project goals and end-users.<p>I'm open-minded about specific technology choices. I do not expect people to work overtime, or to have exceptional passion for their jobs. I'm not demanding elite talent. Just that everyone is competent and makes an honest effort.<p>Have you used any concrete techniques to identify teams like that?
Teams like that are built and grown, not found according to some criteria. You’re asking about personalities and team dynamics, and company culture, which vary according to circumstances and over time.<p>Companies tend to optimize for profit, not for the comfort of programmers.
> For me, "great" means a team that consistently values quality, puts reasonable effort into application design and maintenance, and makes thoughtful decisions related to project goals and end-users.<p>My 2 cents...<p>I don't think it's about teams. IMO it's about company KPIs. Most industries value speed over everything else for a reason: survival. Nearly all companies use KPIs, take a look at the KPIs and you'll be able to spot which companies value quality over speed and vice-versa.<p>The values you're looking for can be found in specific industries that cannot afford low quality. I'm thinking Aerospace, Health, Military etc. Keep in mind that on the flip-side these industries are very slow on "shiny new tech" adoption, for obvious reasons. You might not enjoy working with cobol :^)<p>Another good fit could be software companies, especially in the security space like 1Password for example (no affiliation). By "software companies" I mean companies who's product <i>is</i> software and not companies that are using software as <i>means</i> to an <i>end</i>. The first group has much stronger incentives in delivering reliable software.<p>Quality software can be found in many open source projects. The fact that the code is public increases the level scrutiny. HAProxy, SQLite, the Linux kernel and PostgreSQL come to mind as well known high quality open source projects.
> For me, "great" means...<p>You've done the first step - defining what you want. But your definition is still quite objective. What attributes of a team can be observed when they "value quality". What is a "reasonable" effort, and how can you see whether or not they do it.<p>Figure out some visible outcomes from those traits, and look for them during the interview process. Ask about those topics in the interview. There is so much talk on HN about what is wrong with interviews, but when they ask you if you have questions that is the part that is right - it is your opportunity to dig into these traits that make a team great, and determine whether or not any given team matches your desires.<p>I recommend people break it down even farther - before you step into an interview, break those desires down in wants vs. needs. If you have a need they do not meet then the team is not for you. If you have wants they do not meet, you need to walk in accepting that it isn't perfect and either be compensated for those imperfections, or have enough authority and/or autonomy to try to invoke changes in the organization to improve it.
If you don't know about this (<a href="https://501manifesto.dev" rel="nofollow">https://501manifesto.dev</a>) you will like it.<p>Looking up "9 to 5 developer" or 501 developer" on Google/hn to find blog posts and tweets, then moving ahead to connect with these people or look for places they recommend working at seems like a good idea.<p>On another note: word of mouth and networking. I know it kinda sucks, information in people's minds is not indexable, but it is still a source of high quality information.
I think you can do some things. Honesty at an interview might help - and by honesty I mean actually letting them know your weaknesses and dislikes - to get rejected for the wrong jobs increasing he chance of ending up at a good one. If you can kick ass at the technical tests the “I got fired because I refused to do 60h weeks” might be perfectly fine.<p>Also it is mostly luck and teams can change in the 12 months it takes to even begin to understand the dynamics or get productive with code. It’s a hard human problem!
Yesterday I found this list: <a href="https://github.com/poteto/hiring-without-whiteboards" rel="nofollow">https://github.com/poteto/hiring-without-whiteboards</a><p>Although not exactly what you are asking, this interview behavior could be a reflection of internal values.