What technical recruiters want from engineering candidates
keyvalues.com
keyvalues.com
“You’ll work with the core of our digital strategy”
“You’ll work close to the systems”
“You’ll have a central role”
What systems? What is the company even doing? What about fundamental things like
- where is this?
- exactly what is the work I’m supposed to be doing here?
- What’s the team? 4 beginners? 4000 experienced devs?
- What tech is used, ie what is it about my skill set that makes me a good fit?
These questions are literally never answered in first contacts from recruiters. And of course I’m not willing to compose a response or have even a 15 minute phone conversation or a lunch meeting with a recruiter for a job that might turn out to be in the wrong city.
Is this some secret to the recruiting industry that it’s bad to give away details in the initial contact, so that the candidate doesn’t just apply directly to the company? Or do I have to high expectations on these contacts? Or do I have unusual bad luck with terrible recruiters.
This is obviously the opposite of what recruiters want from candidates, it’s what candidates want from recruiters. But seeing as there is obviously a gap there - does anyone have any insight in this?
A) Write "we use PHP4" in the job description. In this case, 98 candidates will nope out when they read this (say 2% won't notice PHP4 or will be desperate) and 10% out of the remaining 2 gives you 0.2 people on average.
B) Be as vague as possible. Write that you use modern tooling and technologies, don't give any details. Now 80 candidates proceed to the next stage. If you only convince 10% of them, you still end up with 8 instead of 0.2.
It's similar to spam - even though >99% people will delete it without even reading, as long as there is a tiniest chance of someone actually buying the advertised product, the spammers will be in the black.
If you're working with Elm or some other cool language/technology I'm sure strategy A would fare much better.
I've done a lot of hiring and we use a "cool" language (Kotlin). We don't mention the language to recruits although it's not a secret (discussed on our website), because we want to hire people with many different platform backgrounds.
As a series A company it was hard to get purist to focus on shipping and we started weeding candidates out that gave off a ‘I just want to work in Clojure’ vibe. Eventually new stuff got written in Java and we migrated off of it due to the hiring pipeline mostly but when we told candidates some honestly dropped out because they were excited to work in Clojure.
I cannot be bothered to create Elm, Haskell, OCaml, F#, Kotlin, Scala, Clojure, Rust, Go, Swift, Angular, React, VueJS, Flutter, Dart .... github repositories, after work on evenings and weekends, just for the tiny chance of getting around the next round.
As if almost 30 year of experience across multiple business domains are worthless.
It's just being cynical about companies and recruiters.
After A/B testing tons of messages (and analyzing messages from a SaaS platform I built for recruiters to send messages) the messages that work are ones that are short. So I try to keep messages brief, reach out about a specific company that might be a match, and hope to get on the phone with you to actually be able to do my actual job. It's very hard to convert someone over an e-mail message. Getting you to respond to my e-mail is the first part of the funnel.
From there if I can get a conversation with you I can move on to the "fun" part of my job. Giving candidates a broad overview of the market based on their interests, expectation setting, and career counseling.
Edit: To answer your question directly the reason you get bad recruiting messages stems from a mix of bad recruiting practices, bad companies/ low investment in HR departments, and bad engineers. Would be happy to give you a recommendation for a solid recruiter in SF or NYC if you're in those areas.
I completely buy that. But in a short message there is still the choice between concrete information (tasks, location, level, tech/tools, salary, business sector, team size...).
> hope to get on the phone with you to actually be able to do my actual job
But that's the point: a phone call is a pretty big effort I think. I might do it if there is any clue that the job might be something for me but I won't do it if there is a risk that the job is in the wrong part of the country!
> Would be happy to give you a recommendation for a solid recruiter in SF or NYC if you're in those areas.
Not in the US, but thanks!
If location isn't implied the only reason you wouldn't give it is bad recruiting practices in your case. Salary/Tasks/Team Size could be changing pretty rapidly for startups and an external recruiter might not have the up to to date info. Companies do a bad job at investing in their external recruiting process. FWIW, I always provide company name, location, tech/tools, a hook about why I like them, and if I can find it a hook about the candidate.
> But that's the point: a phone call is a pretty big effort I think.
Switching jobs is a pretty big effort overall. A lot of engineers who are willing to take the step of taking a call are generally thinking about leaving or actively looking. For strong recruiters the message is just the hook. If you're able to find a few trusted tech recruiters you can use throughout your career it makes the overall search a lot easier every time. It's like finding the all-star real estate agent when you're buying a home. There are a lot of bad recruiters so in your case, it's more likely you haven't found a strong recruiter to work with yet.
Their first stop is probably a Google search: "example job description software engineering"
Then, they replace the buzzwords with their own buzzwords, which they probably already know, and they're done. This takes much less time than scheduling time with the engineering team, and since they'll be doing the interviews anyway, what's the harm? Their part of the job is already done.
The second part is that companies are doing the same thing that applicants are doing with their resumes; they don't want to put any red flags out there, in order to keep their possible pool of matches as large as possible. There's a chance they can persuade you to ignore a red flag if they talk to you; if they list it in the job description, there's a 0% chance.
Examples of information that might be excluded:
> where is this?
- It's in the suburbs outside Reno, NV.
> exactly what is the work I’m supposed to be doing here?
- You'll be maintaining our undocumented, 12-year old legacy backend.
> What’s the team? 4 beginners? 4000 experienced devs?
- I literally have no idea, I was just given a budget and a number of slots to fill.
> What tech is used
- Something you've never heard of, running on top of PHP 4.
> what is it about my skill set that makes me a good fit?
- We will literally take anyone who can FizzBuzz.
Finally, there are some dog-whistle/shibboleth phrasing that seems perfectly clear to the person who wrote the description, but might not be clear to you. Examples:
> “You’ll work with the core of our digital strategy”
- You'll be working on our product that is the closest to making money (or actually makes some! who knows).
> “You’ll work close to the systems”
- You'll be doing some DevOps as well.
> “You’ll have a central role”
- We have a small team.
And so on.
And to think that hiring will have one of biggest impact on the engineering team.
I have the feeling many see this as malicious by employers. But it's already hard to find good developers, employing them as recruiters is a waste of resources. You'll try to find recruiters who have some idea what to look for and then only include engineers in the last stage. Having every application for a senior dev scanned by other senior devs won't work.
As for the recruiter, they can only learn so much about the job because the company probably has 20+ roles to fill where they need to know the basics for all. They can't be expert in all domains.
> “Passion”
Working overtime and week-ends while not getting a dime for it.
- designing your resume
- EQ
- having a deep, enthusiastic, and genuine interest in some aspect of the company
- Think of your resume like a poem
- visual representation of their experience/resume
These are great criteria for hiring a designer or marketing personnel, but these are TERRIBLE criteria for hiring a technical person.
In my fantasy world, a technical resume is in a monospaced font and is eminently readable; I would expect the resume to look good in a code editor.
My fantasy applicant would be very precise in the tech they list, and when asked questions, they would gripe about that technology all day long; if they can't complain about its shortcomings and pitfalls, they didn't use it.
They would not match the job criteria on the posting exactly, because the criteria on the job posting is for some fantasy developer that doesn't actually exist. I would instead expect them to have figured out the core of the actual stack and list it instead.
Sadly, my fantasy world doesn't exist, and we have to pretend we're designers to work around people like this who have no idea how to hire actual technical people.
https://www.quora.com/Typography-Monospaced-fonts-what-are-t...
Lol that is gold. I have to add that section to my interviewing questions.
So to me, constant griping is more of a not-that-much-experience signal.
I aim to answer by listing: a high-level business benefit of X, a time I saw X delivering such a benefit, a time I saw X being a hindrance or failing to completely deliver the purported benefit, something an alternative of X does differently and why, then wrap up with a conclusion that the benefits are situation-dependent.
Reading into how Javascript was created clarified that the "issues" with the language were. I understand the creators(who are probably far smarter than I) chose to make things that way for a reason. I can often just google these reasons "Why does X language do this?" and understand. Any time I think "This seems silly..." there's a reason for it.
"We need someone who can design and implement frontends alongside our product marketing group." Not, "Looking for a JavaScript, Typescript, Angular, React, Node.js, Mongo, and BerkleyDB rockstar."
Because I've personally watched several people who were cultural fits and great talkers be PIPed and fired purely for the lack of an ability to execute technical tasks.
When I read:
>"Looking for a JavaScript, Typescript, Angular, React, Node.js, Mongo, and BerkleyDB rockstar."
I parse it as:
"We need someone who can design and implement frontends alongside our product marketing group. Our technology stack is JavaScript, Typescript, Angular, React, Node.js, Mongo, and BerkleyDB."
The first problem is for people not on the spectrum to recognize that I wasn't trying to speak to the OP as if they were a simpleton. Because for a person not on the spectrum the implied requirement is obvious.
The second problem is a message to people like myself on the spectrum, "This is a new social rule to add to your matrix for interpreting behavior."
Eliminating the first paragraph entirely would have decreased the likelihood of creating the new rule in spectrum people while simultaneously seeming like I was being snarky to non-spectrum people. It's entirely probable that I failed in both my goals in spite of this.
That is true. But there is a huge variability in degree, both on the side of the candidates and on the side of the jobs. I think most people would agree that saying "we need an efficient programmer" is insufficient detail. The same is true for a requirement like "needs to be able to communicate and work effectively alongside other humans."
On the other hand, I think recruiters take it way to literally too. The will quiz candidates and their experience on everything in the list and drop people that don't know 1 or 2 of them (and the liars will get through).
You have to be able to navigate the work environment and find a way to get stuff delivered. Which your "design and implement" part captures, but "cultural fit and great talker" doesn't.
But good practices and clean code habits are older than that.
We always do the same dance: First they ask me for my most recent updated resume. I send it to them. It's a text file. No fancy formatting, no fonts, not even any Unicode, just ASCII. They always ask me to reformat it, and they always send me the same example resume, and they always explain to me very nicely that they want my resume to make a good impression.
I never do it.
Mostly because I'm lazy, but also because I don't care. That resume gets me jobs. I've never posted it to Craigslist and not gotten responses and a job.
Sometimes they nag me once or twice and sometimes I just don't hear back from them.
Now the thing that puzzles me about this the most is, why, for goodness' sake, don't they have somebody on staff to do the reformatting for me? My hourly rate is not low, y'know? I know they have an office full of people 'cause I've been there. If it's such a crucial step, why not provide it as a value-add service?
Oh well. Not really my problem. Just a weird recruiter thought I wanted to share. :-)
I have literally baited people I interview with this type of thing. Asked about things I know everyone who has come in contact with has cut themselves on and been upset about.
I don't really feel the need to complain about languages. I just find the workaround and implement it and move on. All languages have trade offs. I can tell you that this one lends more to scaling projects or this one is easier to maintain, this one is easier to iterate, etc. But getting upset doesn't do anything. You just pick the best you can and work with it. I'm not going to get mad that my hammer isn't also a drill.
It’s whining on the surface but it’s really 90% tradeoffs and 10% badness.
Being able to critique design mistakes in eg. an API means you have a pretty deep knowledge on the domain (and/or API design in general). Being able to argue the downsides of a certain technological tradeoff (such as GC vs not, dynamic vs static) is also important. No one will be able to win an argument on tabs/spaces or dynamic vs static but everyone should be able to point out some drawbacks and benefits.
Describing the merits of a technology is just as good as describing the drawbacks. I chose drawbacks/whine because (unfortunately) I am myself much more enthusiastic when describing flaws than positive sides - itself a flaw, but a very common one.
I can't change the language itself. I feel like a lot of people stress about those issues and can talk about them at length. I'm usually like "This isn't optimal, here's the workaround, this other language does it better but it's got other issues that are even worse for what we're building. Problem solved, moving on." Like, it's just another problem to solve at my problem solving job. The answer is not elegant, but that's the case with so many things in the real world...but this is probably the stoic in me.
I honestly don't know what you mean by this.
It was an agonizing process, but the end result is something that recruiters recognize as being well designed. I hate having to maintain it.
That's what I mean by pretending.
The basis that the HR drone/recruiter (wonderful people or not) is only actually interested or capable of matching buzzwords (when hiring engineers, specifically, but possibly in any field) and thus will pass the resume based on meeting a Ctrl F hit percentage critera.
Once the actual hiring manager get the CV, they ask for the context and we discuss it. This largely gives me a reason to talk and thus make people like me, I feel less awkward because I'm not regurgitating my CV, and the hiring person is less bored because they haven't read this. This seems to give them enough context to move to the hiring stage, few ask me any technical questions at this point.
I'm a contractor in London with a very high success rate in landing gigs. Your mileage may vary, but try to think about the people who read your CV.
> They're busy and have a lot of CVs, thus they want to skim for relevance.
> They want 1-2 pages, they're not going to look past this.
> If they ask you about a tech on your CV and you don't stand up to scrutiny, they'll feel you're dishonest and you've wasted their time.
A little bit of empathy goes a long way.
Additionally, have a master CV template and customize it based on the requirements.
Cutting it down to 1-2 pages, removing everything not worthwhile listing for the advert.
Rephrase the technical terms for the buzzwords bingo as per job advert, e.g. .NET vs C#, ADO.NET vs C# database access,...
Dear God, is that really what they're looking for? Tech hiring gets more ridiculous every day.
- Name - largest on the page, picked a font that looked good at that size
- Email address - monospaced font, colored to appear as a link (which seems silly, but helps pull attention to it since it's the primary contact method for me)
- Physical address - Small font, so it, my phone number, and email address occupy roughly the same visual space as my name. Also, a different font to fit the reduced size without impacting readability
Per job:
- Company name and title - Larger than the description
- Dates - Small so they can exist on the same line as the company name, but a different font to be legible.
- Descriptions and duties (also used for summary) - The baseline for font and size.
A quick glance at my resume won't show the design choices made; it's supposed to be subtle while retaining legibility through a fax machine (you wouldn't believe the lack of quality of some of the resumes which I've been handed over the years). That subtlty/readability is what took the longest.
This frustrates me so much. What if I can't find a company that offers any such thing? This seems like anti-common sense to me.
If you have skills at carpentry, and do a professional job, you can get a job at any construction site. Nobody cares if you have a "deep, enthusiastic, genuine interest" in the type of structure, or the challenges of woodworking, or the layout of the job site.
If you have skills at programming, though, you might not even get a job these days if you can't demonstrate that you're sufficiently passionate about what exactly the company does and how they do it.
This isn't a blue/white-collar distinction. I once talked to the industrial design lead at Fluke, and asked if he ended up there because he had a particular interest in test and measurement. He laughed at me and said no, not at all. He just liked industrial design, and didn't much care where he did it, or what he was designing.
If I didn't know any better, I'd say it sounds like you're searching for people with passion so you can get them to work unpaid overtime for you. I don't know why else it would matter.
Why?
Because programming isn't carpentry. The difference between an average programmer and a great one is that the average one will build what you ask according to blueprints provided. The great one will come up with new ideas for how to make the product better, drive improvements throughout the team and so on. Building sites are hierarchical - by the time the carpenter turns up the plans are finalised and can't be changed so easily, but software is always in motion.
Also, when I look back at the hires we had that didn't work out, "didn't appear to care about the job" is a common theme. Carpentry is a physical job out in the open where everyone can see if you're working or not. Programming isn't. If you're in front of your desk it can be hard to tell if you're working, or goofing off, and the much greater flexibility given to developers vs carpenters feeds into that (e.g. if you're goofing off temporarily we'll cut you some slack because you're a valuable employee).
So in an environment where supervision is less rigid, the gap between most effective and least is high, and it's hard to tell when people are working, having an interest in the work (it doesn't have to be "passion") means you're much more likely to work out.
Your hypothesis only fits 2 of the 3 data points I provided.
Software is the only non-customer-facing job that I know of where passion is considered relevant at hiring time. The mathematicians I've known have all been somewhere between "moderately stoic" and "downright antisocial" and had no trouble getting hired, despite mathematics having all of the features you attribute to programming.
This is a 100% contrived, but here's an example...
- I run a dev team largely using Microsoft tech
- You are a Java developer
- I had a Java developer try out the Microsoft stuff, and quit because they decided they didn't wanna go all in on C#
- If you're work experience in largely in Java, but I see you spending a lot of time writing C# in your personal time, or somehow demonstrating a passion for you, I'm more likely to think you'll be a fit.
Maybe asking people to demonstrate a passion for tech is related to feeling defensive about that tech. Plenty of back-end-y developers trash talk CSS and JavaScript. Someone who works on front-end stuff all day long might not like that trend, so they filter for people excited about JavaScript, and I can't say I'd blame them for that.
Where I differ is with your (admittedly contrived) example. I've interviewed dozens (hundreds?) of people over the years, and I can't say I've seen any correlation between passion and professionalism/competence/longevity.
I think "Hiring for passion" is the new "Nobody ever got fired for buying IBM". It's the CYA response. We have no clue if a hire is going to work out, but if they spend their weekends writing C# for fun, and they don't work out at our company, we can at least tell our bosses "They came across as so passionate during the interview -- we couldn't have known they would turn out to be a bad hire!"
Makes sense. I think I was trying to say we come up with seemingly arbitrary reasons to hire & reject people. Before getting into software, I had expected the opposite. As far as I can tell, hiring would be more effective if we asked candidates to roll a d20 to make a charisma check w/ a difficulty modified by how we're feeling that day.
If I made a software company who openly declared that their hiring process was purely random, would it work as a company? Would it be legal? For that matter, is a standard tech interview legally valid[1]? What if there is no known valid method?
[1]: https://www.hiresuccess.com/blog/facts-about-validation
"It's been determined that our CS interviews are both random and unscientific, and we'd like to reverse that trend. To give us more control of the outcome, and to help us be more science-y, how would you design a random number generator which can be made deterministic by giving it a seed value? We need one for our hiring process."
Do you ever worry that you’re overlooking talented people who have a life outside of programming?
I think companies are also expecting that 'people with passion' will be less impacted by the unavoidable organizational BS and garbage that pops up on occasion.
In my experience, the people with the greatest passion also turn out to be the biggest assholes and unnecessarily alienate their coworkers. Going with the carpentry example, imagine building a house with someone that insisted _everything_ be _perfectly_level_ and went around checking everyone's work every hour and reviewing their work.
Culture fit could more effectively be restated as emotional/social intelligence which a small subset of software engineers severely lack. Hiring an excellent engineer that doesn't enable other team members is a net loss for the organization.
Funnily enough I always find it that the people with passion are the ones that get themselves all worked up and distracted with the BS, the rest just keep on chugging (assuming it's not so bad that they quit).
Perhaps so. (Wanting people to regularly work unpaid overtime could be seen as an instance of "organizational BS".) In this case, it's a good signal to applicants like me that I wouldn't want to work there. Unfortunately, it's become universal across the software industry.
Ding ding ding. Also in this category
* We still shitcorp want the company to be a family * Believing in our vision * Want our employees to be caring about the customer * Have fun and pizza in the office
Unless
a) there are hard cash+ benefits b) there is equity c) there exists a formal incentive structure reaffirming the officially started desires
It's all consciously or subconsciously a way to sucker people in and exploit them without pay. And some people go in knowing that and not caring they get exploited (nurses, some people better than me I know), some don't notice (mostly junior devs/consultants). But for both exploited they get
AFAICT equity is a lottery-ticket at best, and is usually bubkes.
What novel information do you have about equity?
1. I'm talking about equity, not options. Aka, part of the company is yours. With voting rights, or in the case of e.g. Google, at least worth cash 2. In a startup, it is a lottery ticket. If the company is public, you can include it in compensation as there is a market value
If the company actually gives you a meaning number of shares, they can expect you to care about the company beyond the paycheck... because it's your company. If they are Google and the stock is a way to chain you via vesting...at least it's golden chains
If your skills were truly in high-demand, they would verify that you could do the work and are easy to work with then they’d give you the job (see: Nurses).
I remember interviewing for a place and the recruiter thought he was an expert coder since he knew some buzz words. He was saying they wanted someone with SPA experience AND was able to build REST API's. I spent thirty minutes trying to convince him that NodeJS runs on servers and I've been a back-end JavaScript developer writing large REST APIs and back-end services. He was convinced JavaScript only runs on browsers and I was full of shit.
That was at a big-name tech startup (one of: Lyft, AirBnB, Uber, Github).
Other times I've been told by recruiters things like "Sorry, we want someone with at least 5 years of Ember3 experience, not Ember2". Stupid stuff like that.
I don't know if the talent shortage is real, or if companies still haven't figured out recruiting. I think it's probably actually a combo of both.
I now write my resumes full of fluffy buzzwords, my GitHub is full of animated GIFS and pretty pictures and I adjust the buzzwords based on the job posting. Much higher conversion rate.
You know what is impressive about (at least some) technical recruiters I've met? Despite not knowing much about tech, they can pull down $300K/yr (and this is not in SF or NYC).
*
I do know one recruiter who truly does have a good reputation, but not for the reasons you suggest -- I met her years ago and while I haven't seen her for a while, every so often over the years, I'd be talking to someone about job-hunting and they'd say they knew a good recruiter I should talk to and, inevitably, the name they'd then mention was hers.
And I don't think she did this by networking or attempting to create a higher profile or becoming an authority or by convincing people she had access to top people at top companies. I think she's just done a good job for people and so those people feel good about her and therefore about recommending her to others. Someone like that might be worth paying a lot to -- for all that good will in addition to her skill and experience.
*
BTW, it occurs to me that the first $300K recruiter I met told me he ran a Python user-group out of his offices -- and perhaps that wasn't the only group he did this for. That kind of thing, obviously, can help a recruiter become known to developers, but, again, not because of having an out-sized reputation -- rather, by just being around when developers congregate, giving him a chance to introduce himself to them, face-to-face. (I don't know how much business hosting such groups actually brought to his firm, but it obviously couldn't hurt).
This may not be 100% right, but: think about this -- imagine you're a recruiter who is a partner in a firm, not someone just starting out and getting paid very little. Let's say you place people with average salaries of $100K. Your firm may take 20% of that. Meaning that $300K would only require placing 15 people per year -- that's a little over 1 per month.
Of course, you'd have to share the revenue, pay your share of expenses, etc.
But let's say you can place 2 or 3 per month on average. Or 4, whatever. At some point soon, no matter the expenses and revenue-sharing, your cut should reach $300K.
It may not be so easy to place one person every week or two. But you're working with other people and maybe you have some low-paid people to do the drudge-work of sifting through resumes and so on.
*
An interesting point, though, about making those big bucks: the first $300K recruiter I met, some years back, told me this -- yes, you could do well working with him...but he would only hire you if you got yourself trained elsewhere. Meaning, that you'd have take a much lower paying job to start (the number $30K comes to mind, but I don't know how accurate that is -- maybe there are commissions too for successful placements? --- and, in any case, it was a while ago).
So, for at least your first job, you'd probably be working at a large outfit with a lot of people, which might be competitive, with a lot of turnover, perhaps because people wash out or whatever -- whenever I talk to a recruiting firm locally that I've dealt with for a while, most (or all) of the folks I knew previously have moved on.
In other words, you might not make it through the prerequisite needed to get to the $300K guy's firm (and I'm assuming you probably wouldn't start at $300K, or anywhere near that, since you'd be a junior hire).
*
The second guy I met who told me he was getting $300K was more recent. He was an internal recruiter -- which struck me as a bit odd, given that he was working for a startup that wasn't very large, so, unless they were to suddenly grow fast, I don't know why they'd need a recruiter that expensive around on a long-term basis, even a very good one.
(It appears he moved on after being there close to a year, so maybe they reached this conclusion too...or perhaps that's the gig -- you stay as long as you're needed then move on -- or perhaps he just found a better position elsewhere).
*
But what do I know? I mean, if I really understood recruiting, maybe I, too, would be making $300K as a recruiter.
And, if recruiting occasionally proved to be less interesting than writing software, I'm sure I could come up with ways of amusing myself, such as, say, trolling my candidate-developers by scoffing at the existence of server-side JavaScript and seeing how long I could keep a straight face arguing with them :-)
I mean, when NodeJS first came out, I thought it was a joke too :p
The original ASP pages could also be written in JScript.
Luckily I was able to talk sense into him that Rails 5 has like 1 new feature.
Then the company that put up the listing was dragging its feet, and I ended up choosing another offer that got back to me before I even got an interview with the first.
Anyway, not all recruiters are deaf to the voice of reason.
I felt it was because she really had nothing tangible to contribute to the technical assessment process so felt she must do something.
I can tell you this - I'm not wasting my time recruiting for a company that does that sort of thing.
Why I point this out is that many of the things that these people say they want are things that are not really very important when trying to find very scarce technical talent, but such recruiting people are happy to throw away a great developer because some unimportant thing was not present.
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.
- Actually try to get to know and understand a person
- Dont use fill-in templates
- Have some actual knowledge of tech (java != .net)
- Dont make offerings for positions I worked on 10 years ago during college.
- Dont be greedy.
To just name a few...
- Don't try to recruit me for the company I work for
- Don't constantly ask me for referrals for a $500 bonus from your $20k fee
In the last year though, I've met a wide variety of people with a wide variety of responsibilities, approaches, and backgrounds, yet they all share the same job title. There are certainly awful recruiters out there, but there are also some really fantastic ones! (Just like how there are both awful and fantastic devs out there.)
I've gotten to see both sides of job searching/hiring and it has been eye opening. Both sides have similar complaints of the other, which is why the process looks so darn similar to dating.
My guess is that founders, CTOs, and recruiters would all probably make a list similar to yours:
- Actually try to get to know and understand our company
- Don't use fill-in templates
- Have some actual knowledge of our industry/product
- Don't focus on positions you worked on 10 years ago during college
- Don't be greedy
That is hilarious. If the representative of a multi-billion dollar company (or a startup trying to become a multi-billion dollar company) every said something like that to me I'd probably laugh and walk out.
There are plenty of young software engineers who hear about first-year salaries at Google and expect similar comp packages from startups. (Are they being too greedy? Meh, they're just misinformed or need to take some time to recalibrate their expectations.)
There are also plenty of companies guilty of the same thing. Their expectations are too high as they turn away great candidates because they don't have a CS degree from a top school or have an impressive track record of open source contributions.
The OP listed "don't be greedy," which sounds familiar to me. It's easy to have a few bad experiences and then draw a blanket conclusion that every tech company is trying to squeeze me. My point is only that it's frustrating on both sides, and whether you're an applicant or a hiring manager, understanding what the process feels like to the other party will make the process that much easier for you.
If they're choosing between working at a company like Google or that startup, it's not greedy to expect competitive compensation.
>that wouldn't be greed, it'd just be realism.
I think that's the point. Startups routinely want to convince people to work for them for less than established companies. They often talk about wanting to hire people who care about solving the problems they are working more than money.
When someone is being realistic by pointing out that they can make more money elsewhere, they say they are just "being greedy."
You're assuming the big paying tech firms will hire any programmer who applies to any startup. They won't.
I've often heard variations on "don't be greedy" from startups and recruiters when I was working as a consultant.
I'd tell them "We'll I'm making X now, so you're going to need to at least meet that in total comp before I'll consider it."
The response is almost always something like "We're interested in programmers who are really passionate about Y and aren't primarily salary driven, so we only pay X/2 here."
"Hi we're looking for a python/clojure/go/dart/react senior developer. We need 5 years of experience and a college degree in CS"
"I have none of those but forward my resume if you think I'd be a good fit"
"Alright, I'll get your resume over to them ASAP!"
Several days later
"Sorry, they said you wouldn't be a good fit"
No fucking shit, I am shocked
Tbh, most people dont even need an expert or senior developer. Unless you are expected to pick up everything within 1 week, its easy enough to learn a language or reverse engineer old code with enough time.
I find this the most annoying thing in programming. Does HR not realize that once you can program, you can program?
You usually have a senior person (or a few) that knows everything and calls the shots anyway.
Heck, even when I had to pick up the pieces of a mess, I found the code easy enough to pick up.
Btw I think frameworks are a far bigger deal than a language. Languages look similar enough and it seems like the biggest challenge is using libraries.
FFFFFFFFFFFFFFFFFFFFFF
Well, in their defense, they're almost definitely recruiting for an organization that doesn't, so it would almost be dishonest if they themselves presented a facade of caring much one way or the other beyond their own quarterly sales commissions.
What a crock of sh*t!! This is what happens when you pack HR departments with humanities and gender studies majors.
Personally I do not read any resumes, all the hiring I've done was either by referral or through online websites like angelList.
This is my process:
- Check your linkedIn, look at your experience and education. Catchy schools and companies is good BUT also that you are not a branch hopper (2 months there, 3 moths here etc)
- Check your github for samples of your code and your work ethic. (If you don't know proper git branch management you are no good to us). Opensource contributions are a major +++
- Check your StackOverflow to see how good a communicator you are (best engineers are the best teachers)
- Don't bother with social media .. unless I am looking for a good excuse not to hire you.
If you don't have any of the above, I will not even spend 10 seconds on you.
Also, what is "office hours"? We are plugged in 24/7.
The candidate, for example, could just walk out of the interview and go for a beer, while the hiring manager could get on with the business of finding a gullible new grad to hire.
>"Check your linkedIn, look at your experience and education. Catchy schools and companies is good BUT also that you are not a branch hopper"
So... you read resumes?
On LinkedIn they are less likely to make stuff up. The public nature of the process keeps people a bit more honest.
So yes, if I get a .pdf/.txt/.word/etc resume emailed to me I will not read it.
You'd be surprised how many engineers actually find that approach a breath of fresh air in this age of diversity and inclusivity.
Wow! Refreshing.
There may not be a great solution to this problem from an applicant's perspective (because if you fail to impress the recruiter, you may forfeit the opportunity to impress a manager in subsequent practice). Still, it's worth keeping in mind, not least because your ultimate success at the company depends more on what happens after the hire than before.
> Watch for spelling and grammar. [..] After conducting my own A/B tests on this matter, the data showed that candidates who had untidy resumes faired less (sic!) than those with well written ones.
Edit: I was going to write a longer post about what I am more interested in seeing as an engineer who does the interviewing. But most of it was obvious stuff. Instead, here's what I don't look at:
- What libraries you used. Languages, maybe -- libraries? If you're past junior level, I expect you'll be able to pick up a complex one, in a field you're familiar with, in a week or two.
- Length of past tenures. I gave favourable feedback for a lot of kids who, early in their careers, left from two or three jobs in a row because they were hired by large companies who then proceeded to give them completely uninteresting work that was entirely below their programming skills, without any mentoring, any meaningful source of professional growth and any timeframe for when they'll get to do some actual programming. I'm talking kids who, fresh out of school, could write a decent kernel driver, but were asked to write automated tests for REST APIs. I was never wrong about this.
- Hackatons, coding competitions and the like. The former are entirely unverifiable. I've seen plenty of people claiming they went to this hackathon and wrote this application that could potentially solve the problem of water crisis in Africa, using advanced GIS algorithms and numerical optimization and machine learning and whatnot. One of them even showed me the app on their phone. Then they don't know how to iterate through a list or find the race condition in three lines of code which contain literally nothing but a function name, an initialization, and a race condition. Copy-pasting from Stack Overflow is a useful skill to have when it sits on top of other skills. The latter tend to be completely unrelated to programming in the real world.
- The length of the resume. If you have enough relevant experience to fill four pages of resume, then write four damn pages of resume. A one-page resume that drops three pages of relevant stuff will put you in the same basket as someone who can barely fill that page. It's not ballast, it's stuff I can ask you about in an interview.
- Layout creativity, cleanliness, typography, visual identity and the like. Pick a CV template for Word (or, if you want me to instantly like you, LaTeX). This is Andrew S. Tanenbaum's resume: https://www.cs.vu.nl/~ast/home/cv.pdf . When you can sport one that's more impressive than his in terms of content, look into making it pretty, too.
Being able to write really well can also make you stand out and do wonders for your career, especially if everyone else on the team is likewise a high performer (Jeff Dean style). The best people I've worked with have also all been really nice and kind to a fault.
The part I quoted is representative of the recruiting industry because it has a spelling mistake. It's "fared", not "faired", and unless "fared less" is some strange idiom that I'm not familiar with (I'm not a native English speaker, and I'm more familiar with British English than with American English), I could swear it's fared worse (or less well, if you must).
This is... very representative of the recruiting industry, in my experience.
To me 4 pages is a CV not a resume. You might prefer 4 pages, but in my experience most people won't bother reading past the first page.
Those people should not be involved in hiring. I know it sucks to read page after page of seemingly irrelevant stuff until you find that one good candidate, but that's literally your job. Complain all you want, then do it. I, too, hate dealing with poor code from irresponsible vendors, undocumented libraries or legacy applications, but I don't stop reading past the second file of source code.
My point was that those kind of people are involved in hiring, and the single page resume has become fairly standard.
You personally may prefer a longer academic CV style. I think that probably makes sense, if anyone profession could use that type of resume it's ours.
However, that isn't currently the norm, and I suspect that you'd see a net loss if you always sent out a 4 page resume instead of condensing it to single page of bullet points.
I will say that I could be completely wrong on this. It could be that the increased interest from people who want 4 page resumes might more than make up for the people who won't bother reading it, but I don't think so.
On one of the first calls I had, the recruiter heavily implied that I was “not a culture fit” after I explained that I’m only interested in a job if it pays more than I currently make consulting (this particular job paid about half that). I’m not socially inept, I know how to speak politely and it was definitely polite. I mentioned it on the first call because I didn’t want to waste anyone’s time (mine included) interviewing for a job that I wouldn’t take.
The HR lady seemed completely taken aback and offended... says “we’re looking for people passionate about the problems we’re solving, even if it means taking a pay cut.”
Get the f- out of here with that BS. That really grinds my gears. The company is allowed to be profit seeking but the employees are not? No thanks.
I’ll stick with consulting... I like having multiple clients over one employer. I like that there are no “interviews,” just my own confidence and sales skills to pitch proposals to clients. I like the respect that clients show me that no employer ever has. I like the autonomy, the lifestyle. And yes I like getting paid more than I would at a local job. There’s nothing wrong with that.
* If you have sales/negotiation skills, but no technical skills, you do sales/HR/whatnot.
* If you have both sales/negotiation AND technical skills, you do consulting or start your own business.
* If you have good technical skills, but poor negotiation skills, you go work as a software developer.
So yeah, an unwritten requirement for many technical positions is having poor negotiation skills. And no recruiter will obviously tell you outright that "you know, we're just looking for a sucker to take a crappy deal and you don't look like one, so move on", so instead they will use the politically correct "culture fit" to make themselves feel better.
Regarding negotiation for engineers-- a few years back, I had been happily employed at a company for ten years. The CEO of some company calls me up and says I'd be PERFECT for a job opening he has. He says its C2H for 6 months to make sure I'm a good "culture fit". I politely decline, and he was incensed.
I said, "Why in gods name would I leave a position I've been in for 10 years for a contract position?"
I agree the comments on salary are ridiculous, but the last paragraph implies heavily that you are not actually a "good culture fit" for a non-consulting job.
We want people smart enough to program but not smart enough to think about compensation, in other words. I think there was a Dilbert about that!
Yep, thats a one way ticket to not having quality employees.
If I really want to solve those problems, I'm probably only going to trust myself to solve it.
FYI, you can always make more as a consultant if you don't count cost of medical care, taxes, etc.
Maybe I'm the weird one, I have met a couple programmers at the bar too, but its just not as fun as meeting someone whose life revolves around making chocolate for a living as an example.
If that makes me a poor cultural match, good. I can't be that insular. I don't want to join a cult when I join a job.
I always laugh when a recruiter reaches out looking for people and asking if I know of anyone. LOL! No, all the ones I know I currently work with, and I try not to know them past that.
> I don't want to join a cult when I join a job.
My feelings precisely.
I love how they get snippy when you tell them you don't know anyone. "Well! I guess EVERYONE you know already has a job!"
Sarah Arcoleo - "It’s important to me and our whole team that we are bringing on new team members who align to our company culture and values."
Roses are red, Violets are blue, I need a job, You're hiring, right?
Codes in whatever language
Works for market rates
No technical interview question I've ever been asked has anything to do with "self awareness" as Tammy pointed out. In fact self-awareness for the hyper-productive is a negative for the organization, as that individual eventually realizes they deserve a significant share of what they create and aren't getting it.
So the other way around: I would love to see tech recruiters with actual technical understanding.
> Greg Banks: Recruiting Manager at Digit, previously a technical recruiter at CourseHero.
> Lana Herzig: Technical Recruiter at Dia&Co, previously at Quartet.