I would absolutely love to see a thoughtful 'what engineers want from technical recruiters' post.
Recruiter: "Hi you seem like a perfect fit for <company you like> can I set you up with them?"
Me: "Yeah sure why not"
Recruiter: "Actually you aren't a good fit for that role but how about <buzzwordy startup>"
What's most annoying is that between the bait, and the switch, I've not talked to anyone new or given them any new information about my skills or technical past. They knew what they were gonna do from the beginning.
It's less of a bait and switch, and more that they have like a 1% response rate on their spam. So they spam first and then see if it actually fits you. It's more efficient that way.
1. Actually read my resume before sending me an email.
2. Don't offer me a pay cut to work at your silly startup.
2) Don't even try to talk about project management frameworks because you don't understand them
3) Don't ask me if I have experience in something that isn't on my resume
4) I don't want your 3 month .NET contract in Cleveland even if it "may have the opportunity to go full-time"
5) Get both my and the employer's salary requirements up front so I don't call out of work to spend the day interviewing, being told by the company that they absolutely wanted to move forward, and then find out that my salary was way out of their range.
6) If you name drop a renown company and then start talking about how I should instead interview at some startup for helping people put their mom in a nursing home, the conversation is over.
7) APIs isn't a skill
8) Save the corporate kool-aid for the product owner candidates
9) Just because you got my phone number because some job board sold my info to you doesn't mean you can call me
10) My resume, LinkedIn, and any other job board profiles have my location listed. Don't call me at 6am PST!!!
11) Stop hoping that I am well. I'd be much more well if I wasn't woken up at 6am by your ass.
12) Who do you honestly think is going to work for a company that requires .NET, Java, Python, Angular, React, and "bonus points for Rust experience"?
Because those totally convert to full time! /s
Insourcing is sort of worse than outsourcing to be honest.
1. An understanding of the fields of work and of their evolution. Don't look for candidates based on languages and libraries -- those might be OK to get an initial shortlist, but:
a) Any programmer past junior level should be able to pick up a library (from a field he understands) in ~1 week and become minimally productive with a language in 2-3 weeks.
b) It's the idioms of each field that are difficult to teach, not the tech tools. Someone who did Java ME programming back in 2003 is probably better suited for an embedded software engineering position than someone who has 5 years of writing C++ code in the banking industry.
2. Erring on the side of inclusiveness. If you have doubts about whether I should see a candidate or not, send me the resume and we'll figure it out.
3. Valuing listening over "established patterns". Case in point: short job tenures. I've given favourable feedback for kids who, early in their careers, hand changed two or three jobs in a row. They were brilliant programmers who ended up in large companies, where managers many layers above them assigned them tasks way below their skill level, based on their title of "Junior Software Engineers" rather than on reading their CVs. They did the smart thing and left jobs that hampered their professional development. So far, I have not been wrong about this a single time.
That's not to say short job tenures are always something to ignore. Some people have them because they're assholes -- but okay, we won't hire them because they're assholes, not because they spent less than an year in two places.
4. Valuing honesty over "right" answers. I know people who left their jobs because their boss was a dick, HR wouldn't handle it, their boss's boss was an even bigger dick and they had no access to that boss's boss. These people should be able to say why they're leaving their jobs, not invent reasons about company culture and looking for new challenges and self-deprecating comments about how they just don't think they belong in that team.
5. Appreciating competence, thoroughness and professionalism, not things like enthusiasm. Some of the best engineers I know work on a strictly 9-5 basis and go home to their kids and don't touch computers by choice because their kids are the world to them. Professionalism and competence are hard to fake. Enthusiasm isn't.
If you want to appreciate enthusiasm, take real, falsifiable cues. Don't look for broad smiles and "I'm so super enthusiastic about <this company culture item>". For example, look for relevant hobbies, like ham radio or restoring old computers. Any idiot can fake being enthusiastic about programming in an interview, but faking it by writing m68k on a Friday evening for fun is above and beyond what most people would do in order to look like they love their profession.
The exception to this is if you're hiring the lead for a project, who will be setting the idioms and mentoring the rest of the team. But even then, why are you dictating technology to that person rather than letting them choose?
It is worth asking people whether they are interested / willing to learn the tools you're building on, but it doesn't make sense as a filter.
Just because you are hiring a lead doesn't mean it's a greenfield project with nothing established; even if the lead has freedom to migrate over time, that doesn't mean that it isn't important for them to be able to guide and mentor on the existing stack very quickly.
I generally agree the I industry overemphasized experience in using particular tools rather than skill in engineering systems, but it is not the case that specific tool (including language) skill is completely irrelevant.
Another exception: contractors. In this case, you do want someone who is immediately productive in the language you're using because you do not reap any of the benefits of them ramping up like you do with permanent employees. For contractors, familiarity with the language and ecosystem is the more important part of their job; for employees, familiarity with the business is more important and the language stuff can be picked up.
Although I have met a few of fellow techies, totally sure that no first-line recruiter is able to grasp basic IT knowledge.
But, if I tell you that I'm not interested now, and probably won't be for at least the next six months, don't call me back next week.