They may be able to hack around, write a for loop, track down a bug....but you're not going to get the same caliber of work from someone who first saw python two weeks ago compared to someone whose been using the language for 5 years on real projects.
I don't mean to be combative, but so many job recs and interviews expect X years of Y. How do you get that time it? You learn it, right? I didn't used to know Python, but it was obviously useful for my job. So, I installed it and learned it. I was producing useful results for my company very rapidly. Sure, a few years later my skills are more well rounded and 'pythonic', but really, so what? This is how every. single. one. of. us. learns.
My job is only interesting to the extent I am learning new things. You are only going to hire drudges if you require the applicant already know everything needed for the job. How boring. Obviously I'm not arguing for hiring a janitor to rewrite Google's deep learning from scratch; some ability is required. But picking up basic skills in a new language? Easy peasy. Nothing to it. That's our job.
By having commits on Github numbering in the middle five digits, of course! The only downside is eventually employers will move on to some other arbitrary bullshit metric, and you'll have to start over.
In a small company, everyone wears a bunch of different hats and you will often be asked to do new things outside your official role.
In a large company with bad management, staff turnover will ensure that they regularly find themselves short on skills, at which point you can stick your hand up to pick up the slack.
Either way, if you consistently deliver the goods then they'll keep coming to you with new challenges.
Luckily this is >75% of large companies, IMHE.
Careful. You probably need to define your terms more clearly.
A CS student who knows Java (4+ years of experience) is going to turn out very different programs from a 20 year veteran of Erlang who is just learning Java.
Even with bad Java idioms, the veteran is very likely to be turning out much better code because he is thinking about the underlying architectural issues (failure modes, recovery, concurrency) with far more experience.
Yeah, I watched this play out in real time when I paired them. It was actually really enlightening and entertaining.
I also found out I didn't know as much about either Java or Erlang as I thought I did.
Careful with that assumption. While there may be instances where this is true, I've met many veterans that couldn't think outside the small specialty they had become locked into.
Idioms are powerful in that the shape how you think about a solution within a fixed language. They shape your thinking and the shape of your thinking changes what solutions you can conceive of. A veteran that shows interest in a broad range of topics will have more failure experience and will be able to offer better results.
It's the difference between 10 years of experience, and 1 year of experience repeated 10 times
[1]http://archinte.jamanetwork.com/article.aspx?articleid=20389...
Perhaps. But I would take contention with a CS student claiming 4+ years "experience" with Java unless they were referring to something outside of class work.
When filling a position though, you're usually not comparing "was handed my degree yesterday" candidates with 20 year veterans. . . they're demanding much different compensation and degrees of responsibility.
A more apt comparison of my point would be a 20 year veteran of of Erlang who says "oh, yeah, I can pick Java up. Never seen it, but it'll just take me a couple of weeks." is not, in any way, going to produce the same quality code as a 20 year veteran of Java of relatively comparable experience and general skill.
> A CS student is going to turn out very different programs from a 20 year veteran.
I have seen a company pay someone 100$/hour to learn a new language as part of a 6 month contract. They were producing better code than the company's staff within 3 weeks and finished the project ahead of time.
Granted, he was an EE not a software developer. But, deep knowledge of a platform is often more dangerous than helpful. The surface layer tends to be the least buggy parts of most systems.
PS: I wish more people heard "Let's use reflection!" as "Let's use regular expressions!" for similar reasons. Yes, it can help, but you can also dig a ditch using grenades...
Everytime I've seen it used, it turned into a quagmire of subtle regressions, strange effects at a distance and extremely brittle code.
I think the best pattern there are:
1. Thou shalt never write code that uses reflection on its own code base.
2. Thou shalt never use reflection unless all other options have been proven worse.
Which leaves mostly unit test frameworks for some reason...
But then, my opinion may be unduly influenced by Java vs Ruby.
Most job fills aren't going to be putting the new employee in charge of "greenfielding" the architecture of a brand new app, they'll be doing maintenance or build-out of an existing codebase, giving them plenty of time to ramp up on the fine details of a language while still being productive working with the existing code.
Someone who has been programming for a while but is learning a new language will have a ramp-up period when their code is ugly or unidiomatic, and they will take longer to write it, but it will capture the correct algorithms and abstractions. Compare that to someone who is inexperienced and writes a pile of exponential-time spaghetti that is slow and unmaintainable in any language.
From the opposite side of things, someone who's only been using the same tools for 5 years is probably going to struggle picking up new tools. For the projects I work on, it's rare to use the same languages and tools for every project. I'd rather have someone that understands how to write good code in general and knows multiple programming paradigms instead of someone claiming to be a guru in a single language.
If someone knows Java and JavaScript well for example, is it really going to take them more than a few weeks to be productive in Python (especially if you have someone on the team helping with picking the appropriate libraries to use)?