Homakov: Story of a White Hat

In early March 2012, a Russian programmer one month shy of his 19th birthday emerged on the radar of the software world via one “simple” commit that startled both the Rails and GitHub communities.

railscommit

The exploited vulnerability was known to many in the community, so discussion about the controversy gravitated towards GitHub’s failure to properly protect repos and the potentially insecure default settings of Rails. The attention drawn to mass assignment served as a beneficial public service announcement to other Rails users, although the delivery method put off many developers as well as GitHub admins who quickly suspended (and just as quickly reinstated) the account. It was all over within a few hours, but Homakov had “arrived”.

Who is this guy?Homakov

Egor Homakov grew up in Saransk, a small city of 300,000 residents that sits 400 miles east of Moscow and somewhere deep within Ukraine on a Risk board. He dabbled with Delphi as a teenager to learn how programs worked, and later Pascal. His GitHub dates to 2009, oddly enough on New Year’s Eve. After initially struggling to understand programming concepts, his self-study turned a corner when he transitioned to web apps. Homakov dropped out of university before completing a year, which he admits was a risky move for someone in Saransk, but he found the program far too boring to continue.

Homakov initially focused his career on SEO, but when clients were hard to come by he began advertising PHP programming services on SEO forums. When negotiating a proposal to build a simple news management system for an early prospective client, Homakov requested a rate around $10 per hour. The prospect countered with an offer of $30 if the job was done well. This was a significant wage in Saransk, and Homakov distinctly remembers his mother’s pride.

Over the next few years Homakov bounced between employers, with freelancing gigs followed by short stints at European startups in the online payments and travel spaces. Eventually he decided consulting was his best option, and he is now part of the security firm Sakurity which provides penetration testing and code audit services to clients worldwide. The lion’s share of Homakov’s income comes from consulting, with some additional income via bug bounties (including a $4,000 payout from GitHub earlier this year).

Fame or infamy

Although he admits that he knew little about security before the 2012 GitHub hack, Homakov instantly became a polarizing figure. His action was lauded by some who believed the high profile exposure of the vulnerability would benefit the community by raising awareness for other Rails users. Others felt a more private notification would have been more appropriate, not to mention GitHub’s clear responsible disclosure policy in the terms of service. Supporters saw him as some populist hero sparring the Rails elite, while detractors resorted to mocking his broken English and even criticizing his profile photos. Those on both sides surely realized that he could have chosen the black hat route and done something much more malicious with the Rails repo and any others, and could have done so anonymously.

Some soon discovered that Homakov had indeed opened an issue about the mass assignment vulnerability, and only went public when he felt his warning had fallen on deaf ears. Homakov later regretted much of his behavior, and eventually provided a brief public apology to both GitHub and the Rails team. It’s not much of a stretch to imagine that GitHub’s bug bounty program launched earlier this year was at least partially influenced by their highly public experience with Homakov.

The most interesting man in tech?

Since leaving Russia, Homakov has become a world traveler. His Tumblr feed reads like a poorly edited and NSFW Frommer’s guide, chock full of selfies and commentary on the livability and food/drink from locations throughout Europe, the United States, and southeast Asia. Sofia, St. Petersburg, Barcelona, Istanbul, New York, Shanghai, and Seoul – all while earning a living and developing a reputation in the security space.

From his writing it is clear that he has an affinity for Asian culture, bright city lights, and beer (not necessarily in that order), while showing no affection for his country of birth. After about a year on the road, Homakov finally settled in Thailand, where he intends on living for a year before picking up for more travel on the spots he has missed on his first world tour. India, Africa, and South America are on the agenda.

He seems pretty funny too. His Twitter feed is peppered with various self-deprecating third person references as well as little gems like this…

joketweet

And now that he’s showing maturity…

joke2… he seems to have the ear of at least some in the industry.

atwood

Although much of his security research is unpaid and he is far from wealthy, it’s been quite a trip so far. From $30 to $300 an hour, and from Russia to Bangkok with plenty of stops in between – all in two years. He admits he acted irresponsibly, but now calls himself white hat and takes responsible disclosure seriously. As someone who first arrived to the security field conspicuously, Homakov continues to strive for increased credibility and legitimacy from peers in the industry. For many, his work will speak for itself. As he now approaches his 21st birthday, one has to wonder what his future hold.

 

