Last week I published The Worst Developer Résumé in the World, which resulted in three things.
- We are not alone – The article resonated with many hiring managers and recruiters who immediately recognized this style of résumé. We’re forming a support group.
- RIP Inbox – Readers wondered “Is that my résumé?“, with many reaching out to me or my résumé review/writing side project (Résumé Raiders – shameless plug) for a personal inspection. Some résumés were good. I had to open some reviews with “Are you sitting down? Because you might want to sit down…“.
- Thanks…but where is the rest?– A handul of readers asked for details on best practices and tips for résumé writing. “You told us what not to do, now tell us what to do.” OK, I’ll do that.
WARNING: Keep in mind that entire books have been written on résumé writing, which I’m also considering as a future project. I dedicated a full 20 page chapter to résumés in my 2013 ebook, so a few hundred words is only going to scratch the surface of what it takes to craft a résumé that gets results (interviews).
That said, here are some best practices for a good résumé.
A Short, Detailed Summary or Profile
In my opinion, this is the most important piece of a résumé and the section most often overlooked by job seekers.
Why? There are two simple reasons you need a good Summary.
1. Your résumé’s audience. We must assume a human will read your résumé at some point, and we (unfortunately) must also assume that the human is not highly-qualified to assess your background. At many companies the reader will be an HR or recruiting professional who may know little about technology. Startups too small to have dedicated recruiting/HR personnel use administrative or operations staff to review incoming résumés, as dev time is too valuable.
Do you want to miss out on a great job because the résumé screener was an accountant unable to decipher that you have the required five years of Python experience? Or because the reader didn’t understand that the “J” in J2EE is Java? Make it easy for them, which in turnbenefits you.
2. It may be all you need. A well-written Summary can be the only thing a reviewer needs to read before passing your résumé to the next step. In those rare instances where I receive a résumé leading off with a descriptive Summary that includes the skills and experience level we are seeking, I can immediately reply “I like your background. Let’s talk!“. I’ll read the full résumé later as I prepare for our phone conversation, but the powerful Summary got an immediate “Yes” answer from me. The résumé’s purpose is to try and start a conversation, and a Summary alone can do that.
How? A Summary should be written in a way that leaves the reader little room to misinterpret who you are and what you can do/have done. It should be no more than a few sentences. The biggest Summary mistakes, which were detailed in the previous post, are ones that go way too long (and cease to be summaries) or those that contain useless, homogenized, non-descript content.
A Summary that reads “Passionate software engineer with excellent communication / interpersonal skills dedicated to writing elegant code” sounds nice and might be someone I want to talk to, but says nothing about qualifications. Does this Summary make it any easier for the reader to say “yes” to you? No, it doesn’t.
A quick aside: And while we’re talking about self-assessments of communication skills and interpersonal skills on résumés, do you think any hiring manager in history has said, “Did you see this résumé Frank? Says here that Ms. Thomas has excellent communication skills. VERRRRRY INTERESTING… Get her in for an interview at once!” No. Don’t waste this space with self-assessments that every résumé on earth also uses. Show me (don’t tell me) your written communication skills by writing a decent résumé, and we’ll cover speaking in an interview.
Back to the story…
If you’re thinking “but DAVE, the job spec listed like 50 languages and tools”, let me stop you there. The Summary isn’t the place to test out your ATS-gaming SEO skills. It’s an overview, like a quick plot synopsis for a movie on IMDB. It’s not meant to give every detail and spoiler.
Realistic Skills in a Digestible Format
Why? Long laundry lists of skills gives the reader a few impressions of the applicant. First, we hear the theme song to our favorite game show – let’s play Buzzword Bingo, Résumé Edition!
Recruiters are often accused of just matching keywords, which is a fair assessment at least for the minimum requirements of an initial résumé screening. Development managers are likely to start with the same method. A suitable candidate needs relevant skills and accomplishments. Has this candidate done anything relevant to our job opening? That determination entails scanning for certain required technologies, experiences, etc.
A long list raises the question as to how much the candidate actually knows these technologies. The barometer for experienced professionals is usually to include something you’ve used (at home or work) enough to answer some questions. When someone posts what is likely an impossible list, the reader may get a sense of some dishonesty which could be verified in a conversation.
The digestible format is also important. If recruiters are playing Buzzword Bingo, they need to know which columns and rows to look in to find their desired words. Again, make it easy for the recruiter in order to maximize your own positive outcomes.
How? Keep the list to a reasonable size based on your overall experience, and remember that listing outdated skills may do more harm than good. If you are now doing Go and Node.js work, listing all the technologies from your days cranking on AS400s might not be a good use of space. You don’t need to be an expert to list something, but show some restraint.
Separate the skills into a few sections. Common categories might be Languages and Platforms, Frameworks, Databases, Operating Systems, and perhaps a catchall like Tools orOther. If you find yourself creating categories for just one or two skill listings (e.g. IDEs: Eclipse, NetBeans), you run the risk of adding unnecessary length to the document and might be better served with using an Other section.
Clearly List and Bullet Accomplishments, Ideally Quantified
Many résumés use the Experience section to bullet multiple responsibilities instead of detailing specific accomplishments. It’s not always easy to point to accomplishments, but it’s important to try.
Why? The reader wants to know what you have done, that you can communicate what you have done, and (most importantly to some managers) that you understand how your accomplishments positively impacted the business. Writing about accomplishments also gives you the opportunity to influence your interview, as projects that are on the résumé are infinitely more likely to be discussed than projects you don’t list.
How? It’s best to list responsibilities before accomplishments, with the responsibilities written in paragraph form and accomplishments bulleted. Just below the employer, title, and dates, you’ll have a few sentences you may use to describe the company’s business (if unknown to most) and how your role helps the business (usually entails either saving the company’s money or making the company money).
Bulleted accomplishments should list your role, some details on the technology used to solve the problem, and outcomes. Quantifying details such as dollars saved, revenue generated, or performance improvement metrics are a nice touch when possible. Accomplishments can be both individual or as part of a team, and it’s important to differentiate so you don’t accidentally claim too much credit.
Trim the Fat, and Optimize For Relevance
Why? There are a few reasons for résumés to be kept as short as possible while still covering the necessary content. First is the signal-to-noise problem, where relevant and impressive accomplishments get lost in a sea of useless bullets. Second, a long résumé intimidates a reader, which is another reason for a lazy recruiter to hit delete. When you see a résumé is seven pages, you may look for reasons to stop reading it on page one or two. Lastly, a long résumé with irrelvant content makes it appear that the writer is overestimating the value of a past accomplishment. Hiring managers mostly want to know what you can do today, not what you did in the 90’s.
How? Most of us can safely eliminate details on jobs from 10+ years ago, as they are usually less relevant to today’s work. Your job title and employer for early jobs is enough to give you credit for the experience without giving the reader the impression that you are clinging to accomplishments that are now distant objects in your rear-view mirror.
Some other quick tips that didn’t warrant full sections:
- Email handles shouldn’t sound like they were created by a teenager, and AOL addresses aren’t retro cool (yet). If you need to ask, you should change it.
- Contact info eats up valuable page space if you stack it (name above address abovephone above email), and it’s the least important thing on the document that ironically gets the most prime real estate. Use a small font (like even 6 or 8) and try to keep all of this to a line or two at most.
- Personal web pages, blogs, GitHub, and LinkedIn links are nice to have if they are neat. Just remember that if it is listed, it’s fair game.
- Nobody cares what you got on your SAT/ACT tests 20 years ago. Same with college courses.
- If you decide to list non-industry positions, consider that the reader may have a hard time thinking of you as “Joe the DevOps engineer” instead of “Joe the former pizza delivery guy“. Most of us have had other jobs, but we don’t need to list full employment histories.
- Don’t list your references names or email addresses on your résumé, unless you want them to hate you. Some recruiters will try and recruit them even if that recruiter never spoke to you. Provide references when asked for them.
- Listing graduation dates gives away your age using the formula 22 + (CURRENT YEAR – GRADUATION YEAR) = CURRENT AGE. If you fear possible ageism, deleting graduation dates and removing your earliest experience is one way to prevent discrimination. It’s a résumé, not a full autobiography. In some countries it is popular to list birthdays and even photos on CV’s, but not in the US.
If you are in the technology industry and haven’t read the recent blog post RECONSIDER, you should. As I’m most interested in hiring-related issues in the industry, I’ll get to my point once we get through a bit of background.
In RECONSIDER, Basecamp founder and Rails creator DHH describes how the term startup is becoming synonymous with the unicorn phenomenon and the potential dangers of this intersection for entrepreneurs and the industry as a whole. He writes “nobody these days is content to merely put their dent in the universe. No, they have to f*&%ing own the universe.” Much of what is written about startups reflects the attitude DHH describes, and he asks readers to reconsider that there may be motivations beyond billion dollar valuations for starting a company.
DHH reports that he co-founded his company over ten years ago and they’ve grown to a modest 50 mostly remote employees without a presence in the Bay Area. Clearly Basecamp never fit the unicorn profile and their maturity may preclude them from being defined as a startup today, but it’s hard to say they haven’t been successful. Few get to commission a special edition race car. The path of Basecamp might not be what the stereotypical startup founder sets out to replicate, and DHH seems to wonder “Why not?“.
What’s a Startup?
One part of the problem is which definition of “startup” is used. Startup is popular shorthand for new and (usually) tech, but some definitions require ambition of fast growth. DHH writes that the term startup has been “narrowed to describe the pursuit of total business domination“. He leads off by identifying Basecamp as a startup upon its founding and later describes it as “a company that doesn’t even have a pretense of an ambition for Eating The World™”. If their intent was never for quick growth or (dare I say) “disruption”, Basecamp may meet DHH’s (and others) definition of startup but doesn’t really meet the definition used most famously by Paul Graham.
Being that there are companies self-identifying as startups of varied age/size/ambition, and some nuance as to how those within the industry define the term, there is opportunity for misinterpretation.
One issue that DHH doesn’t really touch upon is how the somewhat hijacked redefinition of the term startup impacts careers and hiring, or more accurately, how some job seekers may be averse to any company that describes itself as a startup.
Hiring and Stigma
The term startup alone may conjure images of programmers (probably young and male) logging 70 hour weeks for pay well below market salary, poor benefits, and insignificant amounts of equity. These images may be a holdover from the first dotcom boom if you’re over 35.
Startups in many markets across the US today may bear almost no resemblance to that image, and unfortunately thousands of firms need to overcome a stigma with job seekers due to the ubiquity of the meme. It is assumed by some that a startup in Philadelphia or Boulder, solely because of their self-identification as a startup, is likely to expect employees to accept significant cuts in compensation and benefits as well as increased hours. It’s this often false expectation that leads some to stop listening about potential new job opportunities once the word startup is introduced into conversation.
What if I told you there were many fairly new and relatively small software firms solving complex problems that pay engineers at or above market rates, offer work/life balance, provide comprehensive benefits, grant options, promote diverse work environments, and never describe themselves as “we’re like $UNICORN for $PROBLEM“? Because of the popular startup stereotypes, I often feel obligated to lead off conversations by defensively telling candidates about a company’s highly-realistic hours expectations and competitive salaries before describing the interesting technical challenges that should be the focus of the conversation.
RECONSIDER hopefully has shined a light on the fact that there may be thousands of startups like Basecamp that never get huge (perhaps never sought to get huge), yet still created great products that impacted users’ lives while providing opportunities and financial stability for both employees and founders alike. Maybe these are the real unicorns.
As someone who has been recruiting in the software industry for nearly 20 years, I’ve read perhaps tens of thousands of résumés. Good and bad. My experience prompted me to launch a part-time résumé review and writing business (Résumé Raiders if you must know), as I found that résumé services were both grossly overpriced and of poor quality.
There is one résumé type that I get at least once a day, and it’s unreadable. It is immediately recognizable once I open the document and see the first page, and my suspicions are confirmed when my eyes wander to the bottom and see the dreaded “Page 1 of 7”.
I’m not sure as to why, but I belive this style is more common among Java developers – although admittedly my sample size for Java is larger than for other language communities.
It starts with a “summary”…
So the résumé’s summary is a half page long? The writer regurgitates every single technology they’ve ever used, puts them into bullet points, and has the audacity to call it a summary? This creates what we call a signal-to-noise problem, where the sheer volume of content makes it impossible for a reader to decipher what is important information and what is not.
I preach to all my résumé clients that a summary is the most important part. Why? Résumés are often initially reviewed by recruiters, many of whom are inexperienced and not the best at identifying talent. The summary is an opportunity to tell the reader exactly who you are without having to let the reader interpret your experience.
You want to hire a Python developer with at least five years of experience? If a summary starts with “Python Developer with five years of experience…”, that doesn’t give even the most incompetent recruiter the chance of missing the qualification. Keeping the summary clear and concise is the key.
So what’s next?
Thanks…but didn’t we just do this??? We’ve now read the first page of the résumé, and the applicant has mentioned every technical skill at least twice. I know what you’re thinking. This is an attempt to get the attention of those ATS’s (applicant tracking system) we keep hearing about. When it is assumed that the reader is not human, some may choose to repeat keywords in an SEO-like attempt to game the system. Does it work? Probably not, but I don’t think that is the reason behind this.
But let’s keep reading…
After starting off with a summary which was really a set of bulleted lists containing buzzwords, followed by a skills section which was just a categorized list of the same buzzwords, we come to the experience section which is the same list of buzzwords accompanied by a short description of what those buzzwords do.
There are a couple problems here.
The first is that the reader is looking to quickly qualify or disqualify an applicant. When the reader discovers that the résumé is seven pages that seems to mostly be lists of buzzwords, that doesn’t provide much incentive to read it. The size is intimidating to a reader, which gives a negative instinctual reaction. Imagine a friend is relocating and asks if you can help with the move, and on arrival you see a garage full of barbells and bags of sand.
Even if it’s part of the recruiter’s job to review résumés and make a yes/no decision, this style résumé is a lazy excuse to just say “no”.
The biggest problem, for both the applicants and the industry at large, is that these résumés sometimes belong to good developers. I’m a strong résumé writer but a weak coder, and there are likely thousands of people who are strong coders that have no idea about résumés.
If your résumé bears any resemblance to what I’ve described above, do yourself a favor and fix it ASAP.
I have spent many hours discussing and writing about how résumés are written, but I’ve never shared much regarding the way résumés are read. I’ve reviewed thousands of résumés, and my process has changed with the times. The description here describes how I read a résumé upon arrival in my inbox, with the only decision being whether I will schedule an initial conversation (with me).
Disclaimer: This is not meant to be a piece on résumés as a hiring tool. I hope to provide insight regarding details that trigger responses in an agency recruiter’s mind. I try to err on the side of “let’s talk” and not “no thanks”.
Keep in mind that (as an agency recruiter) my goal is to first determine whether my client would interview, and to potentially save everyone’s time (client, candidate, me). I’m looking for some number of positives where I’m convinced that we should speak, or a combination of negative flags that make it apparent that an interview (much less a hire) is unlikely. Technology has provided candidates the ability to shotgun résumés even when they are grossly unqualified/overqualified or would almost certainly not accept the job if offered.
The top of most résumés I see:
Location The only data point I retain on the first pass is location. Remember that I have to consider whether my client’s offer would even be entertained, which location can influence. Even if a candidate is not local, I continue reading.
A non-local location becomes a possible flag if the candidate seems rooted in their home city. If Jane’s résumé shows that she has worked in San Francisco for 15 years, the likelihood of a move to my client’s city should be lower. Assuming Jane later appears qualified, I would want to inquire about her thoughts on relocation before potentially getting too far along. Maybe she has a move planned already.
Email/Domain For certain positions I will visit a candidate’s domain to see if there are any items (work samples, technical blog posts) that might reveal something worth highlighting to my client.
GitHub I don’t read code, and I don’t click GitHub links on the first pass. Generally I won’t bother clicking it at all unless the experience section is lacking, in which case I check for personal projects or activity that might help get the candidate in the door.
LinkedIn Again, I don’t click it on the first pass. If I have difficulty understanding any of the résumé material or career history I may visit their LinkedIn for possible clarification.
What follows that top section varies, but I hope for a profile/summary:
Summary/Profile A well-written summary or profile statement is enough to prompt my decision to initiate dialogue without reading much further. I encourage my candidates and résumé customers to include one. Even if the profile isn’t strong enough to get an immediate “let’s talk” response, it should help steer the reader to which content is relevant.
One can sometimes predict a candidate’s level of confidence/overconfidence or even a blatant lack of industry knowledge from a summary. Entry-level candidates using terms like expert or master to describe themselves are a slight flag.
There is a trend for candidates to create summaries consisting of several bullets (5-15) of information. A summary is intended to be shorter by definition, and these summaries indicate someone who may not understand what is relevant.
Experience is usually next (education for entry-level):
Experience I’m obviously looking for accomplishments and the candidate’s ability to put them into clear and concise terms. Were projects completed? For more experienced candidates, I’m looking for consistency with respect to responsibility and role. An abundance of internal acronyms and company-specific jargon without context is a flag, indicating the candidate may be insulated. Is it clear what the candidate has done?
I’m also observing how the candidate weighs details of their own work history. Candidates tend to lead with and highlight the experience they feel is most important and valuable, which provides insight as to their objective. Those looking to distance themselves from code may list leadership and management responsibilities (project management, mentoring, training, hiring, etc.) before more hands-on duties (architecture, development, etc.), whereas someone disinterested in management will likely emphasize and quantitatively detail a challenging technical problem and the solution.
Dates I look at dates to see if there is a pattern of large employment gaps, but I won’t discount a candidate based on gaps alone. I pay attention to long tenures at organizations and whether someone was able to accomplish several things over years.
Employer Names These are particularly useful when I am familiar with a company’s technically rigorous interview process, as a candidate’s hire by such a firm should at least indicate interview ability (though admittedly not job performance). If I have knowledge regarding how well/poorly a company compensates their employees relative to my client, employer name reveals a high price tag or perhaps an ability to give a significant increase.
Locations As referenced earlier, I notice non-local cities (if listed) and assess the probability that someone would relocate if necessary. When a résumé lists different geographic regions for every job, it can be indicate a candidate willing to go anywhere for an interesting job or someone that chases the highest bidder. If someone is likely to be interviewing nationwide, the odds of any individual joining my client fade.
A skills section often follows:
Skills Obviously I scan to see if the list remotely resembles the job description, particularly if the client has any strict must haves. Hopefully by now I’ve determined what the candidate has done by reading the experience and not buzzword searching. I gauge whether the overall skill set resembles the typical preferred profile of my client based on past hires. Listing a clearly unrealistic number of languages or skills is a flag, with the judgment of “realistic” based upon overall experience while allowing for a degree of self-study.
Last (first for entry-level) is usually education:
Once I’ve come this far the decision is made and the information here is unlikely to make me reconsider. I’ll glance to see if it’s a school I recognize as having a good or bad reputation, whether overall or for the program completed. I check if the graduation year matches with the earliest listed experience experience, as that may expose internships or a past career change. I don’t pay much attention to GPA for experienced candidates, and certifications tend to be ignored with few exceptions.
There may be other details on the résumé that don’t fall into these categories.
Personal Projects/Meetups/Hobbies Some candidates will dedicate a section to these or list them under experience. These don’t matter much for those with interesting professional experience, but can help push a questionable candidate into the let’s talk group.
References I’d never encourage a candidate to list the names of references on a résumé, as I think it’s disrespectful to the reference. Unless the reader recognizes a name, the information is useless at this point and unnecessary. References will be requested when necessary.
Most extended discussions about the technology industry and software engineering trade eventually find their way to the topics of worker supply and demand, talent shortages (real or otherwise), and compensation. Every Best Jobs of The Year list (examples here or here or here or here) features a Top 10 littered with assorted job titles given to those who code, often including salary data that could cause non-technical readers to regret life decisions.
New graduates entering the industry may receive multiple salary offers that dwarf those of non-coding classmates, and after five years on the job it might seem as if there is no limit on future earning potential.
What they probably don’t tell you in school or during your first few jobs is that most in the industry will hit a compensation plateau, where increases become smaller and less frequent. Market rate for skills increases with experience, but once a certain level of experience is reached the market rate flattens.
As an example, market rates for developers with 10 years of experience vs 15 years can be indistinguishable. Making lateral moves or even taking a pay cut in exchange for some potential asset (acquire a new skill or experience, equity, etc.) start to become best options.
The amount of time it can take to plateau varies. Someone who stays several years at one employer where small raises are standard may take 15 years to plateau, whereas someone changing employers with relative frequency or alternating between consulting and direct hire jobs may plateau early.
Ways to Earn More
When you’ve reached the plateau but have some need to earn more, there are a few methods to consider.
Move out – The most effective means to more compensation is still to get a job with a different company. This method usually becomes less effective at the plateau than it was earlier on, but there is almost always another company willing to pay at least a bit more.
Move up – Gaining more responsibility through an internal move should come with more salary. If the company is top-heavy or there is a line for advancement, moving both up and out may be necessary.
Ask – If money is the impetus for considering a change of any kind, why not ask your current employer first? If the answer is ‘no‘ now, they may become more cooperative when you have other offers in hand (not that I’m suggesting counteroffer as a sound strategy).
Branding your additional benefits – Professionals with similar accomplishments and years of experience appear homogenous and plateau. In addition to the productivity and ability that comes with years, are there other benefits that an employer receives by hiring you? Candidates with higher public profiles due to community involvement, such as Meetup leaders or conference presenters, may command a higher salary due to the increased visibility or prestige that their hire would provide a company. Candidates that are likely to be followed to a new employer by a loyal network of talent might justify higher prices.
Consulting and contracting – Contractors and salaried employees of consulting firms both typically earn above market rate for direct hires. A move to contracting or a consultancy can be a sound strategy for those in traditional non-consulting direct hire jobs, but consultants and contractors will also plateau over time.
Moonlighting/revenue streams – Those that have some extra time might consider taking on off-hours remote contract work to increase earnings. Building and monetizing a product may result in additional dollars with minimal long-term time commitments.
Specialize – Becoming recognized as a specialist in a niche area may make it easier to command rates above market. Those specializing in the newest technologies may be able to take advantage of the fact that a market rate has not yet been established.
While training for my first job as an agency recruiter, I was directed to ask all candidates for their current salary. It was uncomfortable at first, partially because of the vast disparity between my income as an entry-level recruiter and the salaries of experienced software engineers in the late 90s during the dot com boom. Discussing compensation with strangers can make people uncomfortable, whether in casual settings or in negotiations with employers. Children (many in the US anyway) are taught not to ask people how much they make, and this cultural element may contribute to why some are reluctant to discuss. Even as an experienced recruiter, I rarely get a rapid-fire response to money questions.
Recruiters gather as much data on candidates as possible, and are trained to use a strategy to prevent spooking anyone. Initial calls start with harmless questions about candidates’ interests and experience, eventually graduating to more sensitive topics once rapport is built.
In my early years, candidates unwilling to respond to the “How much do you make?” question were told that I needed numbers to proceed. Some candidates shared data, some refused again or ended the call, and others asked why I needed to know. Nobody needs to know someone’s salary history to hire them (or recruit them for hire), do they?
One scripted rebuttal was “I don’t want to waste your time“. This phrasing is no accident (“waste your time”, not “waste my time”) and infers that candidates derive benefits by answering, although recruiters are likely more concerned about wasting their own time. The time reference alludes to the possibility that a candidate goes through interviews but gets an offer below expectations.
The most popular theory behind the recruiter’s insistence upon learning salary information is probably the one eloquently expressed by Patrick McKenzie (aka “patio11”) in his epic 6K+ word 2012 post on salary negotiation, where he suggests that candidates being interrogated for numbers (though not specifically by an agency recruiter) should think “You’re lying to me to attempt to get me to compromise my negotiating position.” I believe there are more exceptions than Patrick does to the often quoted “never speak first” rule of negotiation, and I feel informed candidates with market knowledge shouldn’t fear providing salary history. The number provides one data point as to what someone was willing to work for in the past, but candidates familiar with market values don’t need to accept less than market for their services.
As a recruiter, couldn’t I work with a candidate without knowing their current salary or their expectation? It probably depends on the hiring company, but most of the startups I have worked with are willing to play along without salary data and I’ve made successful placements blind to salary history.
The better explanation for a recruiter’s behavior when candidates deny salary info requests is that the refusal indicates a lack of candidate control.
As I’ve written before, candidate control is the notion that a recruiter gains influence over a candidate’s actions during the interview process, culminating when the recruiter gets the candidate’s acceptance to a job offer. Considering that an agency recruiter is only paid if a candidate takes their job, time spent with candidates unlikely to accept an offer is wasted (using entirely short-term thinking).
How Candidate Control is Achieved
One method of gauging and achieving control is through small incremental requests with multiple positive responses over time, with the theory that this repetition will somewhat condition the candidate to be agreeable to future suggestion particularly at offer. The first requests are small and necessary to the hiring process: schedule a phone call, send a resume, respond to basic background questions, etc. Eventually the requests are not vital and in some cases just self-serving for the recruiter: call immediately after an interview with feedback, requests for references early in the process, asking for referrals or introductions to contacts, etc. Compliance is a good sign for the recruiter.
Examples of the highest levels of control might be when candidates give recruiters proxy to accept offers over $SALARY or to let the recruiter provide resignation notification to the candidate’s current employer. Yes, this happens.
What Every Job Seeker Should Know
Candidate control isn’t something to fear for most job seekers, but it’s helpful to be aware of how recruiters are trained to gain influence and close deals. This doesn’t necessarily mean recruiters are all coercing candidates to accept jobs they shouldn’t, but candidate control could lead to that outcome.
When a candidate refuses recruiter requests (whether reasonable or not) early in the process, recruiters assume that candidate will prove difficult to persuade when interviews and offers are at hand. If a candidate is unwilling to provide information, a recruiter who insists on control may simply abort the process.
The aforementioned “I don’t want to waste your time” rebuttal might really mean “I don’t want to waste my time with candidates I can’t control who therefore are less likely to accept my offer“.
Got a question about recruiter behavior that might make for a Stupid Recruiter Tricks column? Leave a comment below.
Or discuss on Hacker News
Several times a week I am asked by a contact/reader/someone on Reddit for advice on what they should learn next. The question comes from both junior and experienced programmers, and has been posed both as open-ended (“What should I learn?“) and multiple choice (“Python or Ruby?“, “Django or Flask?“, “iOS or Android?“, etc.).
Unless it is someone I’ve worked with, there is usually little (or no) accompanying information or context provided which makes any answer rather speculative. To respond with hard data on compensation figures or even an informed opinion regarding future demand for a skill may be helpful, but offering career advice blindly without any knowledge of the person borders on irresponsible.
The easy answer (the long view) is to just say that overall programming ability and knowledge are the most important factors in maximizing employability, and that languages and tools are mostly interchangeable for experienced professionals. “Any good engineer can learn a new language in n weeks/months” is commonly heard from those at the senior level. Whether this is true or not is debatable, but it still does not account for a multitude of factors that may make a particular language more favorable than another to an individual at any given time.
One needs to think of learning as a time investment, and investors need to consider maximizing ROI. Before deciding where to invest their time, it may be wise to research and evaluate some of the following.
- Programming experience and background – Those with little or no programming experience are usually pushed towards a few languages, with Python and Ruby the most popular among bootcamps and courses aimed at beginners. Experienced programmers that have a larger set of realistic options may consider how quickly a language might be picked up based on the paradigms and concepts that are already familiar. Build on what you know. Many Java developers were C++ refugees in the late 90’s, and Java pros of the past decade are venturing into Scala and Go.
- Availability of learning resources – People learn in different ways, so it’s important to first recognize their best learning method and then research what resources are available. Those who learn best by doing can find it challenging or expensive to find resources and tools for proprietary or highly-specialized languages. Classroom learning opportunities or books on emerging languages often don’t exist or may be cost prohibitive relative to common languages. Documentation and support for newer tools can be spotty or unreliable.
- Market supply and demand – If employability is the impetus for learning (as opposed to intellectual curiosity, boredom, etc.), both the current and projected supply and demand for talent is worth noting. Supply and demand are not necessarily universal trends and can vary based on geography and experience level. As an example, demand for entry-level Haskell talent is almost non-existent but rises significantly with experience. Searching for jobs specifically within desired geographic regions and doing research with a tool like Indeed’s Job Trends may provide some insight into both local and national data.
- Professional goals – What types of products do you want to work on? Those interested in gaming might benefit from different choices than those interested in web development or embedded systems. Do you measure job satisfaction by professional accomplishments or is compensation a bigger motivator? Certain industries pay better than others, and certain languages are more prevalent in those industries.
- Popularity and adoption trends – Learning an esoteric language that employers don’t use can be helpful in becoming a better overall engineer, but useless for putting food on the table. Trying to become reasonably productive in a language after hours can take time, and the adoption levels and/or popularity of a language could potentially change during the learning process. Researching current and historical data can be helpful. In addition to Indeed Trends, other sources include the ThoughtWorks Radar, RedMonk rankings, and the TIOBE Index. Always consider how the ratings are assembled, past performances to determine trends over time, and keep in mind that others may be using the same data to make decisions. Just because a language is “#1” today doesn’t mean it will be in a year, and identifying and prospecting underserved language camps experiencing high demand is one way to employability before the market supply catches up.
- Community or vendor support – Is there a community of people dedicated to keeping the language vibrant and relevant? Is the language supported by a vendor in good standing, or are the stewards of the language in a poor position to continue? Regarding community, Raganwald tweeted this back in February and it resonated.
What did I miss?