Right now there are a lot of reports about large companies in the Valley not being able to find the talent they need. There are also a lot of reports about companies bending over backwards financially to retain the people they have.

But what I found working for a large Valley corporate in the last few years is that it is not hard to find talent. The real problem is that companies are not ready for new talent. There is not enough flexibility in them to really embrace change and use creative, innovative and hungry developers to the best of their abilities. Companies want the new and cool, and then they try to force it to function just like the old and rusty. It's like trying to turn a 1980s Honda into a Hybrid with some batteries and duct tape.

Let's face realities here: it's no doubt tempting and cool for many developers to work for Google, Yahoo, Microsoft, Facebook or Twitter to name but a few. Where it stops being cool is when gifted and courted developers face outdated infrastructures and the attitude of large Valley corporates.

Outdated and Impersonal HR Practices

Guest author Chris Heilmann has been a professional Web developer since 1997 and has worked in various agencies and corporations on large, international products.
He was a lead for distributed teams in India, Europe and the U.S., and moved from delivery to architecture and developer evangelism to make sure that new hires don't have to have the same bad experiences we all had to go through until companies started appreciating the internet as a platform.
His current role is principal developer evangelist at Mozilla with a focus on HTML5 and the open Web.

The first obstacle I found that weeds out many prospective hires (and by weeding out I mean they look at it, go "pffft" and move on) are HR practices and the companies' job sites. Check out the HR sites "Jobs @ corporate" of some of the companies and you will see what I mean. The sites look awful, are hard to navigate, ask you to enter a lot of information and responses take weeks rather than hours. A lot of them need you to sign up for them and keep a CV on file. None of them allow you to link to an online resumé - they ask flat out for a Word Document on first contact. Seeing that Web developers take a lot of pride in their online portfolios and keep their LinkedIn profile up to date this just appears incredibly dated.

Then there's the standardization - every time I wrote a technical job description for a very-much-needed role it went down the rabbit hole of the corporate machine and came out as something incomprehensible full of boilerplate requirements.

Why would a HTML5 developer need to have four years of UNIX experience? What do I care if the applicant has a masters degree or not? Try and read some job descriptions right now and you will see what I mean. A lot of cruft and nothing about the real job at hand.

Even worse, job descriptions have incredible inaccuracies. The other day I got an offer to become the "HTML6" expert for a "very important company" from a random headhunter. Good luck finding that one.

The best HR people I worked with trusted experts in the company to write job descriptions and were very responsive to the needs and questions of the applicants. HR should be always on the lookout for people in the company who spend their time and effort communicating with others on the web and then reward them by trusting their judgment.

Instead of using infrastructure of the 1990s with wording from the 1970s, companies should let their employees be their spokespeople and hire through word of mouth. HR should be there to help with the paperwork and be quick in responding and organizing the interview process.

International Companies Acting Like Local Shops

Right now I see a lot of people from Europe moving to the U.S. to keep their jobs as companies cut down outside the Valley whilst complaining about the lack of talent in it. Go figure.

The only reasons I can fathom is that companies still don't know how to deal with remote workers or fear the work legislation and worker's rights in Europe and other parts of the world. It might even be that they fear the paperwork that comes with it. It strikes me odd that these companies build systems that allow families to stay connected although they are in different countries and localize their products to different markets but fail to do the same for their own systems and practices.

Rockstars should be made, not found. Instead of hiring someone from the outside and making everyone else depressed that they aren't as good, foster, support and most of all listen to your people and find the next shining star.

Remote teams are a great thing if you do it right: a team in India, a team in the U.K. and a team in the U.S. communicating and working together in a sensible way means you can build your products 24/7. The time difference can mean tasks handed over can get finished by your colleagues while you sleep. QA can look at stuff built just hours before and give feedback by the time the engineers return to work.

If there is no talent to be found in the valley, why not hire in Europe, Asia or India? Foster a culture of embracing this idea and don't treat non-Valley employees as second class citizens and you will not have any trouble hiring at all.This also leads to another issue I see with Valley companies - they tend to hire boutique employees and rockstar teams.

Rockstars Need Roadies

One other big mistake is that companies are always on the lookout for the next rockstar developer.

There is a myth that there are developers of awesome who do everything right and are amazingly quick in turning around a new product whilst having lots of very creative and visionary ideas. Don't believe the hype.

Of course some developers are very gifted, but they also tend to leave quite a mess behind. Much like real rockstars you need roadies who do the dirty work - turn the awesome ground-breaking ideas into working products that scale and fit nicely into a framework for example. By exclusively supporting the rockstars and by focusing on hiring more and more superstars you will end up with roadies and a stage crew that do a bad job connecting the cables and making the PA work. Then the songs of your rockstar can't be heard.

Rockstars should be made, not found. Instead of hiring someone from the outside and making everyone else depressed that they aren't as good, foster, support and most of all listen to your people and find the next shining star. Then you have someone who already knows the environment he or she has to shine in instead of someone who comes, shines, fizzes out and leaves scorched ground behind.