Author’s Note: This article is a departure from Job Tips For Geeks normal content, but I see value in profiling technologists who have unique careers. I hope to profile others with non-traditional backgrounds and career paths. Feel free to contact me if you feel you fit into this category.

Why Hire Older Engineers

Another day, another article about age and technology. The comments of these articles usually escalate into some generational war played out with mythology and anecdotes regarding relative energy levels and productivity, work hours, the value of experience, and general competence. These discussions usually make no progress, while some useful topics are ignored.

As someone who has been around programmers (and ran a Java Users Group) for about 15 years, I often guide senior technologists in marketing their skills. When doing business with clients, I find myself advocating on behalf of older coders regularly. During the first dot com boom multiple six-figure job offers were dealt to anyone at any age who could spell J-A-V-A, but the landscape is much different now.

Most companies I’ve worked with give candidates of all ages a fair shake, although I’ve witnessed some who have been less friendly to industry veterans. For firms that need additional justification for hiring older workers, here are a few additional considerations that may go beyond the more common topics of discussion.

mainframe picture

Recruiting – So your efforts to scale your team came to a screeching halt? Inevitably the friends and family network dries up and firms rely on internal recruiters or outside agencies to identify talent. Although young hires may be more connected due to early adoption of social networks, older workers usually come with established professional networks. These contacts are not just other senior engineers, but will also include younger former co-workers. When you consider the costs of recruiting (not to mention the costs of a bad hire), the ability to tap into the network of highly experienced engineers might even justify paying a higher salary.

Beyond just the network a senior engineer may possess, having experienced talent on staff will appeal to young candidates who understand the value of learning and career development. A predominance of junior engineers will typically scare off older applicants, and it’s also likely to be a red flag for some subset of the young. Graduates are typically encouraged to find a career mentor, and they will seek experienced professionals to serve in that capacity.

I generally advise my clients on employing some senior level engineers who are strong coders but will also serve a secondary purpose of attracting other less experienced hires. The term I usually use is “hire magnets“, and those magnets may fit a few different profiles. The magnet could be a recognized authority on a topic, an involved tech community leader, or simply a knowledgeable and charismatic developer who enjoys sharing knowledge.

Fad recognition – Industry experience may give engineers a sharpened ability to sniff out the difference between a passing fad and the genuine article when considering new technologies. This of course isn’t by rule, but once an engineer has seen enough shiny things being hyped by marketers and evangelists it should theoretically become easier to evaluate trends with less bias. Hires with this skill may save a company time, money, and many developer hours.

Less performance unknowns – Older engineers with a documented work history, a list of credible references, and demonstrable work experience should be easier to vet than juniors coming from their first or second job. The ability to rely on past performance to predict the future is a benefit, though never perfect.

Retention/stability – Employee retention is a serious concern and cost for many firms, with demand for talent contributing to turnover. Older engineers and those with families should be less likely to consider relocation for new positions, which limits their other employment options to local or regional opportunities. Although both junior and senior level engineers may have bills to pay, the breadwinner concept changes perspective and may result in satisfied and fairly-compensated developers staying put.

Senior level developers often reach a point where compensation plateaus and money ceases to be an incentive to change jobs. Employees less driven by dollars are surely driven by something. It could be something as simple as proximity to their home or a desire to solve complex technical problems, but competitors are less apt to change these factors and often need to compete with pay.

From my experience, most engineers see fewer significant increases related to job change around their 15th year in the business, and by the time someone reaches that level of seniority it isn’t unusual to have once taken a pay cut. Junior level talent in competitive markets view job change as the most reliable means to salary increases, while the relatively minor compensation differential for senior engineers may not outweigh the uncertainty of a new employer.

Unique situations – There are some scenarios that happen in development shops that are nearly impossible to replicate in a classroom or lab setting, and the ability to face the unexpected comes from being there. This could refer to crisis management when a server goes down, handling difficult customers, or knowing how to navigate office politics. Prior exposure does not guarantee preparedness, but should make the second experience less shocking.

On-the-job learning – Older engineers may now be on their second or third set of platforms and corresponding tools. Developing the ability to learn new languages and tools in a work environment is a skill. It is quite valuable to know how much (or how little) to read before starting a project with an unfamiliar component, or which methods are most effective for you when seeking knowledge.

Any that I missed?

How To Succeed in Software Without a CS Degree

This week I was approached by two individuals seeking advice on finding employment in a programming capacity, yet both lacked the traditional standard requirement for entry-level positions – the BS in CS (‘BSCS’). I get asked about entering the industry often, and each scenario has a unique wrinkle.

