When a company decides we want to hire a "_____ Developer" with the blank filled in, the hiring gap immediately comes into play. Ten years ago, that blank would be a technology space, hence the titles like "Web Developer", "Mobile Developer", "Enterprise Developer", "Desktop Applications Developer", etc. would be given. As the years went by, new technologies emerged and companies became more specific as to what they would like the new hire to focus on, hence they hired specialists. These specialists would have more narrowed-down titles based on the programming language and tools they used, hence titles like "PHP Developer", "AngularJS Developer", "ReactJS Developer", ".NET Developer", "Swift Developer", "Native Android Developer" come into play. There's nothing inherently wrong with narrowing down expertise in specific areas. However this pigeonholing of computer programmers (yes I used that word) has led to oversimplifying the nature of experience and learning that they have accumulated over their entire career. Web developers may have once been Java developers when Java was still owned by Sun Microsystems. iOS developers may have once been programming in VB or C# using .NET frameworks. And Javascript developers who now specialise in ReactJS, yep you guessed it, they were using Flash and Actionscript before the industry went bust.
Imagine you were a recruiter, and I'm hoping most of you reading this are, because I wrote this with you in mind. Say you found out that one of your clients required a "Swift Expert", and immediately you login to your company database of profiles of people (who unwittingly accepted your terms and conditions, privacy policy, and other legalities to allow your company to keep a copy of their resumés for future reference). You find a few who have "Swift" in their skillsets. But your HR training kicks in, and you realised after a few minutes of pondering that in order for someone to be an expert in a given subject, that person must spend 10,000 hours practicing it. So you do the Math based on a normal forty-hour work week, and you come up with this requirement: 250 weeks which equals more than five years experience if holidays and vacation time are accounted for. So you create a draft (hope you didn't actually publish this on Seek or LinkedIn, by the way):
- 4 to 5 years commercial experience in Swift (preferably 3 years in Swift 3)
- 3 years experience in Xcode 8.x
- 7 years overall industry iOS development
- Local experience is required
What's wrong with this picture, you ask. Then you realise that Swift only came out in June 2014 hence your "4 to 5 years" is out, much less "commercial experience". Okay, but Swift 3? You guessed it, it came out much later in September 2016. And iOS developers who have developed for more than 7 years are few and far between. And experience in Australia? (which has a general manpower shortage in I.T.) How many programmers are actually here with years of local experience who are still programming?
And don't get me started in React.
Of course not all recruiters are this ignorant about when programming languages were released, but their HR training does get in the way of evaluating candidates. If you're just reading a "shopping list" sent by your clients and ticking skill boxes and years of experience let me tell you -- a lot of developers come from digital agencies and they work with multiple technologies. So your "iOS Developer" and ".NET Developer" may not have spent those entire months of their employment coding in those languages. Surprised? Here's more -- passionate developers tend to spend their free time tinkering with technologies that are not in their workplace. Think Arduino, Raspberry Pi, GoLang, Python, and Ruby. When you're not under pressure to learn and do so at your own pace, I tend to think you actually learn better. Can they work in a job later on in these technologies of their hobbies, that are not in their "commercial experience"? I can already hear you recruiters saying No.
As I work in a government-controlled company in Australia as a developer, I've had the privilege of sitting in the interview sessions, and even asking the questions, for potential candidates. We had to hire a number of developers last year, and we had to revise the way we present questions time and again because at the end of the day, we wanted people who can do the job. But because we had to go through recruitment agencies and couldn't hire directly, we had to cater to your HR lingo. One of the challenges we encountered was having to create a "shopping list". This was a list of skills that we thought would be required, plus skills that were "nice to have or preferred". It wasn't easy, we tended to put too many things in that list being unrealistic, but also overcomplicates the process -- some of those things can be learned on the job. Even common skillsets have different uses depending on the company you're working for, such as git flow.
So we came up with a plan, that can be summarised in three points:
- Send a written test to the recruitment agencies to screen the candidates prior to being considered for face-to-face interview.
- For the face-to-face interview, formulate two major problems that the candidate has to to solve, which were real day-to-day technical problems we encounter.
- Have only one interview with the candidate, with three to five developers (including the lead) from our team doing the interview.
The written test was sent to the recruitment company so that they can screen the candidates, send the results to us, and then we can decide whether to proceed with their application. There's no passing mark or minimum score, it is simply to give us a general impression whether the candidate is a real programmer.
Once we determine that the candidate is a real programmer we can interview in person, we sit down with the candidate for one hour. There were three to five interviewers in the room, and one candidate. It can be intimidating to the candidate, but we just explain that we are all here, and this is the first and last interview you have to go through. At this point please understand, a candidate's "years of experience in technology Y" or "commercial experience" or "Australian experience" pretty much go out of the window. We've hired people with over 20 years experience, and we've hired someone with almost zero experience. We start asking basic HR questions like "Please tell us about yourself and your experience" or "Have you worked in a similar role before?", etc. Then depending on the answers, we can already tell if the candidate is technically sound. We then ask the two major technical problems and analyse the response -- this was a whiteboard test. The whiteboard answers help us to see the thought process the candidate goes through to solve the problems. During the test we encouraged each candidate to ask us as many questions and clarifications as possible in order to solve these two problems.
Should the candidate answer the questions satisfactorily then we will most likely hire, but we first had to have agreement on the assessment of the interview's outcome. We cannot hire if there's no consensus among ourselves.
This greatly simplified our hiring process, and to this day we don't regret hiring more than ten developers this way. This series of interviews happened five months ago over a two-month period, and only half of them made the cut. These developers are still going strong.
If you're a recruiter reading this please don't take this with offense. This is my opinion and I hope by reading this you can understand the frustrations we developers have with your recruitment process in our line of work.
If the three simple points I mentioned in my company's hiring process can change the way you screen candidates and they work for you, then well and good. But for now I can't see myself applying through recruiters anymore. If this article can make some changes to the way you hire, then I hope developers like myself can get good jobs in the future through you again.
Sincerely,
Rex
No comments:
Post a Comment