Attracting Talent, summarized

Attracting Talent, summarized

Rate This
  • Comments 39

Thanks for all your insights on what is attractive or unattractive about job postings, and about working on developer tools. A great many of the comments were strongly aligned with each other; no one likes “alphabet soup”. And a number of them illustrated that there is a wide spectrum of what people find attractive and unattractive. To sum up the hundred comments I received:

Factors that make a job posting unattractive are:

  • “Required Skills Include…”
    • “technology vomit”, aka “alphabet soup”. ASP, PHP, ODBC, VSTO, ADO, VB, TLC, NGO, BMX, OMG, WTF, BBQ…
    • overemphasis on specific existing knowledge vs. ability to learn new skills
    • too many specifics: so many “required” skills that no mortal could actually fit the bill
    • too few specifics: “Fortune 500 company seeks detail oriented, self motivated programmer to work on exciting new projects” says nothing
    • nonsensical requirements: a posting requiring “five years experience with C# 4” makes no sense
    • things that ought to be assumed (can type, knows how to use a word processor)
    • too much emphasis on certifications / degrees / class standing
    • requiring familiarity with older technologies (VB6, for example)
  • Format and style
    • too long; didn’t read
    • too short; not enough information
    • sounds like it was written by someone who has no idea what they’re actually talking about
    • arrogant or aggressive style
    • full of internal jargon, or exposing clunky mechanisms - "Position: SDEII(707719-External)"
  • Personality and culture
    • no evidence of awesome coding methodologies, such as “Agile Programming”
    • evidence of dogmatic devotion to trendy coding methodologies, such as “Agile Programming”
    • flat, boring list of requirements with no evidence of “personality”
    • silly attempts to inject “personality”. (Be a ninja rockstar coder!)
    • no indication of working environment – is it a noisy cube farm, private offices, on-site at the client’s space, what?
  • The job itself
    • vague, unfocussed, directionless, no clear indication of responsibilities, posting seems to be about hiring a warm body
    • job description does not distinguish it from a thousand other postings (“Web developer wanted for… web development”)
    • no telecommuting
    • relocation required
    • no indication of salary range
    • salary is indicated but too low
    • job requires crazy hours away from family and other pursuits
    • no indication of what tools/languages will be used

Factors that make a job posting attractive are:

  • Required skills
    • relevant, focused, sensible
    • emphasis on ability to learn
  • Format and style
    • well-written, self-aware, humble, enthusiastic
  • Personality and culture
    • good work-life balance
    • corporate culture and values clearly expressed
    • evidence of programming methodologies, such as “Agile Programming”
    • opportunity to work with famous industry leaders or on famous products
  • The job itself
    • described in detail: specific team, specific product, specific job
    • telecommuting possible
    • work is beneficial to industry and society
    • work has large scope -- “change the world”
    • work is challenging
    • product is innovative
    • tools/languages to be used are described and are current and familiar
    • good pay
    • autonomy to choose own tools, architectures, methodologies
    • details of the team stated – team size, for example
    • more than just typing in code – opportunities for UI design, DB design, troubleshooting user problems, and so on

Factors that make working on developer tools unattractive are:

  • not used by ordinary people; less impact than working on a browser or a word processor, which ship to hundreds of millions of people
  • problems are too academic, too abstract, too difficult
  • the job requires a CS background; the interview process is going to be scary, difficult, and I don’t want to set myself up for failure.

The last point I want to talk about in a bit more depth.

You don’t need a PhD in computer science or be a Waterloo grad to work in DevDiv. Now, don’t get me wrong; it helps to have a relevant degree from a great school. A great many of my coworkers have degrees in CS, mathematics or other related fields. But a number of my coworkers do not have degrees and are not even from Waterloo. (At one brief moment in my career my entire management chain from me up to our vice president was Waterloo grads; there are disproportionately many Waterloo grads in DevDiv.)  Having an academic background certainly helps because it means that you’ve already been exposed to a lot of the ideas that we work with every day. But what matters is whether you can grasp those ideas and use them in practice, not whether you can “chew algebra and spit assembler” as one commenter put it.

A few anecdotes to illustrate my point. A couple years ago I had a conversation with an architect who had spent several years building up a library of objects to represent control flow operations on generic types, and only a year after he was finished did he realize “aha, this pattern of composable objects that I built this whole architecture around is called a monad.” You don’t need to be able to rattle off “a monad is an endofunctor with an associated bind and return functor” in order to write a library of objects that an academic would identify as being monadic.