The most recent candidates were a fresh Ivy League liberal arts grad and a Physics Ph.D. The former had brief hobbyist programming experience and the latter gained light exposure during school. Both are immediately employable in other industries, but perhaps not in the field they now target.

Of course, both may still be able to earn a BSCS (or MS) and take the traditional route. For our purposes here, let’s take that option off the table. For a Ph.D., the thought of additional classes might be hard to swallow, while costs might serve as a barrier for many others.

Non-BSCS candidates are often at a distinct disadvantage when competing with BSCS grads for entry-level positions. It’s becoming more common for CS grads to enter the workforce with multiple internships and code samples to bolster their candidacy. It’s reasonable to assume that typical non-BSCS grads have nothing comparable, in addition to what may be considered a less attractive degree.

One important point to remember is once you’re in you’re in, meaning that the most difficult job search for non-BSCS grads should be the first one. After gaining a bit of experience, your risk factor subsides (assuming you didn’t perform horribly in your first job). After three years no one cares about your major, and after five no one cares about your degree.

What are the common approaches for a non-BSCS grad to break in?

DIY and self-study (AKA GitHub, apps, certifications, blogs, and sites) – This method is based on the philosophy that you get a shot if you have a body of work. The wealth of freely available resources makes this method attractive to both the confident and the frugal. There can be a fine line between rigorous code immersion and post-graduation idling, so it’s helpful to set tangible goals, a schedule, and practice self-discipline.

When given no direction on what to build, people usually struggle to find projects ideas. Look for suggestions like those on Martyr2’s Project list, and improvise. As for reading material, there are extensive lists of free programming books that may be helpful. All the material you need is out there and easy to find.

Bootcamps – Any conversation today about breaking in for the non-BSCS will include bootcamps, and I have mentioned thoughts on them before. Bootcamps may be regarded as a compromise, where the investment of both time and money rests between DIY and degree programs. Some view bootcamps as an accelerated BSCS, or a hybrid internship and apprenticeship with classwork included. Most bootcamps appear as preparatory schools for startups based on the skill focus and instructors. Do your homework, and use caution when discussing the value of bootcamp experience versus degrees to avoid insulting employers.

Internships, or cheap/free labor – Some organizations (think small businesses and non-profits) will let a non-BSCS perform development tasks as an intern or volunteer. This can be a clear ‘win-win’, as the organization gets productivity while you get somewhat valuable real-world experience. A combination of volunteer or internship and personal projects starts to level the playing field for a non-BSCS.

Training in – There are companies that hire non-BSCS for entry-level programming jobs, and the first months include corporate training programs designed for non-CS grads. The positions may pay less than entry-level programming jobs, with curriculum intended to produce effective employees instead of versatile engineers. For example, instruction could focus on proprietary technologies and frameworks instead of popular industry offerings.

What are some key items to consider?

Get out of the basement! – Some DIY’ers bury their head in code and books with no human interaction. Make community learning events and outside communication a part of your diet. This will help you measure your knowledge in a live setting while also providing the opportunity to make some industry contacts.

Don’t enter the job market too soon – For CS grads, the natural time to start the search is around graduation. No mystery there. For the non-BSCS, there is an instinctive rush to start applying to jobs early in order to take the temperature of the job market. Fight the urge. If you apply to a desirable company today and are subsequently deemed unready, don’t expect to be reconsidered in three months (when you are ready). Make sure you know enough to succeed in technical interviews, have your GitHub code clean and optimized, have any apps or sites tested and fully functional, and are prepared to make a strong impression.

Leverage the skills you have to acquire the ones you want – Bringing useful abilities and experience that can pay immediate dividends (no matter how small) to an employer mitigates their hiring risk. If you are able to contribute to an organization beyond just code, providing both a learning opportunity and a decent wage is easier for firms to justify.

Be realistic – Your three months of self-study or bootcamp are not likely to get you the dream job at Google. Be willing to start towards the bottom and pay your dues to move up.

Beware certifications – When faced with a choice of proving abilities with either code or certifications, always pick code. Many industry pros attach a stigma to those who focus on getting certified instead of just doing.

Make learning opportunity your #1 job search criteria for first jobs – The money will come. Trust me. If provided multiple job opportunities simultaneously, opting for a job due to an extra $2K or a commuting difference of five miles will be regretted. Find a place where you can learn and grow.

