Ask HN: How would you define a “junior” software engineer?
3 comments
"Years of experience" is a massively variable measure. I've known devs who have "one year of experience ten years in a row" and know far less about programming than some college graduates who have done internships at three different companies during college. "Years of experience" isn't as critical as "range of architectures" or applications/situations in which you've worked. You always learn something new at every shop where you work... if you're not getting a lot of variety in your job then seek it out -- or think about getting more experience at another employer.
My definition of junior is "an engineer who can't complete start-to-finish general tasks alone". To unwrap it, it both requires certain knowledge and working experience which certainly couldn't be quantified in years (e.g. my current employee had a 21 y.o. lead developer on a certain system who had a 5 years of directly relevant experience hence the role).
Several traits or indications I mostly come across with junior engineers is that guidance from seniors or on-boarding might be slightly more involved for them to bring them up to speed. Usually, they have less experience in working with production-grade environments or have some internships under their belt to make up for the entry-level experience gap. I would say that "years of experience" isn't enough to define/assess if an engineer is "junior" but my definition fits in with their ability of communication and critical thinking.
I would regard a "new grad" as "experienced" if they can objectively explain their choice of technology with evidence on their decision and if they can reason with the team with a proposal. Repeating this with good feedback and a ROI makes them experienced. Some projects in the open-source world are meritocratic, with a number of significant patches == commit access which makes them a trusted maintainer.
I would regard a "new grad" as "experienced" if they can objectively explain their choice of technology with evidence on their decision and if they can reason with the team with a proposal. Repeating this with good feedback and a ROI makes them experienced. Some projects in the open-source world are meritocratic, with a number of significant patches == commit access which makes them a trusted maintainer.
Seems like having some gauge from a decent sample size of engineers could help to have loosely defined in specifics?