
Ask HN: How to find high quality workplaces for developers? - turboat
While I have had a few great individual colleagues over the years, I&#x27;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, &quot;great&quot; 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&#x27;m open-minded about specific technology choices. I do not expect people to work overtime, or to have exceptional passion for their jobs. I&#x27;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?
======
gregjor
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.

Companies tend to optimize for profit, not for the comfort of programmers.

~~~
turboat
Do you believe then that it's impossible to identify a good situation until
you take the job? There are no reliable job search tactics to select for
better settings?

I would say, for example, that a job interview helps provide a vibe for the
current situation at a company. But it's not a perfect signal, and as an
individual I can't go on that many interviews. Hence looking for other
approaches people have tried.

> Companies tend to optimize for profit, not for the comfort of programmers.

I believe that's a separate issue from my question. Seeking profit doesn't
force a company to hire incompetent or apathetic programmers. If anything it
wastes money on salaries that don't deliver as many new product features to
sell, or as many improvements that will increase customer retention.

~~~
gregjor
Great teams should be visible because they produce great products or services,
and because they have their pick of top people because word gets around.

Big companies will have multiple teams, maybe hundreds at companies like
Google and Apple. Some of those may be great to work with, others
dysfunctional. Adding more people can push the “greatness” in any direction
because interpersonal factors are first-order drivers of team productivity and
job satisfaction.

So it’s not impossible to identify candidate teams but I think it is
impossible to predict how you might fit and what you can get out of it.

I think word of mouth through referrals and contacts works best. Some
companies have reputations for building good teams, others are known for
dysfunction, but those generalization don’t necessarily predict what an
individual will experience. Even Google has unhappy employees.

------
atmosx
> 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.

My 2 cents...

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.

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 :^)

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 _is_ software and not companies that are using
software as _means_ to an _end_. The first group has much stronger incentives
in delivering reliable software.

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.

------
codingdave
> For me, "great" means...

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.

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.

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.

------
O_H_E
If you don't know about this
([https://501manifesto.dev](https://501manifesto.dev)) you will like it.

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.

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.

------
quickthrower2
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.

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!

------
O_H_E
Yesterday I found this list: [https://github.com/poteto/hiring-without-
whiteboards](https://github.com/poteto/hiring-without-whiteboards)

Although not exactly what you are asking, this interview behavior could be a
reflection of internal values.

~~~
scott31
It is the opposite of what the OP is looking for. You can't have a high
quality workplace with people who fail at basic algorithm questions

~~~
non-entity
That's a pretty big jump to say anyone who works at a company that doesn't
whiteboard "fails at basic algorithm questions"

------
probinso
Small research companies or small contracting firms