For more tips on job search for software professionals, see Job Tips For Geeks archives or my book.

When You Can’t Compete on Salary: Tech Talent On a Budget

When trying to hire developers, startups and small companies now find themselves in the unfortunate predicament of having to directly compete with the unlimited resources and mass appeal of market heavyweights like Google and Facebook. New grads are laser-focused on getting jobs with what many call The Big Four, and some grads will land. Most founders and hiring managers know they can’t match compensation, name recognition, or facilities that the big players provide, yet they do a poor job marketing themselves to talent to demonstrate where they actually can compete.

A quote on a recent Hacker News thread echoed the frustration that countless others surely feel:

I hire engineers at an academic medical center who work on really tough biomedical problems. Let’s just say that I would have to move heaven and earth to get annual percentage raise amounts that are being thrown around here. I wonder how industries like healthcare can hope to have the best people with this job market. At some point, even if you are doing work that really matters in a big way, you can’t be stupid about your career and leave money on the table. – HN user JunkDNA

The commenter is correct that the medical center’s employees are likely ‘leaving money on the table’, but this does not mean that hiring managers must resign themselves to subpar talent. A defeatist attitude leads to a host of problems down the road, and mediocre teams create mediocre products and a poor company reputation (which then makes competing for talent impossible without massive compensation packages).

My experience has put me in a position to observe candidates with multiple offers many times. Candidates don’t choose the highest bidder as often as one might expect, and once you’ve had enough conversations on the choice between Job A and Job B it becomes clear that there are several situations and characteristics that technologists are willing to take in lieu of dollars and a recognized name on their résumé.

Firms competing for tech talent on a budget should consider how the topics below influence candidates’ decisions when weighing money against intangibles, and how to market themselves to increase appeal to potential hires.

Work visibility – Many developers derive job satisfaction when they can show friends, parents, children, and significant others what they actually do. Whether they coded an e-commerce site, a video game, or even a device driver, many developers relish the ability to say “I built that“. This value gets overlooked, but it can be one competitive advantage in hiring. If a company builds a visible product, that can be a selling point.

Remote work – If you feel demand for remote work is overstated, post a remote job and see for yourself. Some of the applicant pool’s volume and quality is obviously explained by the geography barrier being lifted, but job seekers are specifically including ‘remote‘ or ‘telecommute‘ along with their tech search terms. The groundswell supporting remote work is impossible to ignore, and remote hires are often willing to accept less money (which can create other problems). If 100% remote work isn’t feasible, even implementing “Remote Fridays” may make a difference.

Autonomy – This could be defined as the ability to make decisions on tools and vendors, final say on hires, or being able to choose a machine and operating system. If autonomy is offered, it’s often worth noting.

Languages and tools – The importance of languages and toolsets became apparent to me when several more lucrative offers were rejected by candidates due to concerns over future marketability or distaste for the tools and languages. Hiring managers are beginning to appreciate the weight some job seekers place on being paid to code in a certain language, and those managers may attempt to justify using an emerging language in some production capacity for the purpose of attracting new talent.

Impact on the business – Most candidates that interview at large companies don’t expect that their contributions will significantly impact the firm’s direction or bottom line. Smaller firms offer the potential opportunity to make a measurable impact, and can use that opportunity as a selling point.

Interesting problem domains – All technical problems won’t interest all candidates, but savvy technical interview teams should learn to discover a candidate’s interests and articulate how the job will allow that itch to be scratched. For most industries, it is vital to get the candidate to look past the non-technical business (widget selling) and focus on the technical challenges (supporting 10M widget buyers). Complexities around scalability and concurrency can make a mundane business quite appealing to top talent.

People – I ask all candidates how they choose jobs, and “people” has consistently been a top 3 answer over my career. For some this means the broader company culture, while for others it is the ability to work with experts. Even at a rate above market, hiring a couple high-level talents who can act as magnets for other talent can be a wise investment if it makes future hiring cheaper and less time-consuming. Companies competing on intangibles should always put their best people in front of candidates during the process.

Reasonable hours/flexibility/vacation – It is somewhat rare for companies to advertise the length of their work week, due to inconsistencies related to events or the sobering realization that the hours are undesirable. For most companies, a reference to a week in the 40 – 45 hours may be considered a genuine draw to candidates, while under 40 is notably positive. Flex time is another perk that can make a company’s expectations more reasonable.