A more extreme example: my wife worked at Microsoft successfully for ten years as a software tester; her degree is in the study of the French “Theatre of the Absurd” movement of the mid 20th century. Admittedly, that sort of thing is less common these days than it was fifteen years ago. But it does illustrate that people do come here with all kinds of academic backgrounds. What matters much more than academic background is drive, talent, intelligence, ability to learn new skills, and simply getting stuff done.

Let’s move on to the positives.

Factors that make working on developer tools at Microsoft attractive are:

  • your customers are developers; you understand the customer and they understand you
  • you are building tools that make your own job better
  • problems in this space are more challenging, interesting, academic, abstract and difficult than those in many other problem spaces
  • a whole team full of tool makers is likely to be a good team to work with
  • the opportunity to ship cutting-edge technology to millions of customers
  • “programming about programming is twice the fun!”
  • employees are surrounded by industry leaders who do great things; employees have direct access to these leaders rather than relying on blog posts, magazine articles, interviews, and so on.
  • programmers are well-shielded from having to deal with non-programming aspects of business
  • corporate culture is well-known: hours are flexible, dress code is flexible, and so on
  • Microsoft provides opportunities to take huge bets; our projects have enormous scope
  • compensation and benefits – all kinds of insurance, gym memberships, bus passes – are generous
  • developers can advance on the “technical track”; you don’t have to become a manager to get promoted around here

