Ask HN: How can a junior dev maximize their income?

If they can get into a FAANG, I think they're already maximizing their income compared to the rest of the industry (not everyone in Tech works at FAANG). I would focus on broadening my knowledge of as many things as I find interesting and not try to specialize for a few years because platforms and languages are always going to change, but there are a lot of core things that everyone needs to know:

  - HTTP/TCP/UDP and basic networking
  - Client/Server architectures
  - Machine learning basics
  - Cloud Computing basics

Every platform has a different flavor of these things, but if you understand the basics a lot of the knowledge carries over (or you at least can see why one framework picked a particular trade-off over another)

Also, I'd learn a little bit about Product, and what Product Managers do. Lenny's Podcast is amazing for this. Thinking about Product and how it leverages Engineering is really important. Customers don't give a shit about your backend architecture, they just want a good experience. I think that helps keep you from going down too many technical rabit-holes

In my own network and in my current role, I see people that should have left years ago, but they never got the hint that their careers stalled. I would have a direct conversation with my manager to see where the growth is and then verify that with action (Are they promoting other people instead of me? If yes, leave.).

As far as reaching staff and then jumping ship, I have no idea. I started my career 10 years ago and at the time, I thought "senior" was the highest option, but then staff role got created.

I wonder if in 10+ years, the IC ladder will get taller, so people don't feel "trapped" at staff level.

That is the only correct answer.

Is there a reason why it was low on the list? What qualifiers did you placed more on? Could you explain more about the thought process?

I’ve also done a decent amount of interviewing, and have a similar (but slightly different) experience to the GP.

We considered someone’s career history a problem when they had several jobs of ~a year or less. Or someone interviewing for a senior position with 4-5 years of experience across 5 companies, for example. If those were the case, we were much more likely to reject them.

If someone (hypothetical) had 10 years experience, with a few that lasted 1-2 years, one that was only a few months, and maybe one that was 4-5ish years, then that was no problem at all. We wanted to be sure they had seen the consequences of their prior decisions, if they were coming into a high-mid or senior role.

When we did hiring, we wouldn’t be comparing candidates 1-to-1 like “Well A had this, but B was good at this, which one should we pick?” …instead, we would just say “ok we’re in hiring mode, keep hiring everyone who is good until we have enough for xyz goal”. So it wouldn’t be that CandidateA is better than CandidateB, but rather if they both met the standards, then they’d get hired.

Some of the qualifiers that mattered more than tenure for us were:

* are they capable of explaining technical problems and communicating

* do they understand algorithms at enough of a level that they won’t cause major performance issues

* are they polite and friendly, how do they respond to feedback

* can they build an architecture which handles expanding requirements

* how eager are they to learn and work on our tech stack + business domain

I haven’t interviewed juniors really, so I can’t speak much to that. But when we’ve hired someone less experienced, it would be the same requirements as above just with a lot more leeway on tech, and more emphasis on “eagerness to learn” + “receptive to feedback”