Equity/interest – Parting with equity is often not a founder’s first choice, but when up against deep pockets it becomes one potential equalizer.

Conclusion

Those involved in the hiring process should be aware of their company’s potential competitive advantages over the larger employers in their market. This is most important when it is impossible to outbid well-known market leaders. Tech talent does not always go to the highest bidder or the biggest name.

Counteroffers, Secrecy, and Fear

Counteroffers are a fairly common occurrence in technology and other competitive job markets, and much of what we think we know about counteroffers seems to originate from agency recruiters. Google counteroffer and we find articles with fear-inducing titles.

counteroffer copy

Check the bylines for these articles and you’ll discover that many are written by recruiters. Some agencies are so bold as to direct their counteroffer article right at the candidates they represent. Or a page of Counteroffer Facts, which go on to list things like “Your loyalty will always be questioned” (which is probably not a fact). It’s pretty clear how recruiters feel about counteroffers.

There is nothing wrong with recruiters writing articles about counteroffers. You are reading one now. Many provide ‘statistics’, while others contain anecdotes revealing the unfortunate fate of those who accepted. Spoiler Alert – In recruiter articles, those who accept counteroffers always die alone and penniless. These pieces aren’t necessarily biased or untrue just based on the source, but when recruiters are the source you need to understand one thing.

Recruiters NEVER benefit from an accepted counteroffer.¹

Counteroffers are the bane of a recruiter’s existence. Put yourself in a recruiter’s shoes for a minute. Over a few weeks you’ve identified a strong candidate, screened, set up interviews, debriefed, negotiated a salary, checked references, and an offer was accepted. You will be rewarded handsomely, as a fee might be in the neighborhood of 30K (sometimes less, sometimes more). If the recruiter is independent or self-employed, that’s a car. And then you get a call saying “My company made me a counteroffer, so I’m staying.” You just ‘lost’ a car. I’ve had it happen, and it burns.

Even if a counteroffer makes all the candidate’s wishes come true, it’s still never in the recruiter’s best interest for it to be accepted. Recruiters get paid when they get you a job with their client – not when their efforts result in a better job at your company. This is part of the reason the recruiter/candidate relationship has flaws, as the interests of the two parties are not always aligned. It’s no wonder some recruiters invest significant time in talking about counteroffers.

How do recruiters prevent counteroffer acceptance?

The best way to prevent a counteroffer from being accepted is to prevent a counteroffer from even being presented, and recruiters may take a two-pronged approach to protect their fee and the interests of their client. Here is a peek into the methods. (NOTE: These details are provided to benefit job seekers, and not as any endorsement.)

1.  Find out why a candidate is considering new jobs.  Why are we talking?” This question sounds innocuous and usually comes across as an ice breaker, yet the answers prove valuable if a counteroffer is presented.

2. Get the candidate’s opinion on counteroffer early. “Have ever accepted a counteroffer?” may come up in your first conversation with a recruiter. Candidates rarely admit that they would consider a counteroffer. If the recruiter can get that opinion in an email, expect to see that email when a counteroffer is made.

3. Tell stories and provide ‘statistics’. Many recruiters cite a National Employment Association study that says 50-89% (depending on where you find the statistic) of people who accept counteroffers will not be with the company after six months. I was unable to find any reliable source for that (date, sample size). Of the 34,000 Google hits on “National Employment Association”, over half contain the word counter or counteroffer. Seems odd, no? It appears the organization somehow merged or morphed into a couple others (NAPC or NAPS), but the statistic lives on. I’ve seen anecdotes that this stat has been used since the 70’s.

Others mention a Business Week figure at 90%, but all I was able to find was an article from 2004 that cites “some studies” and puts the number over 50%.

One may get the impression that recruiting firms are using statistics from other recruiting firms, as these studies seem difficult to verify. Anyone got a source? To get decent statistics, you need consistent methods of gathering data. Even the definition of what qualifies as a counteroffer is up for debate, so any stats are questionable.

Even without numbers, anecdotes work just as well.

4. Fear, shame, worthlessness. The statistic is delivered as “Most who accept counteroffers are gone in six months, either by choice or (dramatic pause) … termination.” People have a strong fear of being fired. Candidates will be told how they will never be promoted or given raises, will be a social outcast, and they will not be given interesting work. These are all possibilities, but obviously not guarantees, and someone who habitually forgets to buy the donuts could suffer a similar fate.

