Pros: TTD promotes an amazing culture of ownership, trust, and responsibility. Getting things done is a key aspect. As an engineer, you work on some of the hardest scale problems in software.

Cons: None that I can think of!

Pros: Lots of autonomy and good benefits. Often interesting work. Emphasis on modernizing the developer experience, even if a bit late.

Cons: Distributed teams cause a lack of in-person culture. The Agile lead role (half manager, half individual contributor) causes a lack of leadership and mentorship for engineers due to mixed responsibilities and expectations.

Pros: Great benefits (health insurance, mobile phone expenses, lunch in the office 3 days a week, drinks, Palooza - a massive 1-week long conference with parties and everything). Very stable company, secure job. Really good compensation, can't highlight that enough. Chance to work on a super high-loaded system. Great people with years and (sometimes) decades of experience; a lot of people work 5+ years at the company. Very good work-life balance.

Cons: Technically, it's a very rigid system, an old monolith with right-for-the-time decisions and very reluctant for any changes. A lot of red tape; you'll need numerous approvals for anything to get done (even code changes require code reviewers, SMEs' approvals, manager approval, and that does not even count for the release process, which is another level). A lot of re-orgs and re-structures, surprising for a company of this size. Most of the tech stack is quite rigid; most of the time it is .NET 4, MSSQL, and React, with not much variation. Introducing anything new is next to impossible; it is seen as unnecessary, dangerous, and always starts holy wars – very emotional and overheated discussions by very senior people (to a point of the CTO getting involved). This is adtech, so some people might find it unappealing. Processes borrow a lot of words from Agile ("agile teams", "scrum", "story points", "sprint", etc.), but in fact, it is just a waterfall which has nothing to do with Agile. Story points are abused (like X story points are substituted for a week of work; each team member could be assessed based on how many story points they have delivered in a given timeframe; no retros, planning sessions, or sprint reviews; people working in silos rather than as a team, etc.). Some management is not really managing people – not conducting 1:1s (or their agenda consists exclusively of work planning/task discussions), slacking on growth/performance reviews. Working in silos; that is, very little collaboration. People often work on a task (the size of a feature) alone, start to finish (design through release), which is good for honing responsibility, autonomy, and all that jazz, but it has its drawbacks. The monolith – the codebase is **enormous**. The setup requires an entire machine; running tests locally is often impossible.