Fabulous Adventures In Coding
Eric Lippert is a principal developer on the C# compiler team. Learn more about Eric.
Today I want your insights, opinions and advice.
In any large organization over time people are going to move around within that organization, or leave it for various reasons, and therefore sometimes you need to bring in fresh new people to fill the gaps left by the attrition. Over my sixteen years in the Developer Division at Microsoft I’ve seen numerous understaffed teams working on great technology; it is almost always a struggle for them to find, attract and hire talented developers.
My two questions for all you professional developers reading this are:
(1) When you read a job posting on a career site, what are the things you look for when deciding whether you’re interested or not? Are there “red flags” that immediately make you unlikely to follow up? Are there more subtle indicators that discourage you? What encourages you?
(2) What would you find particularly attractive or unattractive about an opportunity to work on a developer tools team? (at Microsoft or elsewhere, though I am particularly interested in “at Microsoft”.)
Note that I am particularly interested in your opinions on software developer positions; if you have insights on attracting people to program management, quality assurance or user education positions I’m happy to hear them but I’m more interested in developer position factors today.
I certainly know what my answers are to those two questions, but I already work here and I might be atypical. I’m interested in what your answers are. Please leave comments!
Things I would look for when considering an opportunity to work on a developer tools team:
* High project visibility and impact, e.g., working on a compiler or IDE that would be used by thousands or millions of developers would be a huge thrill. Working on a GUI for editing some XML format used by a few random customers? Could be interesting, but most likely less thrilling.
* Interesting problems on which to work. I'm sure "Interesting" has lots of definitions, but perhaps "problems that have been solved a small number of times before, and in varied circumstances" comes to mind. Of course problems that have never been solved before could be interesting, but also could not (they may be unsolved because they are not useful or interesting to solve). Or perhaps "variations on hard problems with some existing clues for solutions"...
* Whether the team's environment has a technical focus, e.g., working on tools to support a non-tech business' software development department is not as desirable as working at a technology company, where the business drivers are directly related to one's work.
* Technical virtuosity of the team: working with great people who can raise the bar for almost anyone and who can do great work. There is something to be said for being a big fish in a small pond, but it gets old quickly. I'd much rather be the small fish in the big pond (with plans to become the big fish in the big pond).
* Openness of the organization: It's cliche, but software engineers prefer freedom, egalitarianism and flat structures, right? They want to be trusted, and the best are eager to show that they can be trusted to be excellent decision makers and problem solvers, and be team players.
* Regarding Microsoft: For some reason, the one thing I can't get past is using backslashes in filesystem paths. I've been wanting to get this off my chest for a long time. I often hit "enter" when reaching for the backslash key, sometimes with frustrating results. I know the Windows API supports forward slashes, but most everything above the API level seems to be written with backslashes in mind. Do we really have Tim Patterson to thank for this?
I thought about it on my way home and I feel bad about criticizing MS for backslashes. It's totally unrelated to the topic at hand. I apologize. C# is a great language BTW. Thank you for making my daily work over the past eighteen months significantly more enjoyable.
My (overly verbose) two bits:
1) Things I care about: sense of developer autonomy (can I get things done without a micromanager or political/bureaucratic grief?), talented peers (I want to learn from those around me, not just take orders from those above me), flexibility of hours, and most of all the ability to learn and solve new problems, not just maintain someone's codebase. Most developers like to create more than they like to fix (in terms of sense of accomplishment). Back when I was looking, job postings that emphasized these things in some way went to the top of my list, regardless of the company's actual specialization, because I knew they would be potentially challenging and fun places for me to work.
On the other hand. . . like everyone else has said, "tech vomit" postings are a turn off. It's usually clear if HR or a tech person wrote the post, and whether they know what they're looking for. Lack of problem definition also doesn't help either. If I can't remotely answer the question "Why does this company need me?" then chances are they really don't. I also avoid posts with the following blurbs: "heads-down coding", "hit the ground running", or anything else that conveys urgency or immediacy, especially if they want someone totally immersed in a single tech. It also suggests they are behind project schedule and need coding grunts who've yet to burn out (cf. Brooks' law about manpower and late projects).
2) Writing dev tools would be akin to a dream job for me, but I feel like I have a lot to learn before I'm there. I am currently designing a framework/API for my current employer, and it's a humbling experience sometimes. I love coding in general but I definitely enjoy creating things that make a developer's life easier; usually you can make a good product when you know your customers well, and in this case your customers are other developers. I feel their pain more so than business customers and tend to be more excited about solving their problems. It's a unique set of challenges for sure, so I guess if I were at MS looking for this type of developer, I would probably create a posting that emphasizes those things. I would also emphasize the kind of talent developers would have the opportunity to work with and learn from. I mean, I read this blog (and others) frequently, so I can't fathom how much I'd learn if I sat in the same room as Eric and others for 8 hours a day or more. My brain would collapse from overload.
My pet peeve about job ads (and I mean mainly internal ones here) are ads that say "Wanted rockstar developer" or "we only hire the very best", "only very strong applicants need apply" blah blah. I'm looking at a dev div job (say), I know you have high standards, enough with the ego trip in the job spec. It says more about the author fo the spec (arrogant, egotistical and lacking common sense) than it does about the role.
A good job ad tells me about the team, the size, any major processes they use, the near and mid term goals, something about the mission of the group and who the mangers are. It should tell me any must have requirements too. You can leave out the "nice to have" items, you know those and can apply them when you triage applicants, as an applicant I will ignore it if I don't have it, and if I do have it I will be too busy targetting my resume at the "must have skills" to go in to any detail on it. It should also indicate what you expect of the applicant once in the role. If you can't be 100% clear about want you want I'm going to assume you are a second rate manager and not bother applying.
I apologise in advance for the unhelpful comment:
@Pbh I'm laughing so hard at
"its kind of like working on quantum field theory vs black holes in theoretical physics, the latter having more visibility"