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!
I'll preface my comment by stating that I usually look at job postings for in-house IT. I don't know how different it is working for a software development company.
What I typically find discouraging are job postings that emphasize experience with a wide variety of technologies. I've seen some postings that have such a range of "required" skills that I don't think there's a single person qualified. These postings make it sound as if they aren't considering the technical prowess of the applicant. As Joel Spolsky calls it, the "special part of the brain that they're going to need to do great programming work." Instead, they only seem interested in whether you've worked on a project that used Python for at least n years.
I once saw a job posting that required "five years experience working with ODBC". Seems reasonable, right? This was in 1992! I had actually just received the first version of the ODBC developer SDK and was in the process of writing the ODBC driver for WATCOM SQL (now known as Sybase SQL Anywhere I believe.) The ODBC dev kit had been available for I think a couple months when I saw that posting. Recruiters often don't know anything about the actual technology, its history or context; they just know they need a dev who can understand "ODBC", whatever that is, and write the posting. -- Eric
In my experience, the quality of programming of a top-notch developer who used technology X once or twice is still better than that of a mediocre developer who's been using technology X for years. When I see job postings that so emphasize particular technologies, I feel so threatened by the need to explain to the recruiter that it isn't as important as technical aptitude, that it discourages me from applying.
I strongly agree. However, there is a flip side. Once, many years ago I interviewed a guy who had nothing but machine vision on his resume; that's what he had done his masters research on and what he'd worked on in industry. Now, I agree with you that this demonstrates ability to learn about a particular topic deeply, and we certainly need that skill on the language design team, so I was very glad to get this candidate. First question: "I see you have a lot of machine vision experience, and I'm very interested in that topic so I'm looking forward to talking to you about your work. But I've got to ask, why are you applying to a compiler team?"
His answer: "I have no interest in working on languages. The Microsoft Research team that does machine vision isn't hiring right now, so my plan is to get a job working on something else for a year and wait for a position in the machine vision research team to come open. Then I'll transfer over there."
I was stunned. I mean, A+ for honesty, but NO HIRE for my team. Hiring people, ramping them up and getting them productive in a complex existing codebase is very expensive. We need a team member who is going to be engaged and interested for the long term, not someone who is just wasting time and drawing a paycheque until something better comes along. -- Eric
A very interesting question. I think to your first question, what attracts someone to a certain advertised position varies tremendously based on what one is looking for in a job and so there is no globally "right answer". For someone like me work is an important part of life (40+ hours/week) and so I want to ensure that what I do is 1. Technologically beneficial to society at large (the more it "changes-the-world", the better it is), 2. Challenging (the more innovation in the space the better because you get to learn more) and 3. perceived culture of the organization (does it sound like the company in question does not think culture is important by not talking about it in their ad?)
As to your second question, developer tools is tricky business. One does not necessarily see the product being utilized by your everyday man and so that sense of your product being life-changing is limited as opposed to say working on the iPhone (its kind of like working on quantum field theory vs black holes in theoretical physics, the latter having more visibility). At the same time, atleast in my case, because your target audience/customers are seasoned technologists and developers the challenge of delivering something that can be quantified as an excellent product is even higher and therefore so is the satisfaction (not to speak of the fact that your customers can understand the nuances of the problems you faced while developing the product, as evidenced by this blog). Also I feel that working on dev-tools also allows you to interface with academic research more so than working on enterprise software.
One of the first things I see that discourages me is a posting that includes "technology vomit", a list enumerating every technology known to man. Postings like this indicate to me that the company doesn't have a clear direction for how technology fits with its overall goals. Also, for technical positions, familiarity with word processors and spreadsheet editors should be assumed, so when a job posting for a technical position mentions that, I start to wonder. I also like a posting to indicate focused responsibilities. This is more difficult for smaller companies where one IT person may be the developer, network admin, and help desk.
Alphabet soup discourages me as well, both when I see it in a job posting and when I see it in a resume. -- Eric
All of these things are akin to code smells. I don't immediately shut down, but I start to look for other signs of concern.
I will also second both Rick Pocklington and Pbh. The most important thing any engineer can have is problem solving skills. The ability to learn and understand languages and tools depends on these, as does the ability to guide a project through its lifecycle.
When we interview job candidates here, we do ask questions about certain technologies that are important to our methods as a starting point, but our most important questions are puzzles and riddles because those are much more difficult to be prepared for. We aren't necessarily even looking for people to get the right answer, we are mostly watching how people reason through them, because that is more important than correctness (in an interview anyway). Its much easier to show someone an error in their reasoning than it is to teach them to reason better. As a candidate, I look for companies that think along similar lines.
We used to do that at Microsoft, for similar reasons. This is not encouraged anymore, for several reasons. First because we've become famous for such questions and people are showing up prepared for the old chestnuts. Second, many of these puzzles have "aha!" solutions; I'm not interested in whether someone can come up with the "out of the box" solution. Rather, I want to know if they have a grasp of the tools that are already "in the box", since those are the tools we actually use 95% of the time. And third, I can learn about people's reasoning skills by watching them analyze real code, rather than inferring their code analysis skills from their ability to divide matchsticks into three piles with an odd number in the first pile... etc. -- Eric
I also would like to work for a company with more "visibility" and be surrounded by people who are capable of doing great things. They are the people I want to learn from, and right now, I have to do it through blog posts, magazine articles, and, in some cases, forums. Being able to work with such people directly is an advantage that Microsoft has that not many other companies can claim.
I think working on developer tools at Microsoft would be a very interesting position, and am surprised that there is difficulty in finding candidates*. I expected that people would be knocking the door down. I, for one, would love to work there (especially on dev tools) because it does provide the opportunity to solve challenging and interesting problems. I know the "Developers, developers, developers" mantra has been blasted, but that mentality is especially appealing to me (a developer, duh). MS gets knocked around for a lot of things, but the one thing I don't think can be argued against is that the products are almost always top notch, inside and out. The business value may be primarily on the outside, but the problems I find interesting are usually on the inside, so working somewhere that does both well is an especially appealing idea.
*Out of curiosity, is the difficulty in finding candidates or in finding good candidates?
There's no shortage of candidates, the vast majority of whom do not make it past the initial phone screen.
Thanks for your thoughts and kind words. -- Eric
1) Whether or not they have the slightest clue what they want to hire me to do.
When the posting has a large set of skill requirements and no mention of what they want those skills for, it's pretty obvious that they don't have the slightest clue what kind of a developer they're looking for. I'm not likely to chase that one down very hard. When there's a small skill set requirement and actual mention of specific teams or products that they want someone to work on or with, then it gives the definite impression of there being specific work that needs doing.
I'm not interested in being hired for headcount, I want a job to do. The more specific they can be about what job they want to hire me for, the more interested I am in chasing that job down.
Another big factor would be the software development methodologies in place. If they're looking for someone who already knows unit testing and is familiar with agile software development practices, then I'm highly interested. If I have to tell them what TDD is and they don't even know that they're using waterfall development, then they're going to the bottom of my list.
Call it "evidence of structured development practices" (or lack thereof), it's a big flag.
2) I would be thrilled to bits to work on a developer tools team, period and end of story. It's what I usually do, but I'm typically the only guy on the team. Actually having other people on the team would be great. So the #1 attraction would be the existence of a team that I could join. Since the collaborators are the attraction, the better that team is the more interested in the position I am. Equivalently, if the team is a bunch of cowboys, then I'm less interested. Although I can't imagine how any company with a whole team just for toolmaking could have a bad team. Doesn't mean it couldn't happen, just that the mere existence of the team is still a positive even if the team somehow doesn't seem all that impressive.
I have been a consultant for over 25 years, so my focus is always on contract positions rather than direct/fulltime (formerly known as permanent) positions. This may have an influence on my "thought process".
Like the others I cringe when I see "technology vomit". If I were to include ALL of me experience (I have actually been programming for almost 38 years!) I would not have a resume, I would have a fairly large book.
What I tend to look for most are the clients who fall into one of two specific areas [I work across most vrtical markets except for gaming]...
a) They have a specific problem and are looking for a resolution.
b) The are interested in a new technology, process, etc. and are looking for guidance. In other words "They know that they don't know what they need to know" [my apologies to those for whom English is not a first language]
I know that's confusing, but don't you see what's happening here? You and me, we're pawns in this ugly little game. lf you love him, if you really love him, then just keep on loving him. Never let him know that you know what he thinks you don't know that you know. You know? -- Eric
Both of these are VERY hard to discern from the vast majority of postings.
For jobs far from where I live, if a position does not allow telecommuting, I immediately discard it. I don't understand why more programmer positions aren't completely work-from-home. I feel very limited to programming positions in my area because I never see positions that don't require a person to be in the office every day.
The main kind of programming I would be doing and the languages used are the most important after the telecommuting option. I prefer doing web work, and I have a subset of languages and frameworks with which I'm most happy.
On question 1: Maybe this would exclude me from the type of developer you are looking for, but as much as I love programming, it's not my first love. So I'm always looking out for explicit or implicit suggestions that "you must not have a family / hobby / church life / etc. to succeed at this job." Occassional all-nighters & extra-hours -- of course. And keeping up-to-date on your own time by reading books? Expected. But, at the end of the day, it's a job, and must fit into life according to one's priorities.
You say you get lots of candidates, just not good ones. That might just be because MS is no longer considered to be a place where good/ambitious people go to work. The last ten or so years have been a long run of difficult press, no stock growth, (recently) layoffs and some pretty awful product releases.
Even devdiv doesn't look, to me, like it's well-run from the top. There are some glittering nuggets (and C#/CLR is one of them), but much of the rest is a shambles - look at VS - personally I wouldn't want to be anywhere near the kind of hell-storm which must be surrounding that project right now, even if I was hired onto a different team initially.
I think you are massively overstating the problem. Yes, some aspects of this release cycle were a little bumpy, particularly around the performance characteristics of the CTP releases. We're working to address both the specific technical problems and the "process" shortcomings which led to the problem. From my perspective, this release has been not particularly better or worse than others. (For example, getting through the "bug tail" on the Whidbey release was a very long slog.) Shipping software of this magnitude is a hard problem no matter what team you're on; what matters is how well management addresses the problems when they occur. I don't expect perfection; I do expect professionalism, and I feel comfortable with the level of professionalism I've seen. -- Eric
Let me add my vote for over-specific requirements as a turn-off. However, there is more to development than general problem-solving skills. Applications development is very different from systems development, which is different from language/compiler design, etc. It's a good thing when people ask for domain or category experience.
Also, it's a little discouraging (but hardly surprising) the importance a lot of companies place on one's college degree and class standing, especially for senior developers. Especially discouraging for me, since I don't have a college degree: I didn't need one in the 80's when I started.
It's extremely irritating to say say right upfront that you don't have experience X (but you're willing to learn), go through the entire weeks-long interview process, and then get rejected for not having experience X. That happened to me the one and only time I interviewed for Microsoft, and why I wouldn't apply there again.
I had little desire to interview with Microsoft after reading "How Would You Move Mount Fuji? Microsoft's Cult of the Puzzle".
Though I enjoy William Poundstone's writing, I was struck when I read this particular book just how out-of-date it was. As I said above, I know no one at Microsoft who still uses these hoary old brain teasers as interview questions. They do a bad job of testing for skills that I am actually interested in, like ability to debug existing code efficiently and effectively. -- Eric
Agile teams are attractive to me. A recent podcast interview with a Microsoft employee made it sound like TDD is still the exception rather than the rule at your company.
Generalizing from one employee out of 90000 is perhaps a hasty generalization. There are some teams that are full on scrum-meeting-every-day test-driven-development agile, and there are some that are very traditional waterfall model. Microsoft is not a monolithic entity where one size of solution fits every development problem. It's more like a collection of mostly-allied fiefdoms where each particular team sets its own working style based on what works well for the product and the employees. For example, the XBOX dev tools team is on a strict "every thirty days" ship cycle, which works well with a scrummy agile style. But that would be ludicrous for, say, the team doing research on programming language asynchrony. -- Eric
for me, i like to know that the programmers are largely shielded from non-programming aspects of a job.
programmers like to program!
not only are non-primary aspects of a job demoralizing over time, they can have quite the negative impact on concentration and productivity.
another aspect for me is flexibility. while i can see that some there should be some "core" business hours for a team to all be around (some 3 hour chunk in the day maybe), the rest of the time should be pretty flexible. not everyone gets into their natural zone at the same time.
as for Microsoft specifically? i have a fear of inflexibility and lots of corporate/political baggage - both as an overall layer as well as inter-team infighting, turf-wars, etc.
it could be completely unfounded, but that's a general fear i have about any large company.
@Sarah - Although I have done many tellecomute projects (acroos the USA, and from Germany to Austriala (the long way), my experience is that this is rarely effective in many areas [but by no means impossible]. While LiveMeeting, etc. can address many of the issues, so much of the the project dipically tepends on ad-hoc meetings of the team members in a fc-2-face situation
@Dave - "It's not just a job, it's an Adventure"...but I do get your point. My experience is that a top developer needs to spend 15-20 hours per week if they are to keep current [over and above the "paid hours"]
@Will - I worked for MSFT (specifically MCS) for two years [2005,2006]. It was a great environment (however the extensive travel brought work/life balance into a near crisis. The days (as an MVP for 2008,2009,2010) I have to same that my involvement with DevDiv has been an excellent experience. This applies all the way from the top to each of the teams I have been involved with.
Eric, nice on the Sneakers quote. I've got to see that movie again.
Quite frankly, I rarely judge a job by its HR description. My first consideration for a job is whether I would want to work for that company. Then I think about the project. And then I think about a few things that matter to me that are personal preference. But I've seen job postings that sound horrible that I know actually describe pretty cool jobs. Doesn't mean I wouldn't apply for them.
As for the requirements, I figure you've just got to read between the lines. If you have real experience, you will be considered, unless you get unlucky. If not, then you will be considered, if you get lucky. What the experience is (or isn't) actually doesn't matter much.
(1) What encourages you?
- A Team that shares my passion for software development
- People on the team that I know I can learn from
- A Project that I know can have a larger impact
(2) What would you find particularly attractive or unattractive about an opportunity to work on a developer tools team?
- Being at MS that in itself would make it attractive, the scope of the project is as large as it can be for that area
As a (very) junior developer who walked very much sideways into the career:
1) Fear of being blitzed way above my level of knowledge.
2) Somewhat a secondary to the first; lack of recognition that experience and knowledge don't just magically appear. Some of the juniors you're interviewing haven't been in the job for very long, and if they happen not to be computer science graduates, won't know stock answers to fundamental questions. They're the sort of thing you work out as you go along, or look up. I'd like there to be some demonstration that the ability to adapt, learn and improvise is important to the employer.
Then again, if those are my issues, perhaps I'm not the sort of person Microsoft are after.