What Are You Buying Startups For?

Companies keep buying startups with cool products, good ideas and talent. Most of the time the reason seems to be to buy them before the competition does. Buying and integrating a startup into a larger corporation is quite a task - after all these people started their own thing instead of joining a company in the first place. Most of the time buying a startup has bad consequences for the parent company.

First of all the cases where the integration of the new small agile and innovative company into a large corporate worked are few and far between. Most of the time the company gets bought, the original employees get annoyed that they have to change their ways, the CEO cashes in and once the required period of staying is over moves on to new and better things or to start the next company. The amount of blog posts by disgruntled engineers of startups ranting about the period of merging is legion. You bought a working thing, maybe it is a good idea to leave it as it is and get its data and access to its users instead of trying to change it.

Secondly, buying a startup for a lot of money gives a message to the engineers in-house that they are missing out. It feels wrong that the company buys technical companies and pays them a lot of money when what they do is not that hard (and engineers always consider things not hard). It gives engineers the feeling that they just didn't get the chance to do something similar as they were busy ploughing through endless bug reports instead. It also makes them feel inadequate and that means that the startup engineers working with in-house ones on integration are already in for trouble.

Instead of buying startups and trying to alter them to fit the rest of the company (which was exactly what the startup didn't do, which is why it was a success in the first place) why not just partner with them? By all means buy them but don't try to swallow them as it will cause you stomach ache and make people leave.

Interviews are Applications

They say that you never get a second chance to make a first impression - especially when it comes to job interviews. In a saturated market however where several companies try to hire you as an expert this works very much both ways. You apply for the job but the company also applies to you.

How about giving an applicant a real-world problem to solve? How about showing them some live code and asking them why some of the things are done the way they are done? How about showing them erroneous code and ask them to debug it...?

Judging by some of the interviews I went through before landing my current role, I am not surprised that companies are struggling to hire people. You have of course the odd press release where the CEO of a large corporation hired some kid on the spot after doing a cool demo, but let's face reality: on the whole, job interview processes are tiring, annoying and to a large degree about going through the motions rather than really trying to find a good employee.

You are aware that developers right now get a lot of offers. Why would you put a several day process in place with dozens of interviews starting by forcing the applicant to sign an NDA?

I've declined a few job offers after the interview and the reasons were much the same that makes job listings ineffective:

 

  • Impersonal. Interviewers had no clue who I was or what the role was. Instead they were just sent in as they were "technical" and available. This meant that I got the same questions in several interviews (which also meant that interviewers had not conferred with the ones that questioned me beforehand) and I was asked the only set of questions the technical person knew - regardless of how irrelevant they were to the role at hand.
  • Bad planning. Interviewers didn't show up, couldn't be found and once we were kicked out of a meeting room during my interview as someone else had booked it. If that happens during the interview, what impression does that give me of day-to-day life?
  • Classic, out-of-the-book interview questions. You can guess that in five year's time I will not have started my own cult or bred a new race of atomic supermen. My biggest weakness is most likely that "sometimes I work too hard" and not that I love cross-dressing and dancing to Polka in public fountains. The answer to "how many golf balls can fit into a school bus" is "as many as possible until it is full," and the answer to "how much would you charge for cleaning all the windows in Toronto?" is "a million billion gazillion dollars" while using your pinky doing a Dr. Evil impression. Let's move on, shall we?
  • Generic CS questions. I was asked several times to write a solution for an algorithmic problem on paper or on a whiteboard. You know, math problems. The things you do to get a degree. I thought I was hired as an expert - why not ask me the things that make me an expert instead of asking me to repeat what I learnt in the past?

 

Let's think out of the box:

 

  • How about giving an applicant a real-world problem to solve?
  • How about showing them some live code and asking them why some of the things are done the way they are done?
  • How about showing them erroneous code and ask them to debug it or tell you which parts are not optimal and how they would improve them?
  • How about asking them to document some of their own code and explain to you why they did things the way they are?

 

How about this as a rule: no interviewee coming through the door should be a stranger. Interviewers should have researched them and prepared a few questions and ask for explanations. That way you save time and money and you don't make people feel belittled or give a wrong first impression of your company.

And Finally, Why Not Give Geeks What They Want: Respect and a Voice

Large corporations are seen as black holes. You see very outspoken and active developers who blog, participate on forums and mailing lists join a large company and vanish of the face of the earth a week later. I was once congratulated on my blog and my online work and then told in the same sentence that I would have to stop doing that when I joined the company. Wait, what?

If you want to find and hire talent, show off the people they'll be working alongside. Instead of silencing your employees give them an infrastructure to use to show off to the world what they are doing. Coach them not to disclose copyrighted technology or company secrets, but give them a voice (a simple blog system will do) and a playground (a virtual server with a domain like people.corporate.com/name) to show the world that in your company there are people who do awesome stuff and you won't be employee #14321 but instead the same person you are now - only with a company that is OK with you telling the world about the cool stuff you do.

Show off your staff and more will come.

Photo by sundstrom