1. 33
  1. 9

    The focus on years of experience in specific technologies doesn’t entirely make sense to me in recruiting. While it appears quantifiable on the surface, the depths to which users of a tech go in X years differs quite a bit. Also, many job postings I see focus on tech, and would seem to pass over good candidates with problem domain expertise, just because they haven’t used a specific flavor of attacking the problem. This makes sense in some situations where in-depth expertise of a specific tech is required, but the range of job posts I see far exceeds the numbers I would expect this to be.

    1. 3

      While it appears quantifiable on the surface, the depths to which users of a tech go in X years differs quite a bit.

      At my previous employer, we had a saying “some people actually have X years of experience, but many have 1 year of experience, repeated X years”. The idea is that if you’re not actively learning and leveling up your knowledge about a piece of tech, you’re not really racking up any experience.

      1. 1

        Maybe one explanation is that the number of distinct problem domains is vastly larger than the number of tech stacks. In a lot of cases, chances are so low that you’re going to find someone with years of experience in your company’s niche problem space that you’re better off optimizing your onboarding process around training someone about the problem domain and letting them leverage their existing tech skills than around training a domain expert on your tech stack.

        1. 1

          In my $DAYJOB, we seem to have a spectrum of tasks that require X amount of tech stack expertise and Y amount of domain expertise, where X/Y varies from 0 to infinity. That’s why we hire from both ends; Tech people with zero to little domain expertise and domain experts with zero to little tech expertise. Then people start tackling tasks from the side they entered, but we encourage everyone to grow the other skill as well, and they can take on tasks from any end as long as they think they can handle it.

      2. 6

        I explain and ask people to use the following scale:

        • Beginning: has started to use this technology
        • Familiar: has successfully completed at least one major project using this technology
        • Proficient: routinely uses this technology in many projects
        • Advanced: has taught others; is comfortable discussing design and development of the technology itself
        • Expert: generally recognized and associated with the technology

        I fully expect that anyone who answers “expert” on that scale either doesn’t need to because that’s the reason I’m interviewing them, or is bad at self-assessment. On the other hand, I have been pleasantly surprised on occasion.

        One might also be interested in recency: I have beginner-level competency in a bunch of languages and such that I haven’t used in ten years. I’d like to think that it would only be a matter of a week or two to regain those skills, but they have certainly rusted.

        1. 5

          I’m not sure I can agree with your expert definition. The others seem fair to me, but I don’t think someone needs to speak or engage publicly (especially not enough to be recognized!) in order to be an expert.

          To be clear, I do agree there’s a “special” level for someone knowledgeable enough to be immediately recognizable - but I’ve met people who I would certainly call experts that wouldn’t fit that bill.

          1. 1

            If someone clearly qualifies as “advanced”, they are clearly technically qualified for that skill. If you need an expert, you are probably seeking them out rather than the other way around.

          2. 3

            completed at least one major project

            I don’t know if that can be a criteria, I’ve never been employed on something you could “complete”.

            1. 1

              If you were interviewing with me, I would ask more about this.

              1. 1

                I’d say this use of “completed” would be shorthand for “shipped at least a usable version that the customer is actually using without too many problems”

            2. 3

              Ok but 11 years for rust may be true by their policy, but is definitely wrong.. I don’t think there’s much to be found in code from pre-beta. And if you’re going async, well you’re down to 4 years.

              1. 3

                https://en.wikipedia.org/wiki/Lindy_effect

                The Lindy effect (also known as Lindy’s Law[1]) is a theorized phenomenon by which the future life expectancy of some non-perishable things, like a technology or an idea, is proportional to their current age. Thus, the Lindy effect proposes the longer a period something has survived to exist or be used in the present, it is also likely to have a longer remaining life expectancy. Longevity implies a resistance to change, obsolescence or competition and greater odds of continued existence into the future.[2] Where the Lindy effect applies, mortality rate decreases with time. Mathematically, the Lindy effect corresponds to lifetimes following a Pareto probability distribution.

                The concept is named after Lindy’s delicatessen in New York City, where the concept was informally theorized by comedians. The Lindy effect has subsequently been theorized by mathematicians and statisticians.[3][4][1] Nassim Nicholas Taleb has expressed the Lindy effect in terms of “distance from an Absorbing barrier.”[5]

                The Lindy effect applies to “non-perishable” items, those that do not have an “unavoidable expiration date”.[2] For example, human beings are perishable: most humans live for about 80 years. So the Lindy effect does not apply to individual human lifespan: it is unlikely for a 5-year-old human to die within the next 5 years, but it is very likely for a 70-year-old human to die within the next 70 years, while the Lindy effect would predict these to have equal probability.

                So… technologies you should be learning…

                C 50 years. Lisp 63 years.

                Let’s skip bash, basic and fortran though….

                1. 2

                  I once had a very confusing conversation with a recruiter who wanted 15 years of Python experience. That’s technically possible of course, but not really for $50/hr part-time contracts. I actually asked her if she found anyone, and she said yes, she found the guy who literally wrote the book on Python! Because this was in a smaller city, I pretty quickly googled him… he had written a self-published book on Python… and technically had done some Python work 15 years before…

                  If someone gets really particular about years of experience, it’s best to just run the other way!

                  1. 5

                    Some people have 20 years of experience in a technology. Others have the same year twenty times.

                  2. 1

                    Well, there’s the flipside too. I’m sure that when looking for someone with 5 years experience in Objective-C, it’s someone that knows macOS and iOS API, not someone who did it from 1983-1988. ;)