Pros
Engineering: The hiring mantra is "great, not good", and the company lives up to it. ALL of the engineers are top-notch - seriously. Furthermore, although the engineering dept has close to doubled every year for three or four years, they've managed to maintain a great culture - you can go to any developer, ask a question, and get a friendly response, a detailed answer, or (at the very least) information on who would be a better source. The code base is big, and it takes a while to learn - but the technologies are all mainstream open source (Java, Velocity, Postgres, etc.), and there are three or four monthly engineering brown-bag sessions to go over different aspects of the code, best practices, or open Q&As with the VP of engineering. There is an engineering meeting once a week to discuss riskier code designs - this is open to all engineers, and though the presenters are sometimes sent back to the drawing board, it's kept the code base reasonably clean. Projects are (very!) short, creating the opportunity to work on lots of different things, all the time. If you don't like your project this week, wait three days and you'll be on something else. You won't end up on an 18 month project that gets cancelled. Likewise, with projects this short, there aren't any deathmarches. There are sometimes long hours to make a launch, but things are generally very flexible. We all use laptops, and no one bats an eye if you have to work from home because of a doctor's appointment, waiting for a cable guy, car in the garage, etc. On snow days, there's an unofficial custom of sending a "working from home" email in haiku format. The tools are generally very good - MacBook Pros, 30" monitors, your choice of IDE, etc. There've been some growing pains in getting people up to an adequate amount of memory (some people are still using older machines limited to 4Gb, new developers get 8Gb), devservers with enough resources to run bigger services, and machines to test Internet Explorer, but that's mostly been fixed. There is a commitment to streamline development, primarily in terms of equipment - there is no set project management methodology (Agile, SCRUM, etc.), as short projects and small teams (usually 1-2 people) generally don't require something formal. Processes are generally kept to a reasonable level. Product Marketing: This is where many of the complaints in the older reviews come from, and (being an engineer) I have less information about this. However, things seem to be generally better than last year, and on an overall upward trajectory. The people I interact with directly on projects (all below the director level) are fun to work with and highly competent. Again, I don't know much about the politics, but there have been some good hires, and there seems to be a lot less angst on that side of the building than last year. General: There are lots of nice things about working at TripAdvisor. As everyone says, there are a lot of small perks - three free lunches per week, the wall of snacks, free drinks, video games, flex time, shuttle to green line, etc. Also, the employees are trusted with a lot of information about the company - 3-4 times a year, there's an all-hands meeting where the CEO goes over the financials, discusses targets and results. It's nice working for a company that's bizarrely profitable. Last year was the best year in the company's history. People are nice. And finally, it's nice working on a product that people recognize and like.
Cons
It would have been easier to pan the engineering department in previous years, but most of the day-to-day problems have been addressed over the past six months. One thing to mention is that, because most of the projects are very short, there aren't many opportunities to work on big teams, on large features that fundamentally alter the site or change the architecture. They do exist - for instance, this year they're putting a lot of effort into Facebook-related features, last year they launched the new Flights product, and the year before they added vacation rentals - but these projects are much less frequent, and most of the time you'll be working on short projects. To some degree, this is a matter of taste - with lots of small projects, you get to touch lots of different areas, learn lots of new things, and there's remarkably little territoriality about code. On the other hand, you probably won't "own" a section of the code, or write a brand new subsystem from scratch. Also, with a ten year old codebase, there's some amount of cruft from previous versions. For example, there are still cleanup projects to convert XSL pages into Velocity, and not all of the services have been upgraded to a newer style. By its nature, this gets better asymptotically, but will never be completely fixed.
