Hacker News Reader

Comment by Matthias247 | Hacker News Reader

> One interviewer who had studied my work asked "How many staff report to you?" "None." He kept returning to this question. I got the feeling that he didn't actually believe it, and thought if he asked enough times I'd confess to having a team.

My experience with this in interview loops is that it's less about admiring a persons technical abilities, but more a checkbox question to determine whether a person fits into a certain role model that companies have set up. At most FAANGs, interviews will expect that you mention you are being the tech lead of a team (5-10 engineers) at a (L|E)6 role, even if one isn't a manager. At (L|E)7, it will be 50+ engineers. As a regular engineer, one would probably have an issue getting hired at a high seniority level without answering the question the right way. Things might be different for well-known personalities like Brendan.

View on HN

Had this experience - worked in a role where I was mostly a very senior IC but also managed a small team for strategic projects. Interviewed at FAANG and got convinced that corresponded to an L6 sort of role, definitely should have held out for L7 though.

Walk in the door to find that move of the L7s I've encountered have been leading 50 person teams (as manager or TL). Seems to range from more like 20-35 and, among ICs, there often not actually the only TL, just the most senior on the team.

My team has hundreds of people, but a core team of about ~20 does most of cool stuff. It’s kind of a unique role.

On interviews it sucks. The engineers assume I’m some jackass manager guy, and the manager guy thinks I’m in the weeds.

At the distinguished engineer level, you can get away with not being a tech lead. But ya, you'll have problems if you go from a very individual IC to a FAANG where they expect more leadership to have been demonstrated.

This is a problem in many FAANG like companies. They have no real technical track for "individual contributors"... all paths turn into management roles eventually. Sucks that when companies finally got on board with technical tracks that didn't require switching to management they just did it by making the senior technical spots management spots. So still no real technical tracks.

A tech lead role is different from a management role.

The TL is the person who the buck stops with on technical discussions. While part of the job is providing mentoring for junior engineers, they aren't directly responsible for performance management, headcount allocation, etc, in the same way that a people manager is, and people don't usually directly report to them in the org chart.

By definition, no large engineering effort is solitary. It makes sense for the more senior eng to be responsible for the decisions that will affect more people, and that requires talking to and understanding them. If people want the senior eng title, they need to be able to do that kind of work.

A large engineering org is almost always horizontal, whereas some narrow problems are unusually deep and/or important and therefore benefit from unusually skilled attention down to the micro level.

In some cases you want your three wizards supervising the architecture of 100 people working on 25 products… and sometimes you want them lovingly crafting every line of a framework or other core component that is going to mechanically influence all that work even more than design review ever could.

To me the main difference is whether I get to work with code or people. Technical tracks are for people who want to work on code, but TLs don't. Technical leads spend all their time working through design documents and in meetings. They are technical meetings and documents, but they are still not actually creating things. They are artists who have gone from making art to helping guide other artists. Definitely a valuable role in a company, but whether you call it management or not doesn't change the fact that they no longer get to make the art.

I want roles in companies for the technical artists to progress. Where you get harder problems, work on more complex issues, do things that require more research and autonomy to solve. These skills are also valuable and needed in companies and most don't have a way of retaining that talent as they have no track for them.

The vast majority of time, a harder, more complex problem, requiring more research to solve implies more than one person working on the essence of solving it. As soon as you have more than one person working on it, someone is providing guidance to someone else who is, on balance, receiving guidance.

Or small teams that self-organize. Sort of the axiom behind "Agile Manifesto."

And some problems require not large numbers of people thinking a little about it, but rather long periods of time uninterrupted for one or a few people to think deeply about.

I have very little interest in becoming a manager, and when I have been pressed into team-leadership roles in the past I've found it uncomfortable and stressful. That said, I have come around to the view that because of the simple fact that any large engineering project must be a team effort, once one's ambitions become large enough, the ability to manage people is the only tool powerful enough to implement one's technical vision. I believe it was reading Joe Sutter's memoirs (Boeing 747 chief engineer) that really crystallized that view for me.

In my own career, I am currently pursuing independent consulting as the "progression" of an individual contributor role. I believe this is fairly common, and I think there's kind of a mutual cause-and-effect going on there with the lack of good senior IC paths at many companies.

As someone that has been on that spot as well, consulting seems to be the only safe path to grow old and keep doing tech.

Most companies don't have any issue bringing in the aging expert that will code and lead their internal team, teaching them the in-outs of the technology they should master, yet have serious issues having such skillsets in-house.

You can progress to highest IC levels as someone who wants to work with their hands directly on code/issues (saw that myself at 2 different big tech). But it’s harder and more one off.

Reason for that is simple - in most areas you can achieve more, if you can properly guide dozens of engineers than lock yourself in the basement. Main exceptions are crazy specialized perf gurus.

A lot of the art though is what not to write. Too much code is written.

Generally referred to as negative space in most art. What you don't write is as important as what you do write.

> This is a problem in many FAANG like companies.

I think this is a problem in all companies in general.

Yeah, if anything individual contributors can go a lot further in FAANG's then they could in most other companies.

Reply on news.ycombinator.com