- 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.