Cloudera

It's easy to find ways to make an impact as an engineer – by working on hard engineering problems like distributed systems, infrastructure, just writing high-quality code, or working on customer problems.

My experience is that people who make a big impact are rewarded. I've had lots of individual growth while here.

Emphasis on code quality on many teams. I've learned a lot from working here, and I haven't shipped anything I wasn't proud of. The management, tech leads, and PMs I've worked with are on board with shipping things when they're ready instead of rushing to meet deadlines.

My team gets lots of day-to-day freedom about when and how to work, so long as you deliver.

My managers have been supportive of taking plenty of time off (more than I would be able to at almost any other US company). No pressure to work while on vacation or in off-hours.

People are generally nice. I don't have to deal with any jerks.

I like working on open-source projects.

Development infrastructure is challenging. Each open-source project has its own build and test setup, optimized for its own needs, which leads to a lot of duplication and challenges with integration.

The infrastructure is continually improving; the difference between when I started and now is dramatic.

Previously, there was a tendency to make too many bets and lose some focus, but there has been a serious effort to rein this in.

Customers are often ahead of the curve on how hard they push the product. This leads to interesting scaling and performance challenges, but I'd rather feel like we were ahead of customer needs.

Individual engineers put a lot of effort into writing quality code and tests (and I don't think this is always fully recognized), but it would be good to have more people focused on breaking the software to take quality to the next level.

At the individual contributor level, responsibilities and processes are often not spelled out. This is usually not a problem for self-starters, especially if you build out a network of contacts in different departments, but sometimes it leads to inefficiencies and uncertainty.

Keep investing in testing and infrastructure.

Articulate some longer-term, high-level technical goals engineers can design towards, beyond immediate OKRs. For example, do we want to scale the number of clusters or the size of clusters?