Datadog reviews

Code quality is quite low. Many, if not most systems at Datadog were built by one-man "teams" of engineers, often as hack-day side-projects, rapidly launched to production well before they were ready. Applications are almost never built in a "normal" way and there are whole applications without a single test. As a consequence systems break frequently and no one even knows how they're supposed to work. As a competent developer, you'll probably notice this in your first two weeks, but you'll also soon discover that there are many sacred cows at Datadog, and despite their obvious deficiencies, the design of these systems is largely non-negotiable. Most of your work will consist of a constant barrage of surprisingly crude devops changes just to keep the thing running. For many teams, most work is unplanned and very stressful because it's done in response to outages. (we have 3 or 4 outages every day, so half your day will be spent working on "urgent" problems) Backend engineers also participate in the on-call rotation, which ends up being once every 4-6 weeks and lasts for a week at a time. You will be responsible for 90% of the systems, even though you know nothing about them, and because everything is mostly broken, you will be paged every hour. Also you will get to experience the joys of working with an international team, where because almost every change at Datadog results in an outage, the developers in France will consistently wake you up at 4am every morning. The company has grown rapidly, but management has not kept pace. Team leads have no experience in leadership, do no planning and make irrational, heavy-handed decisions. Concerns are not taken seriously and you'll be treated like a junior engineer regardless of your prior experience.

You're treated well as long as you're shipping fast. We used to have a culture of soft deadlines, but that's disappearing. The problem is, we're not ready for it to disappear, because for the last several years we've had a culture of not caring very much about technical debt, and now it's coming back to bite us with outages happening left and right, new features being blocked by old undocumented code being impossible to work with, and different teams coming up with multiple bespoke solutions to the same problem because nobody has breathing room to figure out how to work together. Managers will discourage you from fixing problems before a customer complains. We tried to solve this by experimenting with 20% unstructured time, but after about a month or two managers started discouraging people from doing things that weren't directly related to shipping their current project. Unrelated to the growth problems, but here's another issue. When people on my team made mistakes, my manager would use this tactic of saying that he was concerned with "what other people on the team think about you." At one point he seemed to make up that somebody had complained about one of their fellow team members, when in fact we're all pretty sure no one had. I'm not sure if other managers use these kinds of manipulative tactics, but there's at least one. I'm afraid to go to HR about it, since it's gross but not strictly illegal. It's against company policy to retaliate for that, but performance standards are so loose I feel like they'd have no problem coming up with an excuse. Ultimately lurking under the bright and sunny surface of this company is a culture of dissatisfaction at best and paranoia at worst. Work here if you want to get paid well, not if you want to feel good about the code you write. What upsets me the most is that I don't even think these problems are going to affect the company's bottom line, because at the end of the day we're still better than all of our competitors and have a pretty untouchable revenue stream.