This is the blog of Adam Kalsey. Unusual depth and complexity. Rich, full body with a hint of nutty earthiness.

Business & Strategy

How not to apply for a job

Say you’re a developer who’s in the market for a job. You come across a job listing, perhaps something like the one I recently posted. It’s a job you’re interested in and you send in your resume. Here’s what not to do.

A cover letter is not just a standard part of your resume. A cover letter is designed to highlight the parts of your experience that are specific to the job to which you are applying. It’s supposed to be the thing I see first and should draw me in, making me want to get the details from your resume. Don’t stick your cover letter in an attachment and your resume in another attachment or your cover letter might not get seen. It’s certainly not doing its job, hidden in an attachment like that. If you are sending a resume by email, your cover letter belongs in the body of your email.

You need to proofread your cover letter carefully. This is my first introduction to you. This is your chance to impress me. If you have sloppy spelling, capitalization, and spelling in your cover letter I’ll expect that your code as the same sort of problems. I’m not looking for Pulitzer-prize-winning stuff here, but most kids learn in first grade to capitalize proper nouns and the beginnings of sentences.

Your resume should tell me what languages you know, what technologies you have experience with, and how you’ve applied that experience. Unless you’re applying for a job as a secretary, you don’t need to tell me you’re proficient at MS Word — if you’re a software developer, I assume you’re familiar enough the basic workings of a word processor to use it to open a document and read a spec. Do tell me what sort of systems you’ve built and what challenges you overcame while building them. Do tell me how you applied your knowledge of efficient database operation to decrease server load by 30%.

When I look at your resume I should get a sense of what size projects you’ve worked on. If you’ve worked with an internationally-known company, then I immediately understand you’ve had exposure to larger projects. If all of your experience was at no-name companies in North Dakota, then you need to tell me that the project you worked on had 15 developers and an annual budget of 3 million dollars. Otherwise I’m likely to think your prior experience was building simple ASP front ends to little Access databases.

And finally, follow the directions for applying for the job. If I went to the trouble of describing how you should apply, there’s probably a good reason for it. If I ask for a plain-text resume, don’t send a Word document or a link to your resume on your Web site. If I ask for a code sample, include it. If you can’t follow those simple directions, how can I expect that you’ll be able to follow a spec?

I don’t even look at those emails I get with Word attachments, no code samples, no information about availability or your location. I simply file them away in case I ever have a need to hire a developer that doesn’t know how to follow directions.

Recently Written

Your OKR Cascade is Breaking Your Strategy
Aug 1: Most companies cascade OKRs down their org chart thinking it creates alignment. Instead, it fragments strategy and marginalizes supporting teams. Here's what works better than the waterfall approach.
Your Prioritization Problem Is a Strategy Problem
Jul 23: Most teams struggle with prioritization because they're trying to optimize for everything at once. The real problem isn't having too many options—it's not having a clear strategy to choose between them. Without strategy, every decision feels equally important. With strategy, most decisions become obvious.
Behind schedule
Jul 21: Your team is 6 weeks late and still missing features. The solution isn't working harder—it's accepting that your deadlines were fake all along. Ship what you have. Cut ruthlessly. Stop letting "one more day" turn into one more month.
VC’s Future Lies In Building Winners
Jun 21: AI and megafunds are about to kill the traditional venture model, forcing smaller VCs to stop hunting for hidden gems and start rolling up their sleeves to fix broken companies instead.
Should individual people have OKRs?
May 14: A good OKR describes and measures an outcome, but it can be challenging to create an outcome-focused OKR for an individual.
10 OKR traps and how to avoid them
May 8: I’ve helped lots of teams implement OKRs or fix a broken OKR process. Here are the 10 most common problems I see, and what to do instead.
AI is Smart, But Wisdom Requires Judgement
May 3: AI can process data at lightning speed, but wisdom comes from human judgment—picking the best imperfect option when facts alone don’t point the way.
Decoding Product Leadership Titles
Mar 18: Not all product leadership titles mean what they sound like. ‘Head of Product’ can mean anything from a senior PM to a true VP. Here’s how to tell the difference.

Older...

What I'm Reading