Ask HN: How do you define a junior developer? • Hacker News Board

Re: Ask HN: How do you define a junior developer?

#31

Post by quantumhobbit » Thu, Sep 22, 2016, 3:53 PM UTC

beat wrote: post #21

"Do you have ten years of experience, or do you have one year of experience ten times?" A junior programmer is someone who has never learned from a serious mistake they've made while programming professionally. A junior programmer is someone who thinks they should be senior thanks to the Dunning-Kruger Effect ("Hey, I was an honors student at this great college!"). A junior programmer is someone who can't usefully me…

Nothing fixes this type of junior engineer faster than giving them some real responsibility. Let them fail then learn from it. Don't hold them back because that just builds up resentment.

Re: Ask HN: How do you define a junior developer?

#32

Post by gorbachev » Thu, Sep 22, 2016, 4:12 PM UTC

I can't offer specifics, but the way I typically evaluate jr. vs. sr. is whether the person can understand things at the conceptual level or not. Do they understand the design / architecture / reasons why things are/were done in a particular way, do they understand the benefits and downsides, and do they have knowledge about alternatives.

Junior developers almost always only know about concrete things they worked on previously. They typically have a hard time talking about anything other than implementation details.

Re: Ask HN: How do you define a junior developer?

#33

Post by rocket69 » Thu, Sep 22, 2016, 4:17 PM UTC

dccoolgai wrote: post #12

Junior Senior Requires Supervision Provides Supervision Creates Systems that are Resistant to Change Resolves Technical Debt Looks for "easy wins" Seeks to understand tradeoffs Capitulates easily to PMs/etc. (usually to the detriment of the business) Demands cogent plans from business concerns Is always right Fosters discussion and examination of practices (especially their own) by the whole team Easily dazzled by ne…

I don't see looking for quick and easy wins is not a negative, nor is in opposition to understanding trade-offs.

Re: Ask HN: How do you define a junior developer?

#34

Post by recmend » Thu, Sep 22, 2016, 4:19 PM UTC

A good senior developer is proficient in more than one languages, knows or figures out quickly the pros and cons of any technology. They have both depth knowledge in certain part of the development stack and breadth overall.

Assessing seniority by just number of years of experience, or knowing a hot technology doesn't make one a senior developer. A solid Aptitude + Attitude towards software development will make you a stronger developer, and that will also help you pick up any new tools, needed to get the job done!

Good Luck!

Re: Ask HN: How do you define a junior developer?

#35

Post by ChoHag » Thu, Sep 22, 2016, 4:24 PM UTC

mrmekon wrote: post #16

It depends on when and why I'm defining it, but my guidelines are more based on how they work than what they know: * Junior developer - Will not produce much business value if left alone, and may produce nothing at all. Requires supervision. * Intermediate developer - Will produce something if left alone, but not necessarily what the business most needs. Needs minimal supervision, but defined goals. * Senior develope…

* Senior developer - Will produce immediate business value _only_ if completely ignored.

Re: Ask HN: How do you define a junior developer?

#36

Post by gaius » Thu, Sep 22, 2016, 4:30 PM UTC

echelon wrote: post #18

p4wnc6 wrote: post #5

Junior developer is someone who was unable to negotiate a stronger position for any reason, such as experience, recent unemployment, expertise in an outside specialty, company is super tightwad about 'status' and/or pay levels, naive about negotiation, etc. Conversely, sometimes you'll also see someone at a 'senior' level because the title meant more to them than pay or other benefits. Sometimes a title distinction i…

This is absolutely not true. I would expect a senior engineer to come into a new job and be able to propose the design a new service very quickly - its API, architecture, datastores (including sharding, replication, active-active multi-master designs, ...), DR strategy, how it fits into the ecosystem, how to scale it to thousands of QPS, etc.

You might expect it, but I've encountered plenty of 23-year-old Senior Network/Software/whatever Engineers with just 1 year of experience. Basically as soon as they'd implemented a single feature, they would consider themselves senior.

