Speaking as someone who has done a little hiring (i.e. authorized to hire two more people for my team at BigCorp) the answer is "All of them".
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.
> 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.
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.
We're currently trying to hire one or two people in Aalborg, Denmark. Getting anyone with skills beyond C# or Java for a smallish company is next to impossible. We're looking for Python and/or Javascript skills, preferably working knowledge of Unix. We've gotten may one real application, it's strikes me as a bit strange, I would have loved to have had open positions like ours when I graduated.
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.
>> "Skilled software developer ( and yes you can be newly graduated ) will get us nothing"
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.
I had this problem when I started looking for jobs. For things like 'senior' and 'skilled' your best bet is to ignore those, just apply away. If you're resume is interesting you'll get a call. As long as you don't outright lie in the resume you shouldn't be embarrassed.
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.
We don't use the words "skilled", "Talented" or similar in our Python job posting, we simply ask that you know Python and preferably have used the language professional.
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.
For good companies, laundry lists of skills are more like wish lists than requirements, especially with niche technologies. Use the job description to figure out what general kind of developer they're looking for (low level? database? UI? enterprise? team lead?) and apply if you're interested.
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.
> For good companies, laundry lists of skills are more like wish lists than requirements, especially with niche technologies.
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.
I haven't got nearly that much experience (in my opinion but just realized I have ~4 yrs...). Anyway if the job said X yrs/senior and was for a company that I really wanted (not just would) work for I would apply anyways.
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 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).
Try offering the position to remote workers (within a reasonable distance... in your case, somewhere in Europe where there would be no more than +/- 2 hours of timezone difference).
We're not interested in remote workers. We not a software company and the jobs require almost daily interaction with non-developer colleagues (sales team, buyers, marketing, warehouse, accounting).
That is interesting. What would you think if someone applied who had several years C# experience, but had only used python in their spare time on one or two small projects? Assume they have solid understanding of general software development, but they'd need to get used to writing python in your work environment?
We've done that before. Our last two hires didn't know Python when they started, they learn quickly enough. Still that doesn't help us, I assume that the local developers are content working for bigger companies but with less fun stuff.
I agree. I find community meet ups are a great way to find skilled people in specific areas. I've not done much hiring myself (finishing graduate school) but I've done this to find local skill in big data.
It sounds to me as though they are not actually hard to find. You're just looking in the wrong place and not allocating enough funds for salary.
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.
Or, to put it another way, why are you so averse to investing in people/your company that you're looking for the finished article on the job market, rather than finding good people and helping them learn the specific skills you need?
This is exactly what we do, and it's worked really well. Of course, we're doing Agile, which I think helps this process.
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.
I think most software companies will find it hard to get someone up to speed on their existing codebase. If a candidate is relatively green in regards to some programming language, most of the time a candidate can learn a language pretty quickly. The undocumented mess of a codebase typically takes longer to digest. Also, understanding the dev process in use takes some time as well getting comfortable with.
I've met managers who say that but then are surprised when developers in their team complain bitterly about working on anything other than the "hot" technologies.
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!
CFO asks his CEO, “What happens if we invest in developing our people and then they leave the company?” CEO answers, ‘What happens if we don’t, and they stay?”
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.
I had written something on this. I remember speaking to 2 people in a company who needed someone with X years in Silverlight and they weren't considering anyone who didn't have those on their resume. 6 months later they still had an open position and were still trying to hire someone.
I don't understand how people believe this is universally good advice. Perhaps if your company is large enough that you can reasonably pay new employees for weeks or months before they're actually productive, I can see this being feasible. But that's not most companies.
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.
No employee is going to be productive on a new codebase for weeks or months, regardless of the languages they knew coming in. And they're still going to be a drain on resources while coming up to speed with the code base, even if they know the language.
The sooner you realize this, the sooner you'll understand what your real hiring requirements are.
I once eavesdropped on some HR people talking shop, and heard the unsupported claim that thanks to employment laws in the US, new employees are rarely profitable until their second year with the company, which is why it is important to hide the company's warts from the new employees.
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.
It really, really does not take "weeks or months" for a skilled programmer to pick up a new programming language. If you're using intrusive and opinionated frameworks where you have to learn a ton of conventions, that increases ramp-up time. If you're crossing paradigms, e.g. from Java to Haskell or from Python to C, that increases ramp-up time. But if you're just picking up a new programming language, say a switch from Python to Ruby? You can be productive in a week. I've done it before, more than once.
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.
I can learn a new language well enough to be productive faster than I can become comfortable with a new codebase or with all the tooling built around it. I think this is true of many developers.
Its ALWAYS weeks or months before somebody is really productive. They're already learning the build/CI/bug reporting environment anyway. A new syntax/debugging/deployment scheme. The language syntax is really pretty small potatoes.
If a company doesn't have enough runway to have a new hire be unproductive for a few weeks, I'm not sure if that company can afford to have employees yet.
I generally agree with the caveat that you have in-house experts in the language and toolchain (or can afford to grow some). You may also need some experience in the applying that language to your domain, depending on how challenging the problem is.
I agree that any decent programmer can pick up a new language pretty quickly.
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.
But experience in one language should give you a good idea on what library functions should exist (unless you are crossing paradigms). At this point, you can just search (or ask a co-worker) how do I do X in <new language>, and go on your way.
Different things depending on what we are hiring for. It also depends on how people present themselves. Algorithms, protocols, software design, data structures.
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.
I would guess very basic stuff, dns, http, webserver ( not anyone in particular, just what they do really ), smtp ( apparently it's magic ), object orientation, software design in general. You'd be surprised how many people a doing web-development without knowing how the internet works.
) Being able to tell and smtp server from a POP3 or IMAP server is a rare ability.
I've noticed that about Android Developers. I prefer iOS development but have a little more professional Android experience and at least 3 times a week I get emails from recruiters about new positions. I think it might be time to really focus on Android.
It's true that certain languages are particularly hot, and thus particularly in demand. The three that come to mind right away are Ruby, Python, and JavaScript, for which there seems to be unquenchable demand, even if the absolute number of such jobs is dwarfed by Java and C#. I'm sure that there is a shortage of good Erlang, Scala, and Clojure developers, as well.
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.
> 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.
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.
There's also lots of money to be made in pivoting/combining your career learned lessons to date and applying them to a different area.
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.
For the most part that's true, but (for example) unit testing isn't as important in Haskell as it is in Ruby (due to stricter typing rules). Even something simple like mocking an interface requires a lot of boilerplate in C.
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.
For most programmers its not the new language, its the custom libraries, obscure frameworks, legacy code, or tooling that is going to be an issue for them.
True, but I've seen lots of crummy in-house "custom libraries, obscure frameworks, legacy code, [and] tooling" that would have been better if they had been written by veterans of the target language. Or better yet, the veteran would know how to apply an off-the-shelf technology to solve the same problem.
Exactly. I can get a guy up to speed with C# in a matter of hours. The problem comes up when we've got to deal with issues in IIS, Entity Framework, ASP.Net MVC, etc. etc.
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".
I don't really agree. While you can certainly explain the basic syntax of a language in a few hours (assuming a developer who is at least familiar with a diversity of other languages,) it take a lot of time for most developers to become skilled at writing efficient, idiomatic code on a new platform.
IP doesn't have to be magical, not in the sense the parent was referring to. Well-documented modular libraries that perform a specific task well are thoroughly un-magical, and also incredibly valuable IP.
Custom libraries are magic in the sense the OP used that term. So I agree there is no point in calling it all magic; its got to be there, so deal with it.
I never really got the glib claim you can just hire people and get them up to speed in a month. In my experience it takes almost a year to get truly familiar with how everything is done in a platform. It's not that one can't be productive quickly, it's that one will do many stupid and time consuming things.
It doesn't seem quite so ridiculous when you realize that the endemic attitude is that the company should be able to hire someone that can "hit the ground running" and be productive from the hire date.
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.
A lot of times it is the company's hiring process that is broken. I recently did a phone interview for a company and it was an absolute disaster right from the start. The interviewer started asking questions about specific Python functions/methods without even asking me about previous work experience. He was so adamant in trying to understand if I could program that he simply forgot to ask about me. This turned me off instantly and I did not answer any questions. I kept the interview short and politely declined through email for any sub-sequent interviews.
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.
> They brought me in as a contractor for a short period of time and observed me work.
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.
Yes, I agree. It is complicated, but ultimately worth it if you are able to secure someone with my skill set/experience. It might not work for people fresh out of college, but for those of us with years of experience the work environment and insight into how management works is very important.
This is a fundamentally flawed way to hire. Once a developer has 7-10 years of experience, they should be able to learn a new language in a couple of weeks. If you need a Python developer then hire a Python or Ruby developer. If you need a Java developer then hire someone with C# or C++ experience. And once a developer has around 15 years experience, then their past languages don't really matter any more. If they are good at what they do, then they can be productive with new tools from day one. Sure they might be mostly doing code review those first two weeks while they get up to speed, but an experienced developer can provide valuable input to younger developers that provides value to the employer.
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.
The answer to the question is "all of them," because it is the wrong question to ask.
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?
I'd like to come at it from the opposite direction, and help engineers build out profiles of what they are looking for. Not another resume site, but a forum for making anonymous declarations of what the the perfect job(s) would look like. And something similar for potential employers. I probably wouldn't even focus on making connections, but instead just provide scores and feedback on availability, trends, regional factors, indirect costs, etc.
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's what the theory of LinkedIn is for. In practice, LinkedIn is a cesspool of useless recruiter spam, from the very people that drove the employers and candidates to try LinkedIn in the first place.
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.
I find linkedin to be relatively useless in this context. I need to be able to supply scores and weights to the various things I'm looking for, and to submitted job descriptions. I'd like to get at what candidates are looking for, not just what they have done.
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.
Maybe e-harmony, since it'd be double blind model-driven matching, but with near real time feedback while one is refining a set of preference parameters.
> What Programming Skills Are Needed For UK Businesses To Grow?
[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
Talking strictly about UK, but I'm pretty sure this applies to majority of other countries as well. Recruiters are the firewall that surrounds absolute majority of jobs and they won't let you through unless you follow their bullshit protocols. They call you up and try to psyche you up with a position in a modern company/startup which works with new technologies like Haskell, Erlang, Scala, Clojure, etc. There's only one thing though, you have to pass their online 2 hour IKM Java 6 test to be considered... Most of the recruiters I've dealt with don't know the difference between Java and JavaScript. I think this would be a good niche for a startup - providing a service that cuts off the dead meat - incompetent recruiters.
I just had an interview where the company passed because they wanted someone with specific Javascript experience, and I had only useless unrelated experience with Lisp, C++, Java, and C#. None of those could possibly help a new hire be successful, when what they really need to know is the syntax of a specific scripting language.
There was the same problem with ActionScript back in the day. So many people had played with it in Flash, and were going for jobs developing RIAs. They had no idea about software development, but knew how to say goToAndPlay(1) and add a click handler.
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 read the actual page as "Please tell us why you're prejudiced against hiring Graduate Developers and give us your email address so we can name and shame you/your company."
That they even focus on programming languages for candidates, seems misplaced.
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?
You should get in touch with the Texas Advanced Computing Center at the University of Texas. They have people teaching and learning CUDA/OpenCL in large batches; and like any good academic program they want to ensure their students are employed (and employable!). If you like, email me and I'll set up an introduction.
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.