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!
(1) I look for the basics (company name, location, technical requirements), so I can research the position. The "feel" of the posting is important: if it's too stuffy, I will avoid it. If they stress years in service or a plethora of certifications, I shy away.
(2) The most attractive part would be the challenge. Coders can be a very picky lot when it comes to the tools they use. It would be fun to work against a tough audience.
Why is it questions like this get so much response, even from those of us who haven't been in the job market for awhile? ;)
As it happens, I've been hiring myself as our group has been growing at a rapid pace. I agree with the idea that the technology requirements be tightly focused on what the candidate is actually expected to know coming into the position. By the same token, as a reviewer of resumes I always look skeptically on a technology stew. Focus your resume on what you know best.
Now here's my perspective on the things I'd look for in a good candidate:
1. An ability to solve problems. We don't have "puzzlers", but use basic programming questions on our tech test.
2. A thirst for learning and self-motivation.
3. An ability to get along with other people. In some work cultures, that isn't an issue, but ours is extremely team-oriented.
4. Integrity. Our interview questions try to draw out a candidate on experiences that had both good and bad outcomes. A red flag goes up for me if a candidate is unable to give a good example of a project that didn't go well for him/her. They aren't being honest.
And here is the top question from a candidate that raises a red flag for me:
1. What is your work from home policy?
As a candidate, here's what I would look for in a company. And I'd either looks for clues of this in their posting or draw them out on this during the interview.
1. A company that is interested in telling me about what they do. I had one interview several years ago where the interview started immediately with technical questions. Needless to say the interview went poorly for both parties. I concluded right then and there that they were either too stupid or too arrogant to sell me on them. Fail.
Another example is an interview where I arrived and the interviewer had clearly not even looked at my resume before I arrived (even though we had a scheduled appointment). He also yawned a minute into our interview. I thought, "WTF, dude? What am I doing here?" Again, fail.
2. That they are committed to investing in you and your growth. Are you a hired hand or are you going to participate in the growth of this company? In my current situation, this is definitely a negative. I just sat in on a manager's meeting where our top manager extolled all the training opportunities the company offered. Guess what? All those "training opportunities" are focused on management. I have been with this company for four years and the technical training opportunities have been minimal at best - stuff like, Introduction to SQL Server. And yes, this is something I complain about regularly - to no effect.
3. Work that makes a difference. This is a value call, of course. But you have to believe the work you are doing is good and inching our evolution along in a positive way. Does the job posting reflect this?
4. Work that is challenging. One of the key attractions of software development is that it never gets boring, that are always new problems to solve. If you don't see the potential for work that engages your curiosity and desire to learn and explore, then I would think twice about taking the job or inquiring about the job posting.
Oh, yeah, and ditto the comment that MS has a big leg up on most companies given the people who already work there and are well known to the developer community. Who worth his salt wouldn't want to work with Lippert, Hanselman, Guthrie, Nick Allen, Kim Cameron, and so on? ;)
1) As others have mentioned, I avoid the openings that have an endless string of acronyms in their list of requirements or the ones that go to other extreme and are vague about their needs. Also, the thought of having to go through multiple gatekeepers before speaking to a tech person gets tiring sometimes...especially if there is a large pool of candidates applying. Years ago, I remember talking to a temp agency rep who said that whenever he posted a tech opening online, his office would get flooded with 200-300 resumes within two days. Those seem like awfully long odds to me.
What would be encouraging is to see an opening that is willing to let the candidate continually grow/learn. Stagnation will cause me to disengage rather quickly.
2) I applied to Microsoft years ago, but never heard back. I think it would be great to work on the developer tools team...although I think I have a strike against me because although I have a degree, it is not in Computer Science. I'm also not all that great at articulating my abilities in an interview situation or on my resume, and when it comes to programming, I'm heavily self-taught. So how do you portray that in a positive light and convince a company to take a chance on you in this economy? Anyway, I plan on shipping a 3-D game/game engine sometime within the next year or two, along with related tools. So either way...whether here or there...I'll ship software.
And, as someone else mentioned, it's important to show the "value" of the role in the job description. I mean, if you are going to be working on a piece of software that no one is really using...what's the point?
1. If it is sufficently technical with little commerical aspects, especially with references to niche fields or working with people that write books/blogs I'm following.
2. Moving to the US is the unattractive side of the equation, however I don't see that many options in Europe for these kind of projects.
I didn't quite answer the question about what I find attractive.
What really attracts me in getting a job at MSFT DevDiv is the amount of high-profile professionals. Microsoft employs some of the best software engineers on the market, and having the chance to work with some of them and learn from them is something that would be invaluable for my career.
My current role in our society is to be sure that the latest technologies are available for the average computer user in the form of new and exciting products.
Working at MSFT would mean going deeper on this, and be part of the process that creates the latest technology.
That's something that attracts me.
I am a developer and have been one for the last 8 years. I love what I do, I get rave reviews all the time about my work. But I have never applied to Microsoft after college because the job descriptions scare me off.I always have this feeling that a large organization has most of its practices already defined. I have found that I have my own unique way of understanding things, my own way of doing things. The descriptions dont tell me how creative I can be.
Second, in college, when Microsoft came to my campus, only people with the highest GPAs even got through to an interview. I totally disagree with that because GPA dont indicate how good a person will be in the workplace.
What really attracts me is the technology - that I can get to know more about how things I work with actually work themselves.
As a developer I personally always sought to have the opportunity to spend time developing tools for developers, and not have to justify it in terms of line-of-business. In 2002 I built an ORM that we called Object Space (named after a hanging project from MS ;-)), and it was pretty powerful, generating IL from the mapping file, loading complex graphs in O(n) and keeping track of entities for insert-update-delete operations. It's still in use today in a large financial solution sold in Montreal.
Since then, I've always been frustrated to not have the opportunity to work on tools like that. Each time we select a tool for an LOB project, I feel like I should have built it myself.
The kind of offerings you propose are inherently attractive for someone like me, and I'm not the only one. Even though I have my own company today, it's a partnership and we still have constraints in terms of what we should or shouldn't develop. Still today, I keep earing "why would you work on something like that, there's something similar that already does that". Each time I read you blog, I can't help feeling how great it must be to work on the C# compiler and language specifications, not to mention how great it would be to work on stuff like EF, WCF, WPF, or whatever tool in use today or in the future.
If I was you, I would tend to leverage the simple idea of working on tools that will be used by hundreds or thousands of developers worldwide. I think that designing tools used by developers is like building music instruments. It's a completely unique world where you truly have to love the music for itself. When designing tools, you have to love code architecture for what it is : a masterpiece of the human mind. When you design things that will be used by other programmers for their duty, I frankly believe that you're doing something very special that's really different from the common developer's job.
Focus on finding people that find beauty in a good code architecture, that can see an architecture as a piece of art, and you'll automatically attract them and get the perfect developer team.
Well, I think you can divide the first question into two sub-parts. Firstly, I look at the culture for people in the team I would be in / the role. I'm talking about things such as: enthusiasm in the job - I don't want to be the only person pushing to improve. Being goal-focused. Willing to listen as well freedom to speak up and to be heard. Understanding that saying "i don't know" is not a sign of weakness, and being keen to learn and share new skills.
Secondly, from a technical point of view, I guess people like to work on newer technologies - at least, I do - but I suppose more important than that is that we would not continue to do things the same way as we have done in the past simply because "that's the way we've always done it" etc.
I've spent the last few minutes thinking about the second question you've posed and haven't come up with a cogent response one way or the other so will get back to you with that :-)
By the way, I'd like to work with you guys, haha!
One immediate negative is job postings that don't know what they're talking about. For instance, the other day I saw a posting for a position requiring 10 years of .NET programming experience. If they know nothing about the technologies they're using, that's not where I want to be.
Another immediate rejecting factor is requiring too much for too little. Another posting I saw was listing for a Level I (entry level) developer position requesting 8-10 years experience. If I've been around 10 years, I am not entry level nor am I willing to work for entry level pay.
Beyond that the first thing I look at is the location. I will not consider any positions in areas I would not want to live. For instance, being in central Ohio, i won't consider positions in Cincinnatti or Cleveland, because I would not want to live in or near either town.
After that I would echo many of the things others have said regarding posts that don't reveal the company name, aren't clear on what the position is for, or the endless list of "must be familiar with" technologies.
As with most of the posters, I hate seeing a list of qualifications that maybe 10 people in the world actual have. Most people will tell you, "They aren't really looking for all of that, just apply" and perhaps they are right. But just seeing that list often turns me off.
The thing that would most attract me to a position is the opportunity to work with some very talented developers. I currently have 5 years of experience, but I still have a lot learning to do to become a great developer. To even be tempted to apply for a position, I would have to feel that it would be an opportunity to advance my skill set and get some new perspective on problem solving.
As for working at Microsoft, the commute is too long. =D Why doesn't Microsoft have offices in Tacoma? UW Tacoma is turning out quite a few new developers these days.
The ads that tend to stand out to me are those that describe the interesting problems being solved by the team. For one it gets to the heart of the matter (do my interests align with theirs?). For another, it reveals a little about the technical background and approach of someone in the hiring path (assuming it wasn't ghost written).
Sometimes it's also nice to see a little "formal jargon" - not buzzword soup but enough to let you know that someone, somewhere has done a little (hopefully a lot) background reading on the subject.
As BBlake said, entry level positions should be... entry level.
Requiring 5 years of programming experience in an entry level position is just plain stupid. Someone looking to get into programming won't have that. Someone that has that will want actual pay.
A description entailing what you would actually be doing would be nice too.
My wife saw a good description for a job and looked into it. The description sounded like stuff she would love to do in server management, the interview described the job as effectively tech support. They also weren't going to pay for server management but for tech support. This was a major waste of time for both parties as she wasn't taking a 10K+ pay cut to do something she hates.
That's another thing, some companies say entry level, will pay entry level and the requirements are for folks that are anything but entry level. Having folsk that would qualify for senior positions in most environments be the only ones able to apply for this means fewer applications and some of those are fudging their qualifications.
Speaking from someone that does tech support and QA more I can say these are universal.
No one likes seeing a ton of requirements that have nothing to do with the job or even not knowing what the job actually does. No one likes seeing only overqualified people show up to interviews who then see the pay and politely explain that there is no point continuing because their pay requirements are well above what the company was willing to pay.
Describe the actual job, give a fairly accurate ballpark for pay and make sure the requirements are on par with what you would expect someone to be have at that level.
1) A few people mentioned this: getting a sense that I can personally make a meaningful difference on the team, within a year of starting the job, is very important. This is the case whether it's a development position or not. However, I'm not sure how to write a job description for an arbitrary position in such a way as to make that impression more likely.
2) I think a "developer tools team" is one of those things where either you're already keenly interested or you're not really interested at all.