"For example, if I am looking for Ruby on Rails experience and I have candidates with strong python and Django experience are they off the list?"

I think in most companies yes, they're off the list. Bottom line-ism is king these days. Companies see bringing someone in and up as a cost, not an investment. All they want to do is pull from the well, but not put anything in. They want perfect fits, and they want other companies to make them. It sounds like a frighteningly random and risky policy.

I agree. Labor is viewed as a cost rather than investment.

You can find this paradigm in many econ/business courses. You invest in capital; you pay for labor.

Would it be possible to sign employees to a contract then? Flip this on it's head. i.e. we're happy to take you on board, but you have to work here for 2 years at X rate.

In the US (I know, this is a global community) we are largely 'at will' employment (a quick google suggests that only Montana is an exception). Such a contract is not enforceable. To lock people in we use things like vesting - you get stock grants, bonuses, or what have you, but only vest into them over time.

That is not an enforceable contract in the US.

Is this your guess, or are you speaking from experience?

Mostly my cynical guess, and I've seen it personally. But I'm one guy.

I don't think the experience requirements are exactly where you're imagining, but I think it's still there. I've been doing database backed web development for quite a while now, and I've had jobs doing that in C, TCL, perl, java, C#, python, Delphi and ruby. But they were all chiefly database backed web development, so basically the same thing, despite being completely different languages.

I expect I would have significant trouble getting hired to do a different specialization, like parts of a videogame engine (say c or C++ or python or lua). So as long as database backed websites are in demand I'm probably ok, but if those disappeared tomorrow I could become a statistic - if everything becomes apps, I'll manage, but that round of interviewing won't be as easy as the last few rounds of interviewing were and I'll probably have to take some personal time developing a demo to talk about.

I've seen two friends with mainframe experience end up having lots of trouble finding new jobs - they could certainly program, but had nothing they could point to that seemed relevant to the web dev jobs. And a friend who works on videogame engines is trying to make a switch to websites and it's looking hard to make that switch.

So, I don't think it's strictly along language lines, but I do think employers are hesitant to sub in one type of programmer for another. I'm not convinced they are wrong - there's lots of specialized knowledge to pick up along the way that mostly seems to be taught by screwing up a project at some point, and it's safer to hire somebody who has already screwed it up elsewhere once.

Speaking for myself on the specific points you've raised: We're a django shop, but being a rails dev doesn't rule anyone out. A demonstrated record of shipping product and solving hard problems, regardless of language, is generally better than a lot of buzzwords that happen to be on point with the tech I'm working with to day. That candidate will probably get a phone screen, at least. A list of job responsibilities or technologies on a resume won't get you an interview if that tech isn't a good match for what I care about today.

But that's rails... ruby is a pretty strong language, and it's a much closer map to python than other options. As for your other languages...

Someone who's spent their life in PHP with no experience outside that language? At this point, I'd probably pass on that resume. The problems I deal with require a breadth of experience in deeper software engineering-y topics: networking, storage, maintainability... my assumption would be that you haven't been given hard enough problems that require you to get outside of the PHP box, if that's all you've ever done.

Similarly Java vs. Scala. I see a lots of J2EE resumes, and my experience with interviewing those folks is they may understand the J2EE/Hibernate/SOA/webapp stack, but when it comes to non-webapp problems, they're lost. I'd be more likely to talk to someone who has Java, C and Python experience, but no Scala, than someone who's got a broad Java base but has never branched out of that particular language. Scala experience, whether or not immediately relevant, is more likely to be correlated to be harder problems, self-development and exploration -- at the very least, that someone is trying to keep up with industry trends.

Maybe my J2EE and PHP judgments aren't fair; but they're heuristics developed over some time.

It seems like the requirements for jobs continue to increase. Not too long ago, you could get a job just having experience in one/a few language(s) with a few things in a portfolio.

As a guy who's always looking for advice on getting an entry-level position, I've been told to learn a dozen or so technologies before applying for a junior position: HTML, CSS, JS, Python/Django||Ruby/Rails||PHP, Linux, Data Structures and Algorithms, Photoshop, Design Principles. I also need to have some good quality projects and approach hard problems, which can be time-consuming and difficult on your own. Even then, some places filter out candidates who don't have a CompSci degree.

