'BeanDog' said:

web devs: Do you know what node.js is, and what have you built with it?)

How about: What is wrong with it and why it is immature time sink? Or a trivial issue, such as what happens on error. It's kinda of a big and important deal.

This should tell you something about their understanding of end-to-end development process, not just banging out leet "cutting-edge" code and ability to capture low hanging fruit. In any mature ecosystem any problem has already been solved, with node.js it's still primarily NIH until a few years till evolution weeds out dead ends. Is your company willing to support this evolution which is almost guaranteed to end in abandoned code or code that will be superseded by mature full-time maintained libraries.

Granted, employers have often highly unrealistic expectations, but still, someone who even mentions anything beyond code (deployment, versions, migration, tooling, build, automatization) will likely scale much better than someone who knows ins-and-outs of syntax but doesn't care about anything else. This is especially prevalent in academia, where anything beyond solving the algorithm is actively despised since it's menial task. You get people who will prove N==NP twice during the interview - but sneer at actually implementing the solution, since the problem is solved and something sysadmins should worry about.

Source code is something any semi-interested coder will eventually dig deep enough into. The interesting ones are those that look beyond as well. Even if it's customizing vim or emacs, having full build/install/deployment system (gnumake, cmake, chef, puppet, custom scripts, heck - anything).

That is, unless hiring for big shops which require uber-specialists, but those are subject to different rules and often certification.

i disagree, the company should hire a Build Manager. Laying any of that responsibility on developers is asking for trouble, its not the devs issue, the process is screwed. You want transparency so people can focus on what they are good at and be more productive. This also makes new junior developers easier to handle because they won't accidentally break a crucial part of the process.

'BeanDog' said:

web devs: Do you know what node.js is, and what have you built with it?)

How about: What is wrong with it and why it is immature time sink? Or a trivial issue, such as what happens on error. It's kinda of a big and important deal.

This should tell you something about their understanding of end-to-end development process, not just banging out leet "cutting-edge" code and ability to capture low hanging fruit. In any mature ecosystem any problem has already been solved, with node.js it's still primarily NIH until a few years till evolution weeds out dead ends. Is your company willing to support this evolution which is almost guaranteed to end in abandoned code or code that will be superseded by mature full-time maintained libraries?

No, I am not willing to do so--we definitely don't use node.js in production for a web server. But we did replace a buggy, hand-coded C network app with a node.js widget that's 10% as much code at 10x more stable. Developers who reject new tools out of hand because they're not ready for some particular use-case are just as bad as developers who want to use the shiny new hammer for everything. And a question like the one I mentioned is a great way to tease out either problem, or worse, someone who's just ignorant of a lot of cool new technology.

Replace "node.js" with CouchDB or nginx or Google's closure compiler or LessCSS or any of a hundred other things, and you could get the same objections about maturity, but there are use-cases for each of them where they are genuinely the best tool for the job right now.

</offtopic>

Replace "node.js" with CouchDB or nginx or Google's closure compiler or LessCSS or any of a hundred other things, and you could get the same objections about maturity, but there are use-cases for each of them where they are genuinely the best tool for the job right now.

My observation is something similar to this. Companies that complain that there aren't enough people are the ones hiring by technology names. The more specific, the worse they complain.

I can understand and justify that. In ideal world, a .Net 3.5 developer would know the API by heart, know every single idiom, every bug, every patch, every documentation quirk. In reality, people who actually do know that are in absurdly highly paid positions and few and far in between. The number of companies that need this type of *programming* talent are even fewer. The career prospects for such long-term investment are also horrible so this type of specialization is almost a guaranteed career killer for most.

So for everyone else, if not the tech, what does matter?

One is general programming aptitude. IMHO, programming ability is an inherent skill, something that people either have or do not have. It depends on education and training, but it's like artistic talent. Some people have it and academies test it for acceptance without any remorse. They don't let someone into violin studies unless they show they have it.


And then there's the other type of companies. You'll rarely encounter their job postings nor will they talk about tech much. Instead, they actively seek out people who did relevant work. It doesn't matter which tech (it matters a little), but they seek out aptitude.

This is quite relevant for topic at hand - recent graduates. They don't have relevant experience. Having used API or tech doesn't matter. Instead, focus on the side or curricular work they did. That is the indicator of their aptitude. Good developers will, by consequence, have coded a lot, have lots of projects, etc... At same time, their attention span and effort was limited due to practical constraints.

Technical part of web dev is mostly about ability to efficiently manage ad-hoc complexity. Node.js today, something.else tomorrow. It moves too fast. But the underlying concepts remain the same. So rather than trying to constrain the options even more, cast a wider net. It is considerably easier to find someone with understanding of underlying concepts and have them use or experiment with whatever tech-du-jour is. Especially when it comes to recent grads - they'll do this on their own time with relentless effort - if you find those with aptitude.

Or, we can keep reading WSJ on how there is absurd shortage of skilled developers willing to compete in race to bottom. Something, somewhere needs to give in one way or another. My view is just slightly more productive, assuming one actually needs developers. Many small companies choose to grow organically when people join, rather than having an actual dire need due to market. IMHO, all this talk about cutting-edge tech is red herring. It simply doesn't matter anymore until you get to Facebook scale. And even then it's no biggie, LAMP works just fine for them.

My observation is something similar to this. Companies that complain that there aren't enough people are the ones hiring by technology names. The more specific, the worse they complain.

I think you misunderstand me. I completely agree with everything you said there. I'm not advertising for people with node.js experience to come join us--as I said, we only use it for a rather minor internal widget. I'm saying that it makes a reasonable interview question because people who have learned the new stuff today are more likely to learn new stuff tomorrow.

'Antheus' said:

That is, unless hiring for big shops which require uber-specialists, but those are subject to different rules and often certification.

i disagree, the company should hire a Build Manager. Laying any of that responsibility on developers is asking for trouble, its not the devs issue, the process is screwed.

I think he covered this with the part I cut his quote to. Unless by build manager you mean a software engineer who also manages the build. Not everyone can afford to have someone paid exclusively to manage builds.