What Programming Languages Do You Struggle To Hire For?
codingcupboard.com
codingcupboard.com
I'm not being facetious, I seriously mean that.
The skilled people you want are a scarce resource in a world of high demand. The recruiters shotgun anyone whose resume buzzword-matches at least 25% of the job posting. It just sucks.
Imho, your best bet is to develop relationships with the sorts of people you wish you could hire and offer them something interesting when you hear they're considering a move.
An open position in bookkeeping or warehousing however will get us 300+ applications. Skilled software developer ( and yes you can be newly graduated ) will get us nothing.
So yes, I would agree with: "All of them", there aren't enough people to go around currently.
If you don't live in a tech-heavy region, you should also consider hiring someone remote. https://weworkremotely.com/ is one board that seems popular (operated by the 37 signals guys iirc).
Maybe that's the problem. I'm a freelancer but anytime I've thought about applying for a full-time software developer position I get put off by words like 'skilled', 'senior', and a list of technologies the person needs to know that no single developer in the world knows.
I've been coding for about 8 years, professionally for 5 and I consider myself a good programmer. But I don't know if I fit your definition of skilled or someone else's definition of senior as those are both too subjective. It puts me off applying mainly because I don't want to embarrass myself.
Edit: I think a good way to hire would be a short coding test a person can take online BEFORE applying. If they pass they know they are skilled enough to apply for the position, if not they don't get laughed out of the room.
Regarding the idea in your edit, huge companies like Facebook and Google do have coding puzzles and competitions. People who excel in those surely gain confidence to apply to all sorts of job openings.
No, for good companies requirements will be actual requirements and as such be fairly short, the rest if the list appearing as "bonus", "preferred", or other flexible adjective.
I'm a former systems engineer who used to do requirements analysis, so I am a little sensitive to misuse of the word "requirement". Job postings like you describe drive me up the wall.
One thing that I learned later on in life was to not treat interviews as a one sided process. I'm there to make sure the company isn't awful, as much as you're there to make sure I'm not awful. If you go in with a mindset of evaluating the company to see if it's a fit with you I'm sure your fear of getting laughed out of the room will go away. Would you want to work with people like that anyway?
Of course this only applies to people who don't NEED a job.
Our Javascript developer posting is a bit more demanding.
Previous job posting have been even more flexible, still we had to post the jobs twice to get qualified applicants.
Personally I don't believe in coding tests, and would never require it. Coding tests aren't all that common in Denmark, and I think they would scare perfectly good candidates away.
Worst case they would reject me like other places but they might have had an opening for something lower and given me a chance.
If you can't compete on money, you can probably compensate with time instead. A 30 hour work week with liberal personnel policies would be very attractive to someone who likely already earns more than "enough", and probably spends a lot of time padding out hours by just looking busy anyway.
There are a lot of people out there who are working a job they dislike because the job search routine is even worse. Find the company no one likes to work for and actively recruit their dissatisfied employees.
A great way to do this is to 1) contribute back to open source projects on a regular basis and 2) send your talent out to conferences. Companies spend tons of cash marketing their products and won't spend relative peanuts on showing off their top talent and technical achievements to the wider developer community.
/s
But if I have a good candidate that has attention to detail, knowledge of basic concepts, etc. but doesn't know our language of choice, I'm confident we can teach him our language. Especially if he has already learned similar languages. Even if he hasn't, we've hired people with almost no experience as programmers but that have the ability to absorb knowledge and have a passion for wanting to be a programmer.
Then, we've also had applicants that could "talk the talk" and had experience, but ended up being terrible programmers because they lacked attention to detail, or didn't want to be bothered with writing unit tests, or whatever.
Obviously, I'd much rather have someone that I could train with good habits than someone who has experience with bad habits.
http://gillesleblanc.wordpress.com/2013/03/25/hire-talent-no...
It's because recent trends in corporate management have prioritized cost cutting over re-investing in the company's assets. Besides that, training is a dangerous investment when your employees are all "at will". They could take the training and then flip to your competitor, and there's nothing you could do about it.
...other than, perhaps, paying them what they are worth and giving them a measure of basic human dignity. But you can't put that on the quarterly reports!
Variations of that exchange float around the intertubes, but its really true. I saw it first-hand at a defense contractor that mostly reserved enrichment training for those being groomed for bigger things.
Hire someone who knows the concepts behind most languages, and can easily understand new ones.
Keep in mind that this also likely impacts the productivity of at least one of your current employees, and if it doesn't, your newbie's language acquisition is not going to happen as fast, and their ramp-up time on your projects is going to be longer.
There's a big gray area between well-funded startup and well-established business where an entirely unproductive employee can have a non-trivial impact on your cash flow.
The sooner you realize this, the sooner you'll understand what your real hiring requirements are.
After that first year, it isn't quite so crucial to keep you happy. That explains why you never get the raise you were expecting after the annual reviews. You are now profitable, therefore paying you more would reduce profits and make you a less valuable employee.
And so we must go job-hopping.
The difficulty isn't in finding people with specific experience, the difficulty is finding people with a solid enough understanding of essential concepts to be able to do good work regardless of the environment they're working in.
that's a drastic overestimate. at some point, procedural languages really are all more or less the same. sure, there are different notions of types, variable scope, modularity/oo-ness, etc., but someone who knows a bunch of languages knows what concepts to get straighted out from the beginning and can be productive in days. if you find someone who knows a handful of procedural languages and haskell and lisp, they'll be able to pick up whatever language you're interested in.
now, picking up a bunch of toolkits is a different matter, because they really can be just a quirky as their designers want them to be. for example, using gson yesterday, i ran into a bug with json serialization that was pretty quick to diagnose by stepping through a few lines in the debugger, but it took over a half hour of searching and browsing api docs to find out that Maps weren't being serialized properly because i hadn't called GsonBuilder.enableComplexMapKeySerialization(), which it seems like really ought to be enabled by default.
then -- and not even finally in general, just finally for the sake of keeping this post briefish -- there are frameworks, which are like a perpendicular axis to the original language question. perhaps someone really familiar with rails or django and a little java background would be a better choice for a java project built on play than an expert java desktop developer with no server-side experience.
so in summary, if you can find someone who has basically already built your exact project before, yeah, you'd better hire him or her, but otherwise, intelligence, the ability to figure new things out, is always going to trump experience along any single line of expertise that one can attempt to draw through a software project.
However, I think that it's not really about the language, it's more about the libraries. Knowing all the utility functions that exist and how to use them is based on experience, you don't pick that up overnight.
tl;dr: bright inexperienced people pick up the language quickly and then rewrite library functions that already exist.
That, and Android developers.
Hell, there are times I'd be happy if people just understood the difference between TCP and UDP, or knew how to make an HTTP request. I guess it would be a lot easier if we were just looking for code monkeys to follow orders.
) Being able to tell and smtp server from a POP3 or IMAP server is a rare ability.
But no matter what language you're looking to hire for, you're likely to come up short. That's because you don't just want someone who can write code in XYZ, but someone who can write amazing code, and interact well with the others in the company, and be sensitive to business needs, and communicate well. That combination is rare, no matter how popular and new (or unpopular and old) the language is.
Heck, everyone's favorite punching bag, Cobol, is still used in a huge number of businesses. I've seen in a number of places that if you want to make lots of money doing un-sexy work, you should become a Cobol specialist. Believe me, the businesses who need Cobol developers don't really care that Ruby is the new hotness; they've got billions of dollars invested in existing code that needs to be maintained and improved.
This is really an issue of price points. If companies went around offering contracts for double-current-salary, full benefits, and guaranteed employment for 5 years, positions would be filled fairly quickly.
If the required price point is higher than a company can afford, maybe key goals, plans, and roles need to be reevaluated. As I say to my coworkers all the time, software project estimates are not very accurate, so if business will die without 10% returns on their software development investments (or being within 10% of schedule estimates), everyone's already in trouble.
> The three that come to mind right away are Ruby, Python, and JavaScript
That's highly dependent on the problem domain. Again, perhaps those are in demand because companies' expectations aren't keeping up with market prices.
For example, you could take all that great knowledge about unit testing you learned in the Ruby space, and jump into Cobol and in all likelihood you will not only be able to share a new thing or two to some Cobol folks, you might contribute to far better maintained Cobol code.
The new ideas tend to congregate to the language-du-jour.
Of course, most of the "new ideas" were done on Smalltalk and Lisp years ago, but I digress.
That being said, there are probably some things that can be pivoted. The value is in having attempted them in pilot projects so that you already know what works.
Most commodity programming languages are simple. Either they feel kinda like Javascript, or they feel kinda like Java. Obviously there are a few shops out there doing elaborate stuff with Clojure and they have a higher bar, but probably 95% of the work out there is being done with "typical statically-typed VM-based language" or "typical dynamically-typed language".
From that perspective, allowing for a whole month of training seems almost extravagant. That is why people say it. It is to counteract the sheer idiocy of expecting instant productivity.
Their product is APIs for the financial sector. I write APIs for a living, and have done so for a while. Including APIs for the financial sector. I understood their challenges, and the technology. But rather than try and get to know about my experience a little bit first, he decided to test me on my knowledge of some obscure explanation in the Python documentation.
In contrast, my current employer did the opposite. They got to know me a little bit first and then asked me questions about programming. They brought me in as a contractor for a short period of time and observed me work. Then they did three more interviews including a technical one. Which was really interesting to do because it revolved around the decisions made in the short project I was given. The process was very smooth, and I have already shipped a project for the company, and am in the process of shipping the second one. No silly questions about coin flipping, no fizz buzz on a whiteboard. Just real questions about my skills, and an opportunity to show them off on their own environment. I wish more companies hired this way.
I'm glad that worked out for you, but for the time being, contract work is much more complicated than it should be in the U.S. Expecting all future employees to work through a contracting period while paying double payroll taxes and sticker-prices for health insurance probably isn't reasonable.
But as an option for potential employees, that sounds great.
Fact is that we really don't know how to build effective developer teams in the long haul because we have been in an unusual time period where almost all developers have only a few years of experience in their first language.
Times are changing.
When you hire for experience instead of aptitude, it's like trying to photograph Sasquatch with a macro lens.
I see company after company leaving postings open for months instead of just hiring someone and giving him some books to read for two weeks. I thought that was the point of brainteaser interviews--to find out how smart the interviewee is, aside from specific experience.
It is very clear to me that the system for hiring skilled labor in software is flawed at its foundations. There is plenty of supply out there. If you cannot fill your demand, it is for one of two reasons: your requirements are too narrow, or your offered amount is too low.
Is hiring someone fresh out of the diploma stamper and investing in a tiny bit of training really that horrible from a management perpective?
It seems like that sort of data would be worth something to new and established businesses, who both have to sort through an increasingly crowded forest of tools and technology.
It makes sense to list Java and C# in a profile, but I'd give a bump to Python and Haskell opportunities, personally (others might do the opposite).
Actual hiring is driven more by accomplishments anyway.
It was destroyed well before it ever became useful to me. I won't even try the next iteration--whatever it's called--until I am convinced that they can keep the bozos out.
[x] Being able to put up a survey and allow a visitor to receive notification when results are available without faking input and pretending they're a company
We are seeing the exact same thing with JS. The more advanced frameworks tend to weed out those that are just playing around, from those who are serious software engineers.
I am being asked to learn Perl by my employer and I am wondering how much real value it will add to my CV down the line.
When I tell people I am a software engineer, they inevitably ask me what programming language I use. I use the right language for the job. In the past 5 years I've just happened to use C, C++, C#, Python, Perl, shell, AWK, Fortran, m4, and several assembly languages. The language is just a way of expressing something which needs to get done. If necessary, I could learn a new language for a new job.
I'd rather hire a candidate who is able to find and use the right programming language for a job, teaching themselves if necessary, than a candidate with competencies in a given language.
It's always a matter of cost -- what is the quickest and most productive way, now and in the future, to deliver what the customer needs? The costs factor in the decision of which language to use.
The fixation with specific programming languages seems to be misplaced.
It also seems slightly insulting to say that if you haven't had prior experience writing code in a specific language, then you are not a good candidate for the job. Some of us can learn new languages quickly.
For example, I had over 20 years of C experience before I learned C++ on the job through self-learning. I was not hired as a C++ expert, but for broader experience. C++ just happened to be the best language for the project, so I learned it, all the way to template metaprogramming. Before I left the company, I was the goto person for C++ language questions, which is ego boosting in a way, but is not where I wanted my career to go. I did not want to become a language goto person where everyone sent their C++ template compilation error messages. C++ is just a means to an end.
Even if the job requires competency in a specific language because it is the best language for that job, or because there has already been a lot of code invested in that language, a generalist who is able to learn a new language is better than a specialist in one language.
The only time I'd want a specialist in a particular language would be if they were working on a compiler or interpreter for that language, where expert knowledge of the language, and not merely programming competence in the language, is required.
The question should be: Are you hiring a translator competent in a specific language, or are you hiring a problem-solver who can write in a variety of languages and who can learn new ones appropriate for the problem at hand?
Most programming jobs are the latter.