The recruiter may also remind you that your employer never really valued you in the first place. They might say “Sure, you got a raise – but you had to hold a gun to their head to get it. How much do they really care about you?”

5. Resignation. If a recruiter has ever offered to provide you with a resignation template, or to even tender your resignation on your behalf (it’s rare but it happens), it may have been a genuine act of kindness to save you time. A recruiter’s resignation template may include language intended to prevent counteroffer, and some are direct. “Let’s not waste time discussing what it would take for me to stay, as I have already passed on my firm commitment to a new employer.” If the candidate emphasizes that he/she does not want a counteroffer, resigning with a letter that says is appropriate.

6. Transitioning. Once a candidate accepts an offer, a recruiter wants the candidate’s loyalty and interest to shift to the new employer. A lunch may be scheduled before start date to discuss projects. If there are skills that will need to be learned, the candidate might choose to get a head start. Interactions between employers and new hires have obvious benefits beyond the prevention of a counteroffer acceptance, but that will be in the recruiter’s mind.

I remember discussions in one recruiting office about which day of the week was most common for counteroffers to be given, and then suggesting that the recruiter get together with the candidate on that day.

When It Happens

When a candidate accepts a counteroffer, it usually sets off recruiter panic mode. The recruiter will remind the candidate of some things – why they were looking in the first place, opinions expressed about counteroffer, the dangers, their firm commitment to the new company, etc. As a last resort the recruiter might make a personal plea and mention the fee, or even their own family. Some people will say a lot of things for 30K.

I don’t have a problem with some of the things recruiters say as warnings against accepting a counteroffer, as much of the script contains real possibilities. Accepters might not get promotions, raises, or interesting work. We can question the morality of using fear to get someone to do what you want them to do. If the recruiter is honest and believes that the new job is best for the candidate’s career, it’s easier to justify what is said. I do have a problem with the statistics, and the recruiting industry’s willingness to throw around questionable numbers.

Secrecy

Statistics about counteroffers are impossible to measure when you consider the interests and incentives of the parties involved. Companies that counteroffer departing employees are best served to keep that fact private. as employees may pursue offer letters just for the sake of a raise or improvement and outsiders may question if the company pays market rates.

Likewise, those who accept counteroffers may be concerned with the word getting out, as it may genuinely impact attitudes towards the employee. Employees who accept counteroffers are likely asked to keep quiet about what happened, and it’s usually in their best interest to do so.

Based on the secrecy incentives on both sides, one might assume that the prevalence of counteroffers is likely higher than reported, and success/failure rate of counteroffer is difficult to assess.

Conclusion

Regurgitating outdated or questionable statistics as fact hurts the credibility of the recruiting industry. Counteroffers are all very different and impossible to classify or evaluate without knowing countless other details about the candidate’s situation and the organizations involved. When listening to recruiters’ opinions (including this article), it’s vital to keep the source in mind and make important career decisions based on all the information available. Ask yourself if the counteroffer will solve the issues you had with the employer, and if so whether your means of achieving these results (resignation) will make it difficult to stay.

¹ There is one extremely rare instance where a recruiter might benefit from a counteroffer. Say the recruiter places a candidate at Company A, and during the recruiter’s guarantee period (usually 90 days) the candidate accepts an offer from Company B, and then gets a counteroffer Company A. In this case it benefits the recruiter for the placement to accept the counteroffer from Company A so the recruiter will not have to refund a fee.

Don’t Make Me Read Your Résumé (How to Apply to Jobs)

I will read your résumé unless it’s 10 pages, but (just as you didn’t want to write your résumé) I really don’t want to read your résumé. To put it another way, I don’t want to read it because I must in order to make a yes/no decision. Ideally, I can decide to speak to you based on a few sentences in the body of an email/application, and then primarily read the résumé to prepare for our initial dialogue and use it as a framework during the call. Give me a few sentences to make me want to have that talk.I can haz job?

I never ask for or expect a full cover letter with addresses and dates and all the formatting. Personally, I don’t want to read that either, and I’d rather not task applicants with the hassle. All we’re trying to do is start a conversation, and it shouldn’t take much to get it started.

Reading only a few sentences before making a decision will clearly make my job easier, but it will make the job seeker’s life a bit better as well. There is much less pressure to have the perfect résumé if you can get past the first stage without that document being carefully judged. Invest five minutes in the application, and you can spend less time customizing résumés.

Roughly 50% of the applications I receive are résumé only. In 2013, almost 90% of my client hires included additional content. The data set is not large, but over my 15 years I’d expect that the figures would be rather consistent.

