* Professional satisfaction depends more on the customer you work for than on the company itself - nice customers or greenfield projects are usually nice, brownfield projects and bad customers make for a less pleasant experience - and chances are high you'll get onto one of these - bad customers are more likely to not be able to manage software development internally (but that's a given for any dev services company)
* Periodical perf evals are crappy - but again, in all the years since I started working as a programmer I haven't experienced one single SW dev company where they aren't - the problem isn't the company type or size, it's that managers and HR typically don't understand what developers do, so they can't come up with a reasonable way to evaluate it
* You're allowed to organize internal training activities (in fact, the company expects and encourages you to participate or initiate various initiatives, such as presentations at local dev groups, research ideas, internal trainings etc.), as long as they don't impact project work negatively, but there's not much investment in buying external training; the company does buy books, though, and gets involved with local professional communities
* Slightly too many meetings for my taste - but this also depends on the customer
* Mobility across projects isn't that easy (to be expected: the less gratifying projects would run out of people otherwise)
