4 ms·
The main issue with 'seniority' labels is that they are contextual - dependent on the hierarchies already in place in the existing team. In simpler language, wh
by hunglee2 10y ago
The main issue with 'seniority' labels is that they are contextual - dependent on the hierarchies already in place in the existing team. In simpler language, what is a 'junior' developer changes depending on who is already there. The main manifestation of this in the recruiting process is a misalignment of expectation between the candidate and the employer. And all kinds of bad things can happen from this: under / over sold jobs, job title 'inflation', incipient turf wars and so on.
It's not an easy problem to solve and we've wrestled with this on Workshape.io (matching platform for Software devs). The formula we've come up with is a 4 level hierarchy based not on experience or times served but on the role you play within the team.
Entry - you are competent, but need guidance / supervision / mentorship. Your code will be reviewed before deploy
Mid-level - you are competent but do not lead or manage
Senior - you are still hands on, but do lead and manage others
Lead - you may still be hands on but managing / leading / deciding are the most important things you do.
Its still our categorisation though and we know it's not perfect at all
- alinalex 10y agoI think your hierarchy is pretty much realistic. I love what you're doing with workshape.io. I would like to chat with you more on the recruitment topic. Would you be interested? My Twitter handler is @RautaAlin
- hunglee2 10y agoYeah of course. Happy to chat. Followed on Twitter (we can DM there) or if you prefer, email hung@workshape.io
- kod 10y agoI've got well over a decade of experience, much of that as a team lead, and I still think everyone's code including my own needs review before deploy.
- cheez 10y agoYeah, that's kind of nuts. No one is above review.
- Bombthecat 10y agoWho has time for that?
- duncan-donuts 10y agoWhy are you in a rush?
- nevon 10y agoPeople who don't have time for having large parts of their system only be understood by a single developer.
- EliRivers 10y agoI've worked in places that didn't bother with code reviews. In the end, they didn't have time for it because all their time was spent desperately trying to keep the mass of poorly-designed, inconsistently implemented legacy code (which included code written the previous week - "legacy" doesn't mean "old") working. There comes a point where there's no time to stop and start making things better, and you just watch the inevitable disaster come hurtling down the track as people are forced to continue churning out legacy code to keep it going today, knowing that they're just ensuring the final crash will be that much more destructive.
- dhogan 10y agoExactly. The question ought to be "who does NOT have time for that?"
- closeparen 10y agoAt my organization, everyone's code gets reviewed before deploy, everyone (especially leads and managers) is learning and getting mentored, and everyone gets guidance (new projects and major changes have a design doc that goes out to the whole engineering org for comments). Tech leads are expected to do more architecture but having direct reports and writing code are usually mutually exclusive. So, everyone is junior?