Whether applying for an advertised job via email, an online application, or even if you are just blindly sending a résumé in the off chance a company might consider you for hire, the key concepts to address in the content that accompanies the résumé are:

1. Tell me what prompted you to apply for the job

Where did you see the ad? If you were on the major job boards, you saw hundreds. What was it about this ad that caught your eye and made you act? One sentence is plenty. If you saw the ad on the company’s website, kudos – you weren’t out trolling the boards; you were actually looking into us. What did you like about us?

2. Show me why you believe you are qualified

It isn’t necessary to write a long and detailed summary of your experience here, and you shouldn’t. One or two sentences that distill the most relevant experience will get us to the next step. You can quantify years of experience in the industry and with a couple technologies listed in the ad, reference a noteworthy accomplishment, or briefly describe how a current or past role prepared you. A link to past work might help in certain cases (UI and mobile specifically).

3. Express interest

If you’ve covered what prompted your application and your qualifications nicely, a simple “I’m very interested in learning more about this position…” can suffice. If you feel you may need just a bit more to put you over the top, demonstrating that you did a minute of research on the company can help. Is there a product we offer that you’d like to know more about? Did the way we described our culture have particular appeal to you?

4. Mention the company’s name, twice

Doing this lets me know you cared enough not to send a pure form letter. Applications that use generic phrases like “your company” (or the worst, “your esteemed organization“) name scream “I’m just looking for any job” and not “I’d like to be an employee of COMPANY”. The first mention can be in the opening sentence when you list the job itself (“…apply for Senior Python Developer at COMPANY“), and specify again in your closing.

5. Don’t do anything stupid or desperate

Referencing the wrong company name due to cut/paste miscues is a common one, and although we are willing to forgive a small error it does give the appearance that the candidate has applied to several positions simultaneously (which is fine, but decreases our odds of hiring). Creating a tone that you are desperate to work is not helpful, regardless of how true it is. Make the recipient want to hire you based on your skills and not on sympathy. Don’t ask me to hire you, just explain why I should want to.

And a few Protips for specific situations…

If you are asked for a salary requirement…

If you are uneasy about providing salary requirements, at least acknowledge the request tactfully (as opposed to completely ignoring it). Try something like “It’s difficult to provide an accurate salary requirement before knowing any other elements of employee compensation packages, as well as the job responsibilities and company’s expectations for this role.

If you are applying for a job in a different city…

Recruiters receive many résumés from out-of-town applicants. When we see a non-local address without any explanation, it is often safe to assume that you are applying for many jobs all across the country. There is nothing wrong with that, but the odds that we will hire you become much lower if you are looking everywhere (more choices lower the chance you’ll choose us). Combine this with the complexity of relocation – cost of living differences, moving costs and potential reimbursement, changing schools for young children, etc. – and the recruiter has to weigh the decision to spend time with you or someone local. Therefore, unless your résumé is spectacular, a non-local applicants may not be given the same level of consideration.

When targeting a move to a specific city, mention this in the body of your application. Companies will pay close attention to candidates that have concrete plans to move to their city, and agency recruiters are much more likely to work with you if you are only seeking jobs in one or two locations. If you can provide a future local address on a résumé, that may help.

If you are somewhat underqualified for the job…

There will be times when a job looks very appealing but your experience clearly falls a bit short. In this situation, the opportunity to write a few sentences in support of your résumé is your best shot at consideration. Recruiters will often give at least one chance to underdog candidates who attempt to make up for a lack of years with some enthusiasm or an interesting story. It is much harder to say no to someone who demonstrates that they are eager to work for you.

I wrote a book

Would You Hire the CS Class of ’04 Today?

A comment in a Reddit computer science career advice forum got me thinking. There was mention about the high volume of advice in the forum coming from inexperienced people relative to advice from industry veterans. The comment that got my attention (which I believe was made by an experienced person) was:

And most of the people giving advice in this sub¹ are 10+ year veterans who, if they had only the skills they had when they first got hired 10 years ago, could never get hired in today’s market.

So could the college class of ’04 couldn’t get hired in today’s tech talent market? That’s an interesting topic for debate, and your age likely influences which side you choose.² Of course, ‘skills‘ could be interpreted as overall engineering chops (concepts that are language/tool agnostic), or ‘skills’ could refer to ’04 grads having dated skills for today’s market. I sense the commenter intended the former, as the latter doesn’t seem worth mentioning. Either way, my opinion is the same.

