Archive
My Cover Letter Approach
As I’ve been involved in my search for a new role, I’ve taken several different approaches to cover letters. I’m going to outline what I am currently doing and my rationale for doing so.
One of the challenges of preparing resumes or cover letters has been the depth and breadth of my experience. I spent time as a long term engineer, as an engineering manager with a high percentage of hands on coding expected, and as an engineering manager not expected to code but to be firmly involved in technical processes and decision making. That can make things like “tailored” details on resumes difficult. I felt that it was difficult to adequately state what I perceive my value to be.
I wanted to arrive at a repeatable, scalable process that would take just a few minutes for each job posting. I wanted the documents I prepared to adequately represent my career and qualifications. I needed speed and ease as I, like many of my colleagues, cycled through hundreds of applications.
As of this writing, it’s up for debate if my approach will ultimately be successful. I do think it has managed to get the attention of quite a few companies that might not have otherwise noticed. Responses to those applications seem to be better. During several interview cycles my cover letter was referred to as a resource for the conversation.
There were several general sentiments I heard when this journey began. There was a predominant feeling that cover letters are never read. It was suggested that even though they weren’t read, they couldn’t necessarily hurt. They could be viewed as a tiebreaker should recruiters or hiring managers be choosing between strong candidates in this highly competitive market.
After a couple of weeks of choosing to ignore cover letters, since the prevailing wisdom is they were ignored, I actually decided to completely change direction. If cover letters are never read, except in rare instances, I could do what I want with them.
I chose to use my cover letter to surface all of the information I couldn’t fit on the resume I was including with my application.
I recognize this flies in the face of conventional wisdom, but, hey, if no one’s going to read it….
¯\_(ツ)_/¯
Thus, I went from no cover letter to a 9 pager that includes:
- Page One: A targeted cover letter, with mostly templated information, summarizing my career highlights and the value I bring. It contains a paragraph introducing me; a paragraph on my general philosophy; a paragraph on what I’ve done as a manager; and a paragraph on what I’ve accomplished as an engineer. Within two or three minutes, I can adjust content, add specific information, and optimize for the position I am interested in. A variation of that cover letter can be found here.
- Page Two: A portfolio of the websites, systems, and companies that I have had an impact on. Many times candidates are asked for this portfolio, and I automatically include it in my cover letter, just in case someone opens it and decides to scroll past the first page. That portfolio can be found here.
- Pages Three through Nine: A list of the critical projects I’ve delivered, and my role in delivering them, along with the results. I’ve missed a few here and there and update this list as I recall things. For example, in a recent interview I talked about a feature I built into one of my web portals that would include the entire logging history of the system into the web page, piggybacking and enhancing Microsoft .NET’s native tracing feature. I’m going to add that to the list soon.
Having the list ready to go gives me a couple of other efficiencies.
First, if a company doesn’t ask for a cover letter, and I really want to send one, I’ll simply include it as the first page of my resume by copying page one from here and adjusting it for those needs.
Second, I have my list of projects ready to go, already in consistent format with my resume. I then pick and choose the relevant projects from this list to include on the resume I will send based on the company’s requirements.
So, while I am tailoring my resume, I’m not rewriting narratives or reorganizing. I can be ready to apply to any position within 5-10 minutes with a consistent, complete narrative.
If you are also searching for a new role, I wish you good luck.
A fresh start in 2026
It’s a new day. It’s a new year. 2026 will bring a lot of changes, both personal and professional. I find myself with more free time than expected right now, and as a result I’ve decided to focus on re-engaging with the public.
I’ve spent much of the last 8 years working, growing, and becoming a better leader and teacher. I’ve spent time mentoring others to the point where I finally feel like I can do so without my imposter syndrome kicking in in full force. I’ve made a ton of friends along the way, relationships that will outlast changes in employment and location.
But it’s a new day and a new year. I’m in the process of updating my homepage and it’s accompanying blog. I’ve added an updated resume, including a portfolio and a project list. I’ve also added in depth descriptions of what I’ve done and been doing musically, and will continue to flesh that content out as I have time over the coming weeks. If you happen to encounter incomplete pages, don’t worry; they’ll fill out soon.
In many ways, one could say it’s a scary time to be putting oneself out there and expressing opinions or views or trying to educate. But the reality is, there’s no better time than now to engage. I’ve been focused inward on family and music and life for a long time now, and I don’t regret it at all. But perhaps it’s finally come to a point where the world at large might benefit from my perspective.
Or it might now. Time will tell.
Keys to a good technical interview
Hi there,
So you see these all the time, especially on job sites or on MSN.com. The keys to nailing the interview. I have a few myself, and I thought I’d share them with you all. Who knows, maybe it will help you when you are faced with the dreaded technical interrogation.
If you can’t explain it, it shouldn’t be on your resume
I realize that people tend to put everything on their resume that they’ve ever encountered, either at work or in the classroom. This certainly tends to make a resume more appealing, more engaging, and implies a breadth and depth of experience.
The problem occurs when the candidate doesn’t really know the skill they’ve listed, and are not prepared to discuss the skill or technology in depth. Let’s face it, if you can’t explain to me how to store someone’s name in a database table, you probably shouldn’t have any database technologies on your resume. And the same goes for web design or web development. If you can’t explain the basic functional tags of HTML, such as tables and divs, or you can’t tell me what CSS stands for (Cascading Style Sheets), anything related to front end web design probably shouldn’t be on your resume.
Be prepared for niche assignments to work against you…and prepare to counter it
If your work history is peppered with contract jobs, or your technical expertise is limited due to the type of work you’ve done, it’s probably in your best interest to be able to list on your resume technologies outside of your normal job functions. For example, if you have mostly been a Windows developer, take the time to learn Web development enough to be able to speak intelligently about it. If you’ve always been a web developer, learn basic database technologies enough that you can demonstrate that you can work with it, or at worst that you will be able to learn it quickly.
During the course of an interview, I will drill down to determine where the line in your technology stack stops, and where it stops will tell me much about what I perceive to be your drive to learn and excel at technology in general.
Be prepared to justify any technical decisions you reveal
I’ll be honest, I don’t necessarily plan ahead when I interview. Instead, I ask a ton of questions to get the candidate to talk…and let what they reveal lead to my next question. If the candidate reveals that they built an ecommerce site, I might start by asking what merchant provider they used, or how they maintained PCI compliance (the security standard for accepting credit cards). If the candidate mentions a particular technology concept such as MVC, I might dig into why they chose that over MVP or MVVM or standard Web forms architecture. Those answers will reveal the candidate’s true involvement in the project as well as how they think when they design and build systems.
Integrating third party tools is not enough
There are so many niche third party tools out there these days. JQuery for JavaScript, Lucene for full text searching, Twitter’s bootstrap for UI controls. But if that’s all you’ve ever done, that does not qualify you for a developer position per se. We’re approaching a time where people who are into development haven’t lived in a world without JQuery or some of these other tools. As a result, many times they can’t explain what JQuery actually is, or how it actually works, because they are so accustomed to the “magic” of it “just working”. I will take a candidate who understands the fundamental operational concepts of the tools they use over someone counting on “the magic taking over” any time.
Be prepared to honestly answer “I don’t know”
Without a doubt I will stump you somewhere. Well, almost without a doubt! There is no developer on the planet who knows everything, and how you handle your lack of knowledge is just as critical as what you know. If you can’t admit to not knowing, and attempt to answer with a best, perhaps informed perhaps not guess, I’ll likely recognize that for what it is and that will be a point against you.
Bring your success stories, in particular crises or major problems solved
Everyone who has worked in this industry has battle stories. I have a list longer than I care to mention, including the day a single bad value passed into one of our web pages hung 14 million queue messages on 20 servers on a Monday morning. It took me 36 hours (straight, no break) to fix it. That is one of many stories I could tell during an interview about something I’ve faced that was difficult that I solved. Bring yours. I’ll likely ask you if you have any moments in your career that you were particularly proud of, and if you don’t have any, I will wonder how much troubleshooting you’ve done and how many roadblocks you’ve managed to push through.
Communication is key
Be able to communicate clearly and concisely. But more importantly, show that you can communicate with others. Many times developers are working with product managers, general managers, designers, marketers, and others. A good developer is able to communicate effectively with all of the different types of people they will encounter. Indeed, fleshing out software requirements, getting clarity around what needs to be done and what use cases might exist, are all part of what will set a candidate apart.
Be welcome and true.
Rob Hope 