Hacker News new | ask | show | jobs
by sethammons 2769 days ago
I would not define "senior" as "one who codes quickly." I also would not define a software developer's level as "newb." So there is that.

Junior, mid-level, senior, and then maybe principal. I would gauge them by a combination of time in the market, ability to write production grade code, the ability to make informed tradeoffs, ability to work independently and as a team player, and ability to work across teams and disciplines effectively. A very, very small part of that is "quick coding."
1 comments
austincheney 2769 days ago
> I would gauge them by a combination of time in the market,

Absolutely not. Time on the market isn't an immediate indication of competence. It certainly isn't an indicator of potential. In my experience you are so much better making an objective hiring choice by throwing EVERYTHING related to programming and interviews away and simply providing a battery of personality tests. I went through this when I was interviewing with Bridgewater.

Performance is better determined by the briefness of product, the speed of execution, and minimal time of delivery. An educated person can make gross determinations of this by examination and testing of the code. Likewise, lesser souls can evaluate the product for code style, a super high dependency count, and favorite framework.

Ultimately it comes down looking for an ambitious endeavor versus looking for emotional comfort.

link
sethammons 2769 days ago
Time in the market is not good by itself, but can be a proxy for leveling. Someone could have 15 years of repeating 1-year experience and be a junior dev. Another could be out of school by 1 year and show tremendous potential and have shipped some great stuff and quickly fill a mid-level position. But time in the market is definitely a consideration. Not the most important, but, for sure, on the radar.

For a normal person, it will take time to develop expertise. Time for exposure to novel problems and time leveraged for (the opportunity of) growth.

After you get into an organization, you can level up quickly depending, to a degree, on the speed of execution. I also agree with you that it is uninteresting to gauge leveling based on code style, dependency count, and/or a favorite framework. However, discussions around those can lead to a better understanding of someones professional maturity.

link