For most cases, my answer on whether they could get hired today is ‘Probably not’.

This is not to say that the class of ’04 or even 1994 were lesser engineers upon graduation, and those critical of our increased reliance on tools will make arguments to the contrary. The résumé of the typical ’04 grad would have difficulty getting interviews when pitted against today’s graduates, based on ’14 trends for entry-level candidates. Entering the work force with some level of perceived accomplishment (via internships or personal projects) is becoming a rather reasonable expectation even among average tech employers, to the point where graduates that lack experience or tangible evidence of their ability openly lament their (mostly irrational) fear of being unemployable.³

If we look at the difference between these graduates of ten years apart, we discover how quickly both available resources and industry expectations have changed. How would ’04 grads fare against today’s candidates? It’s interesting to explore how different things were.

How did they learn to code? How much ‘experience’ do they have?

It sounds kind of odd to me, but someone as young as 35 might not have seen a decent web browser until college. The class of ’04 hit puberty when Windows 95 was released, were likely to reference books/manuals (BBS/Usenet perhaps), had limited access to like-minded individuals, and coded on machines dwarfed in power and memory thousands of times over by today’s mobile phone.

The class of ’14 had fully functional browsers and search capability by middle school, and relatively cheap computing power. It would have required unique circumstances for those in the ’04 class to enter college with coding experience, but many in the class of ’14 could have had exposure at a younger age. When I ask recent grads when they started coding, it’s common to hear “in high school”.

What did they do when stumped?

Volumes of reference material and educational content were available to the ’14 grads that were not in ’04. Stack Overflow has become the programmer’s best friend, and that best friend still celebrates birthdays at Chuck E. Cheese – it is barely five years old. ’14 grads could access answers much quicker than those from ‘o4, but many would argue whether that access over time makes for better engineers.

The class of ’04 grew up with search engines too, but how much relevant content was there to search? And how difficult would it be to actually find that content given the search engines of the time? The need for trial and error is dying, and it’s reasonable to assume that death hastened between these two graduating classes.

How did they differentiate their ability from others when competing for jobs?

You’ve got a pretty solid GitHub, eh? ’14 graduates could browse and contribute to thousands of open source repos and create their own all through college. GitHub obviously wasn’t the first destination for repos, but hiring managers didn’t usually ask to “see your SourceForge” in ’04. The ease and expectation of showing past code to hiring entities is a relatively new concept.

It’s become normal for many grads to have blogs, robust sites, or even a mobile app or basic product when entering the workforce. The current boot camp trend produces graduates that usually claim an app. Apple’s App Store had 500 third-party apps around launch in 2008, and now between Apple and Google there are nearly two million. How many of those were developed for the purpose of job hunting?

Websites and blogs were more difficult to publish and expensive to maintain before the recent trend of free hosting and tools. It was uncommon for entry-level candidates to list sites or blogs on a résumé ten years ago.

How do they look for jobs? Did they even have to look?

If we are going to compare the ability for two graduating classes to get jobs, we should consider that methods to hiring and job search have also changed dramatically. Job boards like Monster and Dice existed in ’04 to post a résumé, but were primarily used by the most active job seekers and not for passive/ongoing job searches.

LinkedIn can help to both find people and then store contacts, with the added bonus of making users discoverable to potential employers – but LinkedIn only became available in ’03. Networking just a decade ago was more time consuming, while internships have become the norm for engineering students in recent years. Today’s graduate often has made at least a few potentially valuable industry contacts to use during a first job search.

Even if you were to get an interview in ’04, you went in blind. The amount of information regarding the interview process at a variety of companies is abundant, from best-selling interview question books to sites like Glassdoor. Job search has undergone quite a facelift, with unlimited supports in place to help job seekers identify interesting employers, demonstrate skills, and succeed in interviews.

Conclusion

Without trying to get into any debates as to whether colleges are producing better or worse engineers than they were ten years ago, it would be very difficult for ’04 grads to compete with ’14 grads in today’s market based on evolving expectations and changes in what CS students do during college. What might the résumés of CS grads in the class of ’24 look like?

¹ The shorthand ‘sub‘ is short for ‘subreddit‘, which is the name Reddit uses for various channels or forums.
² For the sake of transparency, my age is closer to the college class of ’94.
³ Source: see perhaps 25% of the posts at that same Reddit forum)