What's Your Engineering Culture?

by Jeff Hui

When evaluating companies, its utmostly important to learn about the engineering culture. Culture for a company is simular to scope for code – culture provides a context for getting work done.

Companies advertise their culture, but note that each company has a different culture. There's plenty of articles about culture, so I won't bother covering that. Just remember they aren't necessarily the same. Companies tend not to be explicit about making sure their process matches what you expect. Be suspicious for a company that can't explain it's culture because that just means they're not activitely trying to cultivate one. And that means it's implicitly defined by the leaders of the company. Even if they choose not to define it.

Basics

There are some basics that should be generally applicable to most companies:

  • Deployment frequency. There should be a process for deployments that in less than a month. And that process should be hassle-free. And by hassle-free, it usually means it's an automated script to do the entire deploy.
  • Feedback loops for code. How does code that gets written become vetted to run in production? There should be multiple points that verify the code: some automated (eg - CI) and some human-review (eg - code review).
  • Prioritization. How do new features get prioritized for engineering? How is the engineering's work communicated to the rest of the organization? Is the business promised upfront before engineering is told about the feature. Or is engineering involved in helping how the business prioritizes work?

While it's possible for some companies to not do one of the ones listed, they should have good reasons to why not. Otherwise look suspiciously.

Sustainability

Hopefully the company has the basics down. Next are things you'll usually have to ask about. Larger companies more likely have these things, but it's worth noting that these are important for companies larger than a handful of people:

  • Are there regular one-on-ones? No doubt large companies have this. That's because one-on-one is a safer way for some employees to voice concerns. But a scheduled one-on-one provides a useful way to raise concerns privately without having to require employees the initiate the effort.
  • Are there regular retrospectives? Not just the one for that outage that occurred yesterday, but a regular one. It's similar to a one-on-one, but for teams. They provide ways for a team to raise concerns. The scheduled time reinfornces that this kind of feedback loop is valued.
  • Do employees work long hours? It's not necessarily bad when employees work overtime. It could be a sign of engineers invested in the product or a specific time-sensitive deadline. But a common occurrence of late nights isn't healthy. Longer hours sacrifices the longer-term sustainability. Companies should make it clear why employees work longer hours for new employees if that isn't expected of them. Otherwise the social pressure can drive the same effect.

These are indications that the company has set some roots down with an eye on the long-term future. Tiny startups don't have this because they're looking for the power-users of their product.

Growth

Finally, companies can go above an beyond if they are willing in invest in your continual refinement of your craft. Few companies do this. To be fair, a lot of it does depend on the person. It's difficult for an organization to offer this well.

  • Does the company provide resources to attend/speak at conferences? It's a useful way to network with the community at large. Resources could be monetary or training.
  • Does the company offer time to do alternative work from the day-to-day? An easy way is to offer some time free for personal learning, contributing to open source, or working on talks. Think like Google 20% or Facebook's Hackweek.
  • Does the company provide a process for evaluating and introducing new technologies? Besides just throwing employees into the deep-end, there should be ways for to help explore and train with new technologies.
  • How does the company train junior developers? Unfortunately, there isn't an obvious answer to this. But is important for the company's bus-factor. Teaching a useful way to solidify knowledge for senior developers. Sadly not every developer will like doing this.

This is by no means conclusive, but this is a useful checklist to start with. How does your company compare?