I also think it's worth highlighting that "years" is a terrible measure of experience with a technology. Suppose I'm a backend engineer on a team where the pro

I also think it's worth highlighting that "years" is a terrible measure of experience with a technology. Suppose I'm a backend engineer on a team where the production services are all in java, we do some low-scale data analysis in python, and in one corner of the repo there are automation scripts in ruby. If resources aren't available, infrequently do a tiny bit of frontend work in js to unblock my projects. I constantly am reading/writing/maintaining java. I frequently am writing python, in a jupyter notebook, but not building anything large. A couple times a quarter, I need to make a small change in a ruby script. Rarely I write javascript and every time I need to relearn whatever react/redux/whatever else the frontend team has moved to. I work here for k years. But it's silly to say that in doing so I got k years of experience in java, python, ruby, and javascript, plus a year in each of the frameworks that the frontend team drifted through. If I tell an engineering manager "years are not a good unit of measure; I have >5 years of overall experience with ruby, but am not a rubyist" they'll probably understand. In general, if I say the same to a recruiter working through a checklist, I'm perceived as being unhelpful.