Last month, discussing the habits that developers should cultivate that will keep them employed, I emphasized aspects that were visible outside your current employment. But the easiest way to stay employable is to be highly valued at your current job; believe me when I tell you that searching for a job is vastly more productive when you are not in financial peril.
Before I turn to those aspects, though, I’d like to talk about a fascinating data point from Aline Lerner’s “Lessons from a year’s worth of hiring data”: spelling and grammar mistakes in your resume and initial communication matter more than anything else in predicting whether or not you’ll receive an offer. Proper English is more important than your GPA, the prestige of your college, or even previous employment at a top company such as Google, Apple or Microsoft! Perhaps more precisely, improper English is more damaging than other weaknesses. And although I have not seen Lerner’s data, I am confident that the grammatical errors are not esoteric ones, but mistakes of tense agreement, inconsistency in pluralizing, and homonym swaps such as its/it’s and their/there.
One costly mistake I see in lots of resumes and CVs is inconsistency in formatting lists and sections. You would never submit sample code that was inconsistently indented, had improper line endings, and used inconsistent bracketing and whitespace rules. Yes, it’s time-consuming and frustrating to manually tweak the beginnings and endings of every section and bullet item so that they are consistent. But what does it say about your programming discipline if you do not take that time?
Unfortunately, I can’t offer you the assistance of SD Times’ editorial staff, who save me from embarrassment every third sentence, but you can hire a well-reviewed copy-editor on Upwork for around US$60 an hour. That’s a trivial price to pay for the single-biggest determinant of a job offer.
Bottom line: There is no more shame in making a grammatical mistake than in making a coding mistake. The shame comes if you don’t care enough about quality to have a system in place to catch it.
Most analyses of hiring show another strong factor, which is the ability of the candidate to make money. The relationship between an individual developer and revenue is usually pretty tenuous, but the equivalent attribute is when a developer is associated with shipping projects. In a real sense, no software is ever finished, but gaining experience in delivering value to end users and focusing on customers—not code—is the software development equivalent of being a “closer.” Coffee is for shippers.
Bottom line: In your resume and during interviews, don’t dwell on your unfinished work, no matter how interesting or cutting-edge it is. The game framework in alpha is the 21st-century equivalent of the novel in the top-drawer. Instead, emphasize how your code has delivered value to real people.
Especially in high-tech hotspots such as the Bay Area, hiring managers have been scorched by turnover. Time-to-first-check-in is often weeks with new developers, and it can be months before someone fully understands the project and its context and starts to contribute at their full potential. But with salaries continuing to rise and career-growth expectations distorted by a combination of an industry boom, the youthful age distribution of programmers, and competition for talent, there’s no gap between the thought “This person has great talent!” and “Will this person leave us after a year?”