Are there multiple tech leads per one people manager?
Correct. My manager has 4 TLs reporting to him. My TL has a team of 7 not including himself, which is actually on the higher extreme. My previous TL had a team of 4 which is more typical. For career/HR-y management aspects I interact 1:1 with my manager for those, as does my TL. TLs will naturally offer career guidance/mentorship informally by virtue of technical seniority (where applicable) as well as feedback to managers and promo committees that will feed into conversations regarding the technical readiness for promotion for someone on their team.
I have a reservation with tech leads who stop writing code as in my experience they'll stagnate (the time frame is maybe 2,3 years).
TLs at Google stay quite technical (and mine certainly does) and write code as a routine matter of course.
I am a manager, who also serves as a tech lead, for the record I'm at Microsoft.
Ex-MSFTee and Google SDE here - At Microsoft my manager served both as a manager in a traditional sense, as well as a tech lead. At Google, my manager and tech lead (TL) have always been distinct roles filled by different people. My manager, though an experienced dev himself, leaves all the various aspects of daily technical leadership to his TLs and focuses on just people and project management. From a line management perspective, both my TL and I report to the same manager.
My experience is that this organization allows managers to manageably have a lot more DRs than my managers at MSFT could. Another benefit is that the TL role is a natural fit for people who do want to step into a clear role that allows them to increase their impact and leadership as senior engineers but are not interested in traditional people/career management work.
Thanks! Yeah, that Steve Yegge post definitely came in handy when I was laying out a map of the bases I wanted to hit in my prep for GOOG and FB interviews
Preparation really is the key. There may be folks out there that can ace technical interviews at Google or Facebook on any random day without preparation but in my experience, and I know many smart engineers, those people are by far the exception not the rule. As the below comment says, just like the SAT, prepare. Really.
Over the years, I have seen a particular scenario play itself over several times - the scenario is a very smart and high quality engineer decides to take an interview with Google, FB, MSFT, Amazon etc etc on a whim without preparation, have a pretty bad day and remember rudely that the interview experience is pretty different from their day to day job, go back home, take a month or so to prepare diligently, and then take interviews again and have excellent results.
My attitude reinforced over the years is that my edge going into interviews over other candidates is my ability to prepare. I take it seriously and don't fuck around. The return on investment on that month or two of preparation has been very worthwhile and each time you invest in it makes the next time easier.
I have worked at Microsoft, Google and Facebook as a software engineer, going through the full interview process every time.
The thing to realize is that being good at technical interviews (as done by the above companies) is a skill unto itself but it is a skill an intelligent person with a comp sci background has the ability to get significantly good at after a 1 to 2 months of disciplined preparation. - I went to a top ranked school myself and had a comp sci degree but was very intimidated by technical interviews until I realized that this was no different than all the other other intellectual hurdles/gauntlets I had successfully navigated up to that point by giving myself time to thoroughly prepare.
Get "Elements of Programming Interviews" and give yourself 2 months to prepare. Start to with "1-month" plan in the book spending at least an hour a day at the very minimum. (I have worked through both Elements of Programming Interviews and Cracking the Coding Interview in their entirety and while both are good, in my experience Elements of Programming Interviews was clearly the better preparation in terms of technical depth, breadth of exposure to the kinds of questions I faced in the full-day interviews, and succinctness of coding solutions)
Get dry-erase paper/notebook or a white-board and work through the problems by hand including the coding (important!). For the first week or two give yourself an honest focused couple of hours to wrestle with a problem before looking at the solution. it is not enough to settle for "I think I know how to solve this" - Actually code up the solution by hand and step through it with some simple cases. This is important and it allows you to develop confidence in your ability to think methodically through a problem as well as giving you an opportunity to develop mental heuristics for how to tackle and test unfamiliar problems. Developing confidence in your ability to think through interview-style problems is every bit as important as exposing yourself to interview-style problems. As you progress, you will be working towards being able to deconstruct a problem and be ready to start coding up a high confidence solution in 15 - 20 minutes.
"Talk to yourself" as you try to solve a problem to simulate explaining your thought process to someone as you go along.
When going through the solutions in the book, do not gloss over a detail you do not understand. Go online and find alternative explanations/references if you don't understand some detail of the solution provided.
After a few weeks of this kind of daily disciplined prep, you should start feeling pretty good and your confidence should start building nicely. Lots of interview questions are variants of each other and once you have enough breadth, you start quickly being able to key into the "type" of question and possible solution approaches almost as soon as you hear it.
Last thing is when you feel ready to start doing interviews, do not interview with your "top choice" first. If you can find someone that has done interviews to give you a mock interview, great! If not, schedule interviews whose outcome you are not as attached to (relatively speaking) first.