Tech sourcing! Always fun! If you are tired of seeing the same people, try looking in a different place online. What about Kubernetes / Container folks? You could always search local Meetup groups like this one:
1369 members! As long as you have a free Meetup account and are logged in, you can see their full name. But this could take a long time to source….#sadface. And there are only 10 results per page…#doublesadface. What to do? How about you use Meetup’s API? It’s free! There are many calls you can make, one of which is to extract all the members of a group: Continue reading
Part II of Our @ATCevent #SST2014 Series
Last week we talked about the power of TMTOWTDI (pronouced TIM-TOADY) in sourcing. The idea is that there is more than one way to source for a req. Now today we will talk about the next steps in the process: Candidate Engagement and Attraction. When reaching out to candidates via email and the phone, what is the correct way to approach them? What is the best way to message them?
The real question you should be asking is: What do you have that they want? This is a very simple question with a host of complex answers that are changing all the time. There is only one way that you will get the answers you need. By PICKING UP THE PHONE AND TALKING TO THE CANDIDATE!
Now I know that I sound angry by typing in all caps, but I’m really trying to drive home this point: Too many sourcers and recruiters are afraid to pick up the phone and instead only do what is called “email recruiting”. The problem with that method is that it’s difficult to get an honest (or close to honest) read of the candidate. We live in a world where people can hide. They hide behind emails, they hide behind social profiles, they hide behind comments on websites. This technological separation between people allows them a certain level of protection and feeling of bravery. The downside is that the candidate’s answers are not spontaneous, they are edited many times over, and sometimes they are not even their own answers! Continue reading
If you are a programmer, you understand the meaning and power that TMTOWTDI (pronounced TIM-TOADY) can give you. It originates from the world of Perl but also programming practices in general it means that for every solution to a problem, there is more than one way to do it. There are different ways to write the code in order to achieve the desired results.
Now before I receive an onslaught of emails from programmers, I also agree that the simplest, cleanest solution is usually the best for coding and low overhead in a software program.
But for candidate attraction, we need more than one way to find those candidates and attract them to the company. How many ways can this be done? The answer is as many as you can imagine. Even if you use the simplest method in the world for finding candidates, that does not necessarily guarantee a hire. So instead, you picture what the perfect candidate profile looks like, and then devise many different paths to get to that candidate profile. If you just rely on one method, whether simple or esoteric, you are missing out on candidates and possible hires.
It Starts with the Req
Let’s take this Environmental Engineer req in Sydney, Australia:
” Track record in power/energy and civil infrastructure projects. Senior Environmental Engineer with heavy civil engineering experience. Continue reading
|We live in a world of automation. We want to speed things up. Or at least that’s what we want when we’re doing mundane things that are wasting our time. It comes down to 2 things: FRUSTRATE or AUTOMATE. FRUSTRATE: sitting in traffic going 3 MPH and watching squirrels walk faster than you. AUTOMATE: adding a 360-degree jet-propulsion system to your car and flying over everyone. FRUSTRATE: using a sourcing method that is cool…but takes too many steps for it to be worthwhile. AUTOMATE: cutting out the extra steps, getting to the specific information you want, and easily repeating the process.
For instance, it’s no big secret that there are many different coding user groups and exchanges on the internet. And if you source/recruit for the world of computer science, then you should already be aware of the potential use of these sites. As sourcers, you should always remember the basics because they will help you.
Now take a site like Snipplr or Google Code, which everyone knows about. They are sites for developers; with tools, code, discussions, and other technical resources. Whenever you approach ANY site, the first things that should go through your mind are:
- What is this site’s purpose?
- Who uses it?
- What user information is available?
- Can I search for users while still focusing on specifics?
- Can I speed up my search process while still maintaining the integrity of my search?
- Can I search this site from another source? Continue reading
Let’s face it. Some people just don’t want attention. It’s hard to believe that. Especially in this over-hyped, over-socialized, and over-advertised world we live in. But there are candidates on Linkedin, Twitter, websites, and job boards who don’t feel the need to cram tons of information about their experience in one place.
Other engineers do not put certain words on their resume because to their peers, the inference is common knowledge.
In fact, some candidates go out of their way to be shy, coy, or minimalistic about their experience. But some of these candidates could be very good. They might just not want to advertise to the world’s recruiters about who they are and what they do. So how do we find them? How do you find a C++ or C engineer without saying “C++”? How do you find a ruby developer without saying “Ruby” or “rails”? How do you find an accountant with Fixed Assets experience without saying “Fixed assets”? Continue reading
Funny Anchorman jokes aside, the reason for the picture here is because so many people talk about Big Data to the point that it’s a little over-used. So why am I talking about it? Well, because technology corporations still need engineers who are constantly solving data aggregation issues that are ever increasing. And because of this, sourcers and recruiters need to understand what to look for in the engineer’s experience besides the words “Big Data” (which really makes me cringe when non-technical people throw out that word to me and assume they have instant street cred….or tech cred, as the case may be). Continue reading
So this is something that I think (and hope) everyone should be doing in their power to accept, change, and implement. The landscape of recruiting today is light-years removed from the free-wheelin’ early 90’s, where many “old school” recruiters could take on the world with their phone, a rolodex, and maybe a Hotjobs account (with an accompanying action figure).
That time has passed, if it ever should have even existed before in the first place. The top 2 complaints that engineering candidates have about recruiters are:
- They never follow up with candidates about steps in the hiring process
- They try to sell candidates a job that they know nothing about
And as you might have guessed, your hiring managers will NOT be happy if they hear about those complaints.
As recruiters, we have to master several different skills/abilities in order to be a “good recruiter”. Someone who is an aggressive telemarketer or door-to-door salesman will not cut it. You might get your foot in the door, but without technical, sourcing, and company knowledge, you will get the door slam in your face.
The “Old School” Solution
If we go with the “traditional” definition of the recruiter’s skills, they are (or should be):
- Sherlock Holmes-level interviewing skills
- Candidate management down to the smallest details
- Being the face of the company (and/or culture)
- Selling the best aspects of the job and sometimes having to clarify (or spin) the negative ones
The main problem lies with the lack of job understanding and technical knowledge. Sure, you can sell. But the “selling ice to Eskimos” approach only goes so far. People will catch on pretty quickly that you are buzzwording their resume to match your job. The fact is, that candidates have many choices when dealing with companies, and they do not have to deal with just you. Continue reading
These days, everybody is looking for candidates with Ruby programming experience. But if you are a Recruiter or Sourcer who doesn’t understand what Ruby is and the many different places it can be used, you might end up selling the wrong job to the wrong person. You also may ask the wrong questions about the things that the candidate will be working on in their job. As a recruiter, nothing is worse that not understanding the job you are recruiting for. The days of “I am a great recruiter and I can recruit for anything even if I don’t understand it” are long over.
Ruby is based off of Perl, Eiffel, and Lisp. The Ruby programming language is a very versatile object oriented language that can be used for:
- Stand alone applications like those written in C, Java, C++, etc.
- Test automation frameworks like Perl Frameworks, Junit Frameworks, Python Frameworks, etc.
- Web application frameworks similar to PHP, ASP.NET, Java Server Pages, Python pages, Perl pages, Cold Fusion, etc.
- Shell commands similar to bash, korn shell, bourne, etc.
There are other uses besides these, but these are the most common ones that we see companies implementing. Now inevitably when you talk about one technology topic, you end up talking about others. So here is a more in-depth explanation of the list of things that Ruby can be used in: Continue reading
Wrong!!! If you are like most people (that are not developers), you really don’t know or see the difference between the older HTML 4 standard and the in-demand HTML 5 standard. If you talk to a candidate and ask them if they have HTML 5 experience, then of course they will say yes. Anything to get their foot in the door at a top notch engineering company. The candidates that don’t have enough experience are counting on sourcers and recruiters who don’t know how to qualify technology:
When it comes to qualifying technology experience, you can approach it with one of two methods:
- The “Fake it Until You Make it” approach
- Or the “Wowee, this is My Job and I Should Probably Be Good at it” approach
Now I know what you are thinking; “Mark, I’m not an engineer! We should leave the engineering knowledge to the engineers!” You are actually right. We don’t need you to code a super interactive and dynamic website, but we do need you to understand the basics that are involved. So why use HTML 5? Well here’s your list: Continue reading