If someone has insight into recruiting, can you explain why contacts sound like sales pitches with vague language?
“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?
Sales funnel + psychology. Imagine you are using PHP4 and, 100 candidates out of your pool will totally hate it. As You know that in a face-to-face talk you have about a 10% chance to convince a PHP4 hater to still go ahead and take the offer. Now consider 2 strategies:
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.
You're giving these recruiters too much credit on their intelligence. They're vuage because they're ignorant and need to reach a certain word count to their pitch, and the same way they need to get a certain number of submissions. In short they're like monkeys incentivized is to give the minimum amount of vuage info in the shortest amount of time until the candidate agrees to continue with submission.
I think you radically over-estimate the number of people who want to learn Elm in order to apply for a job.
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.
We had a problem advertising Clojure, everyone showed up wanting to write Clojure but didn’t care about our product.
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.
Not really, because most companies will ignore those without Elm repositories on github.
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.
Source: I'm an engineer & recruiter that works with over 100 tech companies in NYC. I also work on a SaaS platform for 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.
> concrete information (tasks, location, level, tech/tools, salary, business sector, team size...).
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.
Partially, this is based on a disconnect between engineering and hiring. For example, the people who are writing the job descriptions got a 1-line email, "We need to expand the engineering team; could you take care of it? Thanks!", and so they're basically having to come up with all this on their own.
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).
> Partially, this is based on a disconnect between engineering and hiring. For example, the people who are writing the job descriptions got a 1-line email, "We need to expand the engineering team; could you take care of it? Thanks!", and so they're basically having to come up with all this on their own.
And to think that hiring will have one of biggest impact on the engineering team.
> Partially, this is based on a disconnect between engineering and hiring.
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.
at larger companies you often have recruiters focused on specific areas - so they can know more. At places I've worked we've had just an engineering recruiter and just a sales recruiter and etc...
I feel like this isn't often the case. In multiple teams I've been on - the team wrote their own job descriptions and even revised them multiple times.
- 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.
Had to nitpick on the monospaced font line. Proportional type preserves the shape of words which is a huge part of readability. I don't think I'd take a resume that looks like it was written in a code editor as a positive signal.
It's his fantasy world, so who are we to judge. As a gimmick I could appreciate and would definitely notice a resume printed with a dot matrix printer on pinfeed paper using Courier. But I would recommend everyone to just stick with a nice serif typeface.
I disagree. I used to be this gripe-y person, but the more experience I gained, the more I realized that everything is just the result of its trade-offs and started finding the griping both boring - who wants to complain constantly for years and years? - and less productive than maintaining more of an anthropologist's mindset.
So to me, constant griping is more of a not-that-much-experience signal.
This is the most important question I ask in every interview. The goal isn't to get someone to piss and moan about every little thing, it's to see if they can identify any downsides to the tech they use. IME >80% of candidates have never even thought about it, treat every tool/dependency as free, and whatever tech they happen to use was written by the second coming of tech Jesus and contains no faults.
Fair enough. Perhaps I have a blind spot due to always having been the opposite kind of person. But I dunno, I'm not sure I've ever run into one of these "second coming of tech Jesus" types of candidates. Maybe that sort of perspective is more common in the bay area? I definitely sense a bit less ... cautious skepticism when I talk with silicon valley type folks.
It's a great direct question. However, what I read was that this person asks candidates broadly about X technology and expects them to divine the knowledge that they need to start complaining about X if they want a job.
When a job interviewer asks about X technology, often they actually _want_ to see you hedge your bets. They think of this in terms of you understanding both the upsides and the downsides of technology (and business) decisions.
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.
Agreed, I wouldn't want continual moaning, I'd like to hear about the problems they experienced, and have the knowledge that on a different platform/framework that would be better, but you'd give up something.
I agree, I think it's better to ask what some of those trade offs are. What's this tech good or bad at? I'm not gonna complain about a language feature that I can't do anything about. I'm gonna implement the work around and move on. What's the point in sitting around and complaining? I can't alter the language itself and it would be unreasonable to change the project language past a certain point.
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.
Most of us aren't on the cutting edge of technology. I've personally never worked on a team whose biggest problem was a lack of technical prowess, the problems are always social/cultural.
If I'm being frank, then you need to be up front about that in the job posting. "Cultural fit" and other PC BS won't cut it - be honest about what you need.
"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.
I've written and deleted this message a dozen times trying to get it right without it coming off as an attack. I hope you won't take it that way because I'm genuinely trying to be helpful. The way you parse "Looking for a JavaScript, Typescript, Angular, React, Node.js, Mongo, and BerkleyDB rockstar." sounds like the way I would expect an autistic person to parse it, too literally. Every job everywhere has an implied requirement that you will be able to communicate and work effectively alongside other humans. Since it's a requirement everywhere, hardly anyone will list it explicitly.
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."
Your point would be made just as well if not better with the first paragraph elided entirely. In general when you rewrite something so many times, it means you should say less
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.
> Every job everywhere has an implied requirement that you will be able to communicate and work effectively alongside other humans. Since it's a requirement everywhere, hardly anyone will list it explicitly.
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."
Considering how many of their target audience will parse it too literally, perhaps it is the message that is wrong. It's not purely on us to learn to communicate, the business and recruiters must learn to communicate with us as well.
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).
I'm confused by which side you're comparing to the bit in your last sentence to. All they did was fit in and talk? That's not enough.
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.
There's this one recruiter company that calls me up every six months or so.
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. :-)
Probably because recruiting is a crapshoot numbers game. Emailing massive numbers of people is easy. They have pre-written templates, so the marginal time spent is minimal. Forwarding resumes along is easy as heck too. But customizing someone's entire resume? That doesn't scale. They would have to... you know... actually value you.
Because you're not compliant, and a compliant candidate is easier for them to place. If you won't reformat your resume to look like pretty much everyone else's, how can they count on you to take a bunch of pointless phone calls for positions that may only vaguely match your skillset in the hopes that one is a match and they get their blood money?
Of course, just throwing TeX at your resume isn't enough. However, TeX gives you tools at an engineer's level which can be used to make your resume stand out.
It's a very good recommendation. Simply being aware that TeX/LaTeX is a thing (it's very recognizable) is something that I tend to appreciate in an engineer.
> they would gripe about that technology all day long; if they can't complain about its shortcomings and pitfalls, they didn't use it.
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.
A question that I've been using lately is to ask a candidate to pick some technology (anything) that they have strong feelings about - positive or negative. I'll then throw out a couple of examples: "I really like A about B thing" and "In language X I really dislike Y because Z" -- I'm looking to see that they've really thought critically about some technology. Anything.
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.
Every technology is designed through tradeoffs. Choosing a technology and the using it properly reqires understanding those tradeoffs. What they are, why they were made. I whine about the appetite for secret allocation that my C# program has. I whine about the mess that is writing the equivalent C++ or Go code, and the learning curve of doing it in Rust.
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 see where you're coming from. I think I just don't like the "complain about it" angle.
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 had a similar experience, and at an engineering university no less. The career center was very good if you were a mech/civil/elec engineer wanting to work for a big co, which was maybe 70-80% of undergrads, but that wasn't me. Very glad I turned down almost all their advice and stuck to my LaTeX resume.
I think EQ is incredibly important to engineers or to anyone who is working in a team and "EQ" or put more casually, is this person a self aware, nice person that can work well with other people, is absolutely something I care about in hiring.
I've received a fair number of job offers over the years with a resume that I forward to people as emidln_at_gmail_dot_com_Brandon_Adams_resume.txt. I do work in various development/programming/sysadmin roles. If someone requests html, word, or pdf I just convert it for them.
My current resume has approximately 6 different fonts, left and right justified fields, bullet points, and tables just so it looks just good enough to get past the HR drones (many of whom are wonderful people despite being a resume gatekeeper).
It was an agonizing process, but the end result is something that recruiters recognize as being well designed. I hate having to maintain it.
Mines is just literally a list of techs categorised by bulletpoints under a job without any context. It doesn't look terrible, but it was hardly really well designed.
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.
It's what was needed. And my use of the word fonts is a bit incorrect, it was a total of 6 different font faces (bold, italics, different sizes, different fonts). Sorry about that.
- 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.
You were right the first time. In typesetting, A typeface is a family of fonts, and a font is a weight and set of variations (and size, too, before digital).
> It may seem like common sense, but having a deep, enthusiastic, and genuine interest in some aspect of the company (whether it’s the company’s mission, product, technical challenges, or its work environment) is important.
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.
It is frustrating. I emphasise passion relatively little in my own interviewing process, but others in the firm can't quite get over the desire to do a "one last check" sort of interview. I don't stop them because, well, the harsh reality is that passion does help.
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.
I notice that you focused in on my carpentry example, and ignored the industrial design one completely. Do you think ID is perfectly hierarchical, and doesn't involve changes to blueprints, and never looks like goofing off?
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.
Your industrial design example was an anecdote. There are people who work for me who aren't passionate about the specific area we work in, they just like writing software. You seem to think passion is literally a job requirement, but I've never seen that. Employers like to see interest and keenness but they do hire people who don't have it, of course.
The way I think of it is that we haven't yet figured out concrete ways to assess whether someone can or can't be an effective developer on a team. So if you want me to hire you, and I can't directly measure your skills (because I'm a suboptimal interviewer?), then I need data points that increase my confidence that you are more likely to work out.
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.
I agree wholeheartedly with your first paragraph! As an industry, we still don't have the first clue how to hire. It's not just you.
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!"
> 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.
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.
Great point. The word "science" appears in the name of the field that I studied, yet I haven't seen any evidence that our current hiring processes in this field are better than random (i.e., the null hypothesis).
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?
I'm imagining an overly academic interview question that goes something like this...
"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."
> 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.
Do you ever worry that you’re overlooking talented people who have a life outside of programming?
It wasn't a great example, and I don't manage a team, or work at a Microsoft shop. I think I was trying to say it's easier to avoid making bad hiring decisions than it is to work on making good hiring decisions. It's probably also hard to practice hiring decisions at all, which doesn't help in reducing the learning curve.
>> you're searching for people with passion so you can get them to work unpaid overtime for you
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.
"'people with passion' will be less impacted by the unavoidable organizational BS"
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).
> 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.
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.
> 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.
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
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
This is how you know your skills are no longer in high-demand. When employers want to select for ridiculous crap like that or use vague reasons for denying an applicant like “cultural fit” it’s because they have way too many qualified applicants.
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).
TBH I have never been impressed by any technical recruiter I've met.
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.
TBH I have never been impressed by any technical recruiter I've met.
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).
It's perception. They network, get lucky sometimes, and don't stop preaching about it until everyone around starts believing they're valuable authorities in their profession. Snow ball rolls from there and they start attracting candidates based on perceived connection to the top company/people/teams.
The $300K/yr. recruiters I'm thinking of are not people who have some out-sized reputation, at least not as far as I'm aware -- I think the economics of the business simply allow them to make a lot of money if they can regularly place a small number of candidates each month -- see my reply below to another comment about how I figure that might work.
*
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 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.
I mean, when NodeJS first came out, I thought it was a joke too :p
JS on the server-side is actually pretty old; Netscape implemented it on their web server way back in '95, right after the language was released on their browser.
I had a recruiter insist on Rails 5 experience, at the end of last year. Rails 5 had been out for less than a year.
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've had many insist on knowing how much experience I have with HTML 5, as though my previous experience with HTML 4 has no relevance. I don't know why the talk about HTML at all, a half decent programmer that's never done web development could learn all they need to know about HTML in a day.
I fired one of my biggest clients because they appointed an HR manager who cared most about things like whether or not the career history timeline perfectly lined up and left nothing unaccounted for - like really cared - would knock someone back after 3 tech interviews if there was a glitch in the resume.
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.
>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.
Hate that. Worst is "here is my salary range, does that work for you?" and than they say "lets have you interview first, and see if it's a good fit." - after interview "our max salary for engineers is 60% of your current pay and our benefits suck - but we have free soda and chips!"... thanks for wasting my time.
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"?
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.
I'm surprised I didn't find this higher up the thread: I'm soooooo sick of people hiring based on languages. It's right there in the first response in this article: "make sure you’ve included the same language as the job description if at all possible". This is so ridiculous. Either you're hiring a junior person and you're going to have to invest in ramping them up anyway, or you're hiring a senior person who will quickly figure out whatever language you use.
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.
> 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?
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.
I see that what I said wasn't clear at all: I meant the specific kind of lead who will be setting everything up, ie. on a greenfield project. I think a lead on an established project falls into the camp of experienced people who can figure things out.
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.
Completely agree with the point about not hiring based on specific language experience, but I took the phrase "make sure you’ve included the same language as the job description if at all possible" to mean "use similar terms and phrasing as those used in the job description." I think in that context, the advice can be helpful.
Interesting. Now I truly have no idea what the actual meaning of that sentence is. I still read it as talking about programming language, but your interpretation seems at least plausible.
Crooters never seem to be asking a whole lot, as they always seem to think I'm a "great fit" for any company currently waving money under their nose. Of course it usually takes some prodding to discover that the crooter actually knows nothing about my background, is ill qualified to determine who is a fit, and I wouldn't want to work for their client anyway.
To be completely honest, I also felt a lot of frustration towards recruiters when I first started working on Key Values. (It might be one of the reasons why I built it...)
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
It is basically impossible to get enough information on a company in order to know and understand it prior to working there. Most company web sites provide zero information on org charts, work processes, communication flows, etc. It is very unusual for a company to provide any information during on-site interviews of how the company actually works. And any information that is given usually conflicts with other information provided later by another employee :)
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.
I don't think many candidates tell the recruiter they're working with to be less greedy, nor do many employers tell candidates this. My point is that there's an extremely wide range of scenarios that both parties see, and most people on one side of it have a hard time considering the perspective of the other.
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.
>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.)
If they're choosing between working at a company like Google or that startup, it's not greedy to expect competitive compensation.
I think it was implied by context that they weren't. Obviously if you need advice of "don't be greedy" then such a person isn't simultaneously weighing up an offer from the top of Google's pay tier, otherwise that wouldn't be greed, it'd just be realism.
I don't think that was implied by the context at all.
>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."
I'm not assuming that all "by pointing out that they can make more money elsewhere". In this case I'm talking about someone who can make more money elsewhere.
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."
>we're looking for a python/clojure/go/dart/react senior developer
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?
HR first and foremost needs to justify their own existence to the company they work for. And the easiest way of doing that is basically showing how they look through hundreds of candidates only to find those rare ones with the correct buzzword in the CV.
What makes you think it's HR with those absurd requirements? Some places have very rigid tech stacks and aren't interested in new hires taking even a short amount of time to learn the basics of a new language or framework. (I wouldn't necessarily want to work at such a place, just saying they exist.)
Yes this is fair, I just havent seen any occasions where this was necessary.
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.
Even better is when they try to forward your resume and come back with "Sorry, but the manager wants X years of experience that they didn't list in the job description for whatever reason".
You're thinking of "professional recruiters". The ones listed here are just the technical hiring managers at their companies saying what they look for.
> recruiters should actually start giving a shit about the lives of engineers
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.
I worked with a recruiter once and the way she treated me like an object to sling around to make her commission turned me off to the entire recruiting industry. I refuse to work with them again.
That happened to me when I went for a job at Wang to work on Australia's EFTPOS network. The position required using protocol analysers but the recruiter had removed all references to them from my résumé. I gave the interviewer my original résumé and got the job.
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.
Meaningfull github profile AND stack overflow profile AND able to do full time job?! I understand you pay people to work on their GH and SO reputation during office hours?
Yes and No. A great GH and SO reputation is something you build over a period of time. It shows passion and consistency. That's what separates people who love to code from the ones who just want the paycheck.
Also, what is "office hours"? We are plugged in 24/7.
If only all hiring managers were this honest during the process, everyone would be better off.
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.
It is different. An applicant is free to put whatever they want on a resume and I will have no way of verifying it without devoting a ton of time to the process.
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.
Well I'm not running for a popularity contest. A players like to work with other A players. My jobs is to make sure we maintain that environment. If that means being very selective and exclusive and hire based on merit only then so be it.
You'd be surprised how many engineers actually find that approach a breath of fresh air in this age of diversity and inclusivity.
Note that what "technical recruiters" want is not guaranteed to match what the hiring firms themselves want.
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.
I was going to write a long and detailed post about how so many of these things are so very wrong from a technical standpoint, but basically, let me sum up the recruiting industry in a single quote from this material:
> 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.
As someone who has done a lot of hiring, I've observed a strong correlation between spelling/grammar and the best programmers I've worked with. Details matter, and by failing to even read over your own submission you're showing you don't care about such details. Your commit messages and code isn't likely to impress anyone either.
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.
I absolutely agree. Every single good programmer I know is also exceptionally adept at written communication (and, indeed, really nice). They tend to be good at oral communication, too, but it's a little hard to get an accurate reading of that in an interview.
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.
>sume, 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.
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.
> 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.
Since I love your post, I want to tack one more thing to the bottom of it: please, for the love of all things holy, don't split out "key projects" and skills from your employment experience section. If I can't easily scan your resume and tell what you did where, it's useless to me and I will almost always bin you. This seems to happen more with candidates who aren't in purely technical roles, but it's infuriating.
I'm surprised none of them mentioned the abominable "culture match". I've heard repeated complaints that it's much more important to be a brogrammer who likes craft beers, than it is to be any good at the actual programming.
I’ve been consulting the past year and a half. Recently I decided to contact some companies just to see what the landscape was like, and if I could maybe find an interesting opportunity that also paid well.
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 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 autonomy, the lifestyle."
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.
Yeah, no disagreement there. Worth noting though, I didn’t mention anything about lifestyle / autonomy on the call. And if I did take a job I would adjust myself for that aspect of it. That’s one of the reasons why the pay needs to be good.
I am sooo glad I've not encountered this. When I go drinking I tend to accumulate drinking buddies that are entirely outside of programming. Lawyers, skater bros, confectioners, people that know way too much about the chemistry of post it notes (true story) I love tech and all, but, when I'm out drinking its more fun asking people what they do and just getting out of the stupid tech scene in general.
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.
Agreed, I don't find myself wanting to be around people like that outside of work. They're... kinda boring.
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 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 love how they get snippy when you tell them you don't know anyone. "Well! I guess EVERYONE you know already has a job!"
It's possible this is because of the context. All of these recruiters/talent managers are from companies who have engineering profiles on Key Values. Their team has already spent a lot of time articulating what their engineering values are with the hope of connecting with engineers who share them.
These are all half-truths meant to avoid the real answer. They want high IQ ambitious people who don't suffer from mental illness. They will put you through strenuous interview processes as a makeshift filter for high IQ.
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.
“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?