Personally I say a senior engineer is one who solves problems by the most appropriate means. Maybe he fixes a "bug", maybe he/she knows enough about the problem domain, the use cases, the dependencies, the history and changes the documentation instead. Maybe he/she tells a junior engineer "figure out how to scale that" and uses experience to know what part of the system really needs to scale. And so on and so on. A senior engineer spends little time coding and lots of time mentoring.

Re: Ask HN: How do you define a junior developer?

#37

Post by falcolas » Thu, Sep 22, 2016, 4:36 PM UTC

ChoHag wrote: post #35

mrmekon wrote: post #16

It depends on when and why I'm defining it, but my guidelines are more based on how they work than what they know: * Junior developer - Will not produce much business value if left alone, and may produce nothing at all. Requires supervision. * Intermediate developer - Will produce something if left alone, but not necessarily what the business most needs. Needs minimal supervision, but defined goals. * Senior develope…

* Senior developer - Will produce immediate business value _only_ if completely ignored.

I have to disagree with this; a senior developer will produce more value if not completely ignored; if involved with the company, they can then not only help steer the technological direction of the company, but also move tech towards the company's future goals, not the company's current state.

If left undirected, they will still move tech and be productive, but not necessarily in the direction the company wants to go.

Re: Ask HN: How do you define a junior developer?

#38

Post by ebiester » Thu, Sep 22, 2016, 4:37 PM UTC

allsystemsgo wrote: post #13

A good junior dev asks lots of questions and eventually gets tasks done assigned to him or her on a somewhat reasonable timeline. Tasks get done progressively faster as they grow and they ask fewer and fewer questions (and usually said questions are unique, so no repeat questions for the most part).

That's a cultural thing. On a team of mine, I would worry if people weren't asking as many questions. It means they aren't finding the problems and pitfalls.

The questions should change, to be sure, but they shouldn't diminish unless we're not throwing progressively more complex tasks at them.

Re: Ask HN: How do you define a junior developer?

#39

Post by falcolas » Thu, Sep 22, 2016, 4:39 PM UTC

rocket69 wrote: post #33

dccoolgai wrote: post #12

Junior Senior Requires Supervision Provides Supervision Creates Systems that are Resistant to Change Resolves Technical Debt Looks for "easy wins" Seeks to understand tradeoffs Capitulates easily to PMs/etc. (usually to the detriment of the business) Demands cogent plans from business concerns Is always right Fosters discussion and examination of practices (especially their own) by the whole team Easily dazzled by ne…

I don't see looking for quick and easy wins is not a negative, nor is in opposition to understanding trade-offs.

I think the point is that the "easy" way is not always the right way. For example, it's easy to memoize results returned from a database for 5 minutes in response to a request for performance improvements. It's right to understand the business requirements (including performance), deployment strategy, cost of being wrong, cost of being right, and so forth.

Re: Ask HN: How do you define a junior developer?

#40

Post by dccoolgai » Thu, Sep 22, 2016, 4:40 PM UTC

rocket69 wrote: post #33

dccoolgai wrote: post #12

Junior Senior Requires Supervision Provides Supervision Creates Systems that are Resistant to Change Resolves Technical Debt Looks for "easy wins" Seeks to understand tradeoffs Capitulates easily to PMs/etc. (usually to the detriment of the business) Demands cogent plans from business concerns Is always right Fosters discussion and examination of practices (especially their own) by the whole team Easily dazzled by ne…

I don't see looking for quick and easy wins is not a negative, nor is in opposition to understanding trade-offs.

Notice I didn't say "Negative -> Positive". It says "Junior -> Senior". Thinking about it further, I don't think it's possible to properly get to the second state (tradeoff-understanding) without going through the first (win-seeking) at some point in your career... in fact, when I'm hiring Junior devs I select for win-seeking behavior. "Tradeoff-understanding" is more of a philosophical disposition that one (IMHO the best engineers) arrives at later. "Win-seeking" is kind of related to the "I'm always right" point: A junior will say "Of course this is the best possible thing to do and there are no drawbacks" where a senior will say "Wait a sec - this might be worth doing, but let's understand what we're changing or giving up".

So, in a sense yeah - the Senior is still "looking for a win", so-to-speak but in a deeper zen-state where they realize "There are no wins: only tradeoffs".