Thanks again for all your comments and constructive criticisms. I appreciate it very much.

  • "The winner in a negotiation is most likely to be the one with the most experience and most power."

    I disagree.  I think the winner in a negotiation is most likely to be the one that is most willing to walk away without any agreement.  This party likely has other options which are potentially more desirable.  I'm definitely not a skilled negotiator, but I think the most powerful thing you can have on your side during negotiation is an alternative.  If you select that alternative, the other party must find one as well or walk away with nothing.

    Absolutely that is the case in most negotiations. However, power is a tricky thing. I took a negotiation class once, taught by a former NFL salary negotiator. He described a spectrum of negotiation styles with "Kansas" at one end and "Chicago" on the other. The Kansas style is "Hey, have I got a deal for you! You could do that thing for me, and in return, I'd do this thing for you, and we'd both get higher profits out of it than we're making now!" The Chicago style is "Hey, have I got a deal for you! You could do this thing for me, and I could refrain from burning your house down!" I think we'd all prefer to be "in Kansas" when negotiating a deal, but we live in a world where some people "go to Chicago", so it is best to be prepared.

    My point being that sure, the ability to walk away is power, but it is not the only form of power. The ability to inflict a consequence upon the party that exercises their ability to walk away is also a form of power. -- Eric

  • Chris B: By power, I meant precisely the ability to walk away from the table. Most companies can be profitable for years without any given position being filled. Meanwhile, an average unemployed worker with a family will only have a few months before they have to get a job regardless of what it pays. Of course a person who already has a job and is just looking around can easily afford to walk away from the table, and thus has a better chance of negotiating a higher salary. It seems to me that on average this just rewards disloyalty.

  • Eric wrote: "I think it is generally character-building to build your own compiler at least once, either for a language of your own or for a subset of an existing language."

    Ok, but are there any decent build-your-own compiler/interpreter books out there? I've tried looking at a few over the years, including the infamous "Dragon Book" (odd, I just noticed there is a 2nd edition of this book that came out in 2006), and well...I'm always sort of struck by how they all tend to fall into same basic patterns of lexing/parsing/etc. Why is that?

    The basic pattern of lexing and parsing is the same all over because analyzing language in general is incredibly hard. We deliberately design programming languages so that they can be analyzed via simple, easy-to-write lexers and parsers; analyzing more "natural" languages is way too hard. (Try Inform7 some time if you want to see an incredibly awesome programming language that reads like English; I can only imagine how hard that parser must have been to write.) -- Eric

    Has there been much innovation in terms of how program code is split into tokens, etc.? Note, I'm not referring to JIT compilation, garbage collection or anything like that. I mean the actual initial parsing of the code itself.

    Sure. For example, there's been some research into monadic parsers. They're very useful when you have one language embedded in another. Consider writing an analyzer for ASP markup containing HTML, which is itself containing VB, which is itself containing XML literals. -- Eric

    Part of me wants to bypass the whole process and come up with a completely different way of lexing/parsing program code. Of course, this would probably involve coming up with a new language too.

    Go for it! -- Eric

  • @Gabe

    "Most companies can be profitable for years without any given position being filled. Meanwhile, an average unemployed worker with a family will only have a few months before they have to get a job regardless of what it pays."

    True, but your ability to "walk away from the table" is not solely influenced by how long you can go without a job. It is also very heavily influenced by your ability to get and accept other offers. I never go into any interview assuming that I am at a position of weakness compared to the potential employer. I always assume that they need my skills more than I need their money. I can make that assumption because I have confidence that in most cases I am more highly qualified compared to the other candidates for the job than the job is desirable compared to other potential jobs. That means that the employer has to convince me to work there more than I have to convince him to hire me; and that puts me in a strong negotiating position when it comes to salary and any other negotiated detail of the job.

    Of course, if you don't have that kind of confidence in your own value, then you can't make the same assumptions, and you won't be in the same kind of strong position. And it could be that my assumptions are not always correct. But they have been correct often enough that I have never even come close to the point where I had to accept a job at less than I believe I am worth. I am not trying to paint myself as a rock star developer that everyone should want to hire. You don't have to be a rock star to have confidence in yourself. Even if you think you are only in the 50th percentile of the candidates for a position, if the position is in the 45th percentile of available positions in terms of desirability, you are still in a strong negotiating position. Remember that the less skill that the job requires (which means the more qualified applicants are available), the more it has to compete with other jobs that require similar skills.

  • Eric, in the "factors that make working on developer tools at Microsoft attractive" category, is it still true that you have to work at the main campus to work in DevDiv? I heard that at one point, but I have also seen evidence of people working in DevDiv from other locations (notably Hawaii). I would love to work on developer tools, but moving to Seattle just isn't an option right now.

    The vast majority of developers in DevDiv are on main campus, yes. There is also a minority of people working from remote locations; it does happen, but it is rare. -- Eric

  • Eric wrote:

    "The basic pattern of lexing and parsing is the same all over because analyzing language in general is incredibly hard. We deliberately design programming languages so that they can be analyzed via simple, easy-to-write lexers and parsers; analyzing more "natural" languages is way too hard."

    Good points, and thanks for the reply. I think one of things that bugs me, though, is when I use a language like C or C++, and inevitably miss a semicolon somewhere, the compiler sometimes complains that it has found 5-20 errors in my code. In essence, it becomes a lexical trainwreck under the hood of the IDE. When I was first trying to teach myself C, this became an almost insurmountable obstacle because I wasted a lot of time looking for errors that really didn't exist.

    The C# compiler has huge amounts of "error recovery" heuristics in it to avoid this problem. What we do is try to "reset" onto something that we know is good. So for instance if you are parsing "class C { void M() { class D { }" then we say oh, we didn't expect class inside this method body, let's assume that the brace was missing, give an error, silently insert the brace, and continue on." There are all kinds of heuristics like that which attempt to reset the parser onto something that we know is good so that we can "start over" parsing from that point and not give errors for it. -- Eric

    I know Intellisense is constantly improving (for example), but I think this brings me to another point: why is there an insistence on scanning character by character, left-to-right, and down through the code? Maybe I haven't seen enough compiler/interpreter implementations behind the scenes, but that is what I've gotten from various books/online examples.

    We don't. The current C# compiler parses "top level" stuff in every file first, skipping method bodies and then goes back and parses each method body in each file individually. That way we can do analysis of whether, say, the class hierarchy makes any sense before we attempt to analyze the method bodies that are going to use that class hierarchy. -- Eric

    Here's another way to look at it. In writing, if there is a missing comma in a sentence, it typically does not cause an entire page of text to implode on itself.

    You have good error recovery heuristics in your brain. -- Eric 

    And yes...I'll look at monadic parsers...thanks for the info!

  • Two observations.

    1) Back in the late 1970's (at University) we were using a Pascal compiler on a Univax mainframe (Batch!). The compiler would actually make assumptions and attempt to continue to compile the program. This cut down on the number of iterations (which could take 24 hours) - the school did have a policy that any code which contained a "fix" of this nature was an automatic failure. Ironic, that this is unheard of in today's environments.

    2) Sometimes a comma DOES matter. There was an old "joke" about a prisoner who was about to be put to death. Although I forget the exact syntax of the question, the reply was: "No don't kill him". The intent was "No, DON'T kill him", but the listener took it as "No don't, KILL him". Bet THAT prisoner wished the comma was explicit!

    There was one of those on StackOverflow today. Someone wrote something like "this method does not return true as expected". Is that "As we expected all along, this method does not return true", or "this method does not return true, which is what we expected it to return"? It would have been more clear to write "this method returns false, as expected", or "this method returns false, unexpectedly". -- Eric

  • Eric,

    The Job Search tool on the MSFT career site has a "Division" dropdown. I can't identify the option for DevDiv jobs. My best guess is "Server&Tools Business". Does this seem right?

  • Let me guess, the "aha, monad!" guy's last name was Snover.

    @Abhijeet - yes, DevDiv is part of STB

Page 3 of 3 (39 items) 123