Major Internet Companies: Are there public statistics on the time it takes engineers to climb corporate job ladders?

In nearly 20 years of technology industry work I do not recall coming across statistics of this kind. If I did I would examine it very closely to determine it's true value. First there would need to be years and years of data across a spectrum of companies, countries and industries (as there's some sort of programmable/programmed technology in nearly every single one of them). Second, there would need to be data points on the work these engineers performed to help segment them out. Some examples might be: languages used; PHP, Perl, Java, C#, C++, VB, etc. era of the work being done (there would need to be some way to adjust for the available languages, operating systems, hardware, etc. available for use) size of development team(s) size, length/duration and scope of projects (number of team members, etc) size of company stage of company (new, growth, maintenance, decline) company performance (loss, burn, profit and the depth of each of those financial states) role of IT/IS developer within the organization; r&d, operational support, product development, consultative service arm, etc. And the permutations and combination of needed data points could be exponentially increased for one reason or another that I'm not thinking of at the moment. But, in the end I am not convinced that the information would yield an answer to the question. Or at least not a clear one. I do not believe there is a single right answer to the question of how long it takes to climb the ladder (assuming one is available and the company in question isn't relatively flat). I can provide some insight on what - in my experience - makes for success and progression for software engineers (if they want it - some are happy to keep right on doing what they're doing) in a variety of industries: Subject matter expertise / domain knowledge - understand the development environment; the technology, business and business function. It helps avoid the creation of inflexible solutions that serve a single specific need versus providing a flexible framework that leaves room for change. (e.g. Don't build in a vacuum.) Ownership - own the project to the end; don't just code and go. Many developers finish and run to what they perceive as the next big, cool thing when they might have already built it. Weigh options before running and stick around if it makes sense. Business Partnership - work with the business, not for them. Ensure the solution created fulfill the needs of the executives and end-users inside and outside of the technology group through meaningful collaboration. Know Strengths & Weaknesses/Earn Peer Respect - no developer knows everything.  Recognize shortcomings and gaps in knowledge. Know what you're great at, what your good at and when to say you need help. Seek to partner with others who fill those gaps. Respect their opinions when you disagree with them. Work to understand why they hold those opinions. Don't bulldozer. Solution/Approach Acceptance - whether we like it or not (and as developers many times we don't) there is always more than one way to solve for a requirement. Multiple design models and programming paradigms are available along with dozens of languages, platforms and tools to support them. Don't discount one over the other before doing your homework. Educate yourself. Stay up to date. If you truly believe you've found the best way ensure that you can back it up with facts and ROI - short and long term. Don't Discount - Do not write off someone if their area of technological expertise is  unknown to you or seems antiquated/outdated. I've met more than one  AS400 expert spending their free time building mobile apps for iOS or  developing frameworks using Perl, Ruby or another tool of choice. Some developers are great at reading code, testing and debugging. Some are great at MVC. Some are great at Java, Perl, PHP or some other language. Some are great at databases. Some are great at design and planning. And if you're given a team - figure out how to make them work best for you, your project and the business. This is my take. And lastly I recommend starting the entire process by working hard and smart, listening carefully, speaking thoughtfully and respectfully, being reliable and accountable, staying determined, constantly learning and staying on the mission to deliver real value.

You got already a couple of very good answers. Let me go in a different direction: Why you will not find this information at all. Companies tend to hide this information, if they have. The reason: Making public it would drive to a couple of misunderstandings: - "I will get my next promotion after X years": You need to win it, not to wait for it. - "I didn't got a promotion during the last X years. I have no value anymore in this place": May be you reached the maximum value for the company, or you don't match some of the criteria to have a promotion. There's a huge problem to answer your questions: - There are few software companies big enough to have that many employees to have numbers that are statistically significant. - As companies have different criteria sets to decide about a promotion, their numbers are not comparable. - Criteria differences apply as well to what do you understand for "a top-x% engineer". -  No company is interested to reveal this. Recruiting and career planning criteria are part of almost core business information.