Join the discussion
Write your take first — we'll ask for email only when you're ready to publish.
- Hacker News
- > That stack of tasks you have to do? Your manager or your tech lead could finish those in much less time and with much less hassle than it takes to help you through them.
I just don't find this to be true and if this is true then the company should rethink how they use juniors. Maybe stop micromanaging them as much and expecting them to do thing your way. Or maybe give them lower stakes or easier tasks. Or maybe let them figure out some stuff by themselves. I dont know what the exact issue in this hypothetical company is, but if they are slowing you down so consistently, something is wrong.
I also find this expectation that a person should do the listed "A" improvements from the get go weird. Juniors, but actually also new seniors, employees grows from just closing tasks to suggesting bigger improvements over time. The people doing A things grow from people doing B things, as they gain experience with particular code base, experience with local politics and mainly gain confidence - or loose excessive confidence.
> You include solid unit tests. (I wish this was a B signal, but baby steps...)
Like, for christ sake, tell them in the first code review. It is not that deep.
by watwut - I sure wish I could relate to this but I haven't been at a company that hired juniors since i was the junior being hired 15 years ago.
- So much of this is written with an air of superiority over the noob. Indicates a bit of an ego problem.
Yes, the noobs are noobs, but the goal isn't to exercise your status over them. Or even to waste that much time trying to categorize between A, B, C. The goal should be to boost everybody's productivity instead of treating them like a game.
by asveikau - So, these self-proclaimed seniors... are they the one who signed the employment contract with the juniors? No? Then you're not their boss, you're a colleague. So stop confusing the two. Take some classes in employment law first.
Guys like this are exactly the reason I don't work in big orgs. They might want their ass kissed, I'm not the one who is going to do that.
by rambambram - For a B level: > * You did not cause other people unreasonable amounts of work.*
I would be careful with this one. As the examples listed after, such as an on-call incident or extra review of code isn’t necessarily on the n00b. Maybe I’m biased being only 4 years into my career but engagement on stuff you did wrong or even points on what you can do better are extremely valuable. From my standpoint, screwing up isn’t a problem if you can engage with the team to recover and learn from it.
- This makes complete sense in an environment where people transition from noob to senior engineer within the same company.
It makes less sense in an era when tenure is better measured in months than years.
It makes even less sense in an era of LLMs.
One area where it might be relevant is the military. People are more likely to stay for longer (unvalidated assumption) and the same personnel jacket follows them if they are transferred.
It might also be thought of as a guide as to when to jump ship. If you have managed to get yourself categorized as a C, then leave. Start fresh somewhere else, take the learning with you, and discover if you have what it takes to make it as an A or B.
- This is an interesting perspective(and a great roadmap for juniors to try to improve), but I think for the most part the thesis is wrong, at least in my experience.
Companies do not hire juniors as some long tern play to develop them into good engineers. They hire juniors because they have junior level tasks that need completed.
by LPisGood - I've met maybe 1-2 people in my whole life who were clearly beneficial 'A' from the get go. There's also a weird 'A' that tries very hard but causes more pain than inspiration. Meaning, they're clearly smart but think that's all that's necessary to be useful.
I once worked with an intern from MIT who came in and immediately submitted large PRs everyday that improved the algorithmic complexity for a bunch of functions. Which was awesome to see but the changes were off the hot path and the code was much harder to read. The part that still comes to me was when I'd said during a code review that there were other more pressing concerns, the intern said yes but you can't argue against the improvement in time complexity.
Smart guy. Inspirational, even. But better suited to a large corp than a startup. I think a startup 'A' has a lot more to do with attitude about speed and uncertainty than competence.
by nilirl