To me, this seems a little high for a junior position (Any company, not Google) and sounds more like a full-stack web developer (I'm just shooting for a Front End spot). With no professional experience, there's no way I'm going to be proficient in all of those domains unless I spend a long time learning on my own and that doesn't exactly pay the bills.

As the problems get harder and more people drift towards CompSci, the requirements for even a minimum-level position will continue to increase, while the time to learn all of the requirements remains the same. This will hurt the talent pool in the long run, although people that have been riding the wave will command very large salaries if the talent gap continues to widen.

The problem is that even at the junior dev level, you're delivering solutions, not skills. And you really do need all those skills to build a useful frontend webapp. The only two that you could possibly cut out are Data Structures and Algorithms & Photoshop, and both of those definitely help.

The way I would approach it if I were gunning for an entry-level frontend dev position would be to just start building webpages. Start with HTML, and layer on CSS. Make it interactive with Javascript. Now serve it up from the backend with Django/RoR/PHP, which will also teach you Linux. Work with it for a while and you'll see the reason to learn Design Principles. You don't have to learn everything about those topics at once, but as you face new problems with your webapp, you layer on new skills.

Eh. I'd have to slightly disagree.

Having some experience in one of those frameworks is certainly useful but it's not really a requirement of being a front-end dev.

As long as you're intelligent and can use Google you'll pickup working knowledge of a language or framework quickly. This is why the best companies hire people based on who are they are, not what they know.

There is also the semantic issue of how deep one must understand a language or framework. For example; I build custom WordPress themes and have a general knowledge of PHP but I'd never put on my resume that I know PHP. Not because I don't want to work with it, but because working knowledge doesn't constitute extensive knowledge.

A junior level position for a skilled worker usually requires at least an undergraduate degree, which is four years of training. If you aren't getting a CS degree, you're still perfectly eligible to get a position, but that doesn't mean you get to skip the training. The tech you need to learn for a junior position can easily be learned in an equivalent four years, and if you're committed you can probably learn it in a year or less. That's a hell of a lot better than the situation for other skilled workers.

If you want real advice for getting an entry-level position, it's actually quite simple. Step one: build things. This will help you develop the necessary skills to contribute to a team. Step two: tell people about them. The majority of job openings are filled through referrals and networking; sending in resumes to job postings online is a very inefficient use of your time.

Go based on the job description and if you find a company you want to work for, figure out what technologies they use internally via open source or LinkedIn profile skill sets and job ads. Write on your resume specifically what the job ad asks for, practically repeating what it said, and mean every keyword. If you don't have the skills listed, don't apply for that specific position. Full stack or not, if you want front-end, learn front-end technologies. Starts with the browser, might end at the backend, but honestly? People will love you if you simply don't mess up existing code and can learn on the job from more experienced devs. I don't think that will ever change, it's just getting your foot in the door that's more interesting. As much as possible, try to gain the interest of your prospective manager and ... sometimes it just takes luck for both you and your prospective employer to agree you're a good fit long enough to sign the paperwork and deliver during the first few months. It's okay if the job's not what you expected, as that's happened to me for pretty much every job I've had. Thankfully, for most employers, "just doing your best," is enough. Mostly.

This idea is missed by a lot of candidates "Write on your resume specifically what the job ad asks". When I am navigating the online job posting jungle there is one thing I try to remember, you are being judged by the paper you present. Your goal is moving to the next step (interview)so you can dazzle them with your skills/personality. Spending some time learning about the tech the company uses, and from the JD, how they use that tech instead of rushing as quickly as one can to the submit button can make a huge difference. Give some consideration to who is on the other side of that submit button. In most cases the person reviewing your resume is not technical and could really use your help discovering why you are a fit for the job. At some point the non-A playing Ninja Rock Starey regular folks (myself included) are playing a numbers game and tailoring your resume to speak to the specific position/company can help shorten the odds. That being said, networking is by far the best way to find a gig but can take time, and always works best when you have a job.

They're both generally used to solve one problem and, while they both may be really great at it, don't have a lot of applicability to other things. It isn't a bad filter - don't bother with someone who only has experience and interest in one of the tech stacks that's a total institution.

http://en.wikipedia.org/wiki/Total_institution

Nope, people with Django experience are definitely not off the list. PHP isn't off the list either, though the signal-to-noise in that community does seem (anecdotally) to be a lot lower. In my experience people cast a wide net for senior candidates in terms of what they've worked on, the important thing is how they've worked, what roles they've taken, what teams and projects they've led and shipped. Basically, people that can be trusted to build a solid foundation for the more junior candidates to build on top of. Even with a wide net on the specifics of their experience, candidates like that are still not easy to find.

Is this specified in your position description? Because that's anything but standard.

I feel a lot of employers are exceptionally bad at communicating their actual requirement. Ironically, one of the sure sighs that your job description is bullshit is having a line that says "excellent communication skills". Anything about "fast-paced environment" too.

Well, at risk of going on a bit of a tangent here, realistically my experience in every field is that a distinct minority of jobs ever get filled through formal job advertisements. The vast majority of hiring happens through referrals and networking.

Bringing it back to tech specifically, in my (anecdotal) experience people are rarely bothered by lack of knowledge of a specific framework assuming that the candidate has experience in something similar, or more generally if it is safe to believe that the candidate can get up to speed and contribute in a reasonable amount of time.

At this point we are of course just comparing anecdotes. I will also note, though, that there are a lot of very different subsectors within tech, and hiring practices vary widely between them. In accordance with the venue I am here mostly referring to startups (including late-stage startups).

With all the articles about how terrible just about every company is with hiring, do you think maybe the "talent shortage" is a misnomer and side-effect of companies being outright terrible at judging "talent"?

I think that both phenomena exist and that both contribute to the problem. Which is more significant is hard to tell. In my experience, the talent gap is a bigger problem, but I'm sure there are plenty of people with the opposite experience.

Well based on what you said, the claim that there is a "talent shortage" seems baseless, given that companies are unable to judge talent.

I suppose the salaries of engineers are evidence enough that there is a talent shortage. Though, I've been perusing for a job and would not respond to maybe 85% of job postings because companies can't clearly articulate what they do and what the position they're offering is. I've been to plenty of interviews where they clearly haven't looked at my github, and then ask me odd, incredibly domain specific algorithm questions, and then turn me down as untalented. I've been to plenty of interviews where they think I'm talent, but in all their bragging about how talented their team is, I see signs of lazy engineers.

I think your judgement of how small the hiring problem is is way off. Coupled with companies' unwillingness to hire and train mid-level engineers to senior level (which really only takes a few months with an interested candidate) is the bigger problem.

Some companies are unable to judge talent. Others are able to judge talent quite well, and those companies still have difficulty hiring (mainly at the mid to senior level). That is my argument for there being a talent shortage.

Re job postings, most jobs are not filled through job postings. If you want to find a job at a company that knows how to hire, you will have much better luck if you find the opening through networking or a referral. I have literally never got an engineering job through any other channel. (Note that this does not serve as evidence toward your indictment of HR, most networking/referral hires still go through HR to at least some extent).

It's not a language talent gap, as learning the ins and outs of a new similar language is not a big deal. It is the talent gap of all the other related tasks that go into engineering and development.

Yes these can be learnt by a motivated junior developer reading books and the like, but they can be taught and explained better and faster by a senior developer.

Case in point when I started at a real programming job, I already knew how to program pretty well, but it was the other organisational and system design concepts that I needed help with.

What books would you suggest this junior developer read?

Many of them. :D

Pragmatic Programmers was always a fun start for me back in the day, even some MS Press and plenty of O'Reilly.

Most of what I learned came from blogs and time spent at a computer, however.

There's no substitute for practicing the art of programming to learning actually useful programming skills. Write, run, rinse, repeat. Have fun :)

Oh and when applying for jobs, I found http://pragprog.com/book/algh/land-the-tech-job-you-love useful.

The Pragmatic Programmer, Code Complete, and others in that sort of vein come to mind. Though some of those can be a bit language (and version thereof) specific.

It comes down to living in the trenches yourself or learning from someone that has already done so.

I think you nailed it. Employers today have been taught by database/algorithm-drive search that they can get the perfect candidate if they just keep polling the database. In many, if not most, cases, I think they're far better off hiring a smart person who can ride a fast learning curve without falling off. They also get the high motivation that comes with a new hire who is pumped to be doing/learning something new. But, how many managers are really good at picking out people who can learn quickly and come up to speed?

Talk to your developers. Unless they are quite inexperienced they should have a personal appreciation for why language and platform experience are not the most important things to look for...