Screen Door

Gretchen and Zoe and Heather have been blogging about the process Microsoft uses for recruiting and hiring.  Once you've made it past the recruiter gauntlet, but before you go through the formal interview loop, my team puts the candidate through a technical screening.

The recruiter will usually dig into your background in an effort to weed out people whose technical skills aren't strong enough to make it worthwhile for us to spend our time talking with you (if you can't code, then sorry, but you don't have a place on our team), but just because you pass muster with the recruiter doesn't mean you have what it takes to survive here.  We use the technical screening to give your technical skills a thorough beating.

And beat on you I do.  My typical screening goes something like this:

• Typical "Hi, how are you, would you like something to drink" getting-to-know-you chit-chat.  This is a blatant attempt to make you comfortable while I prepare my attack.  <g/>
• Design/coding question.  I use a real-life task I had some time back.  It's not especially hard, but it's not easy either.  As is often the case when coding, there is no one single right answer.The straightforward answer is a procedure or two.  There's also another solution that is ever so much better.  This is the second most important part of the screening.  I'm looking at such things as:
  • How do you approach the problem?  Do you ask a bunch of questions and then code non-stop, or query and code in a continuous intermix, or code without any further investigation into the problem, or...?
  • How do you write code, and what kind of code do you write?  Do you start with pseudocode, dive right into your language of choice, or some mixture thereof?
  • What language do you decide to use?  How facile do you appear to be with it?
  • Do you start at the beginning and work straight through to the end, start at the beginning and take various detours on your way to the end, start at the finish and move backwards to the start, start at a random point and work out from there?
  • Do you think about topics like security and internationalization?
  • Do you follow accepted coding standards for the language you are choosing?  Coding in a .Net language and not following the .Net Design Guidelines (https://msdn.microsoft.com/library/en-us/cpgenref/html/cpconnetframeworkdesignguidelines.asp) is a major black mark against you.
  • How do you debug your code?
  • Whenever you decide you've finished:  Tell me how you would test the code you just wrote.  Bonus points for talking about this without prompting from me -- especially if you tested your code as you wrote it.
  • OO design question.  There are several obvious answers that are also wrong, and a somewhat-less-obvious answer that is what I'm looking for.  However, there is another answer that would make me very happy.
  • What programming language do you know best?  What programming language do you like best?  Why?  Compare contrast both against C# (or C++, or VB, depending on your answers).
  • What are your technical strengths? 
  • What are your technical weaknesses?
  • Define the tester mentality.
  • What would be your optimum mix between manual testing, writing test automation, and writing test frameworks?
  • How do you test your own code?

Not the easiest hour you'll ever have, eh?  Those last few questions may seem somewhat out of place.  Others will drill into your testing skills in much more details, certainly.  However, I'm not only evaluating your technical skills -- I'm also evaluating how you will fit in with my team.  Understanding what you think testing is all about helps me do that.

I said earlier that the design/coding question is the second most important part of the screening.  The most important part isn't a particular question but rather your overall attitude.  I'm looking for passion:  passion for testing, passion for design and coding, passion for the customer -- passion.  Why do you want to be a tester?  What side coding projects do you have going?  Curt over at The Occupational Adventure (sm) has helped me realize how important passion is and how much more productive someone who is passionate about a topic will be than someone who is just doing their job. 

If you're a stellar tester or designer or coder but don't have passion for the work my team is doing, you don't have a chance of joining my team.  If, on the other hand, you demonstrate abundant passion in areas where we are working, but your testing or designing or coding skills aren't quite up to par, you have a good chance.  We'll help you grow your skills if you have the passion to make doing so worthwhile.

And if you a stellar tester and designer and coder, *plus* you have immense passion for the areas we're in, well -- email me right away!  <g/>

*** Comments, questions, feedback?   Or just want a fun job on a great team? </g>  Send two coding samples and an explanation of why you chose them, and of course your resume, to me at michhu at microsoft dot com. I need testers, and my team needs a data binding developer, program managers, and a product manager. Great coding skills required for all positions.

Comments

• Anonymous
  April 07, 2004
  micahel: "The design/coding question is the second most important part of the screening. The most important part isn't a particular question but rather your overall attitude." Amen. Ability is important, of course it is, but ability without commitment, enjoyment or

• Anonymous
  April 08, 2004
  "Do you follow accepted coding standards for the language you are choosing? Coding in a .Net language and not following the .Net Design Guidelines is a major black mark against you. "
  
  How strict is this? The guidelines ay not to use Hungarian notation and not to prefix field variables. I do both in C# out of habit from C++. Plus I prefer it because it's easier to read when I print code or am quickly skimming and I can tell instantly what is a local variable, what is a member variable and what type they are. I can't stand camel cased variables which is one reason I hated Java. So would that be a black mark if I did something like "int nCount = _arrItems.Count;"?

• Anonymous
  April 08, 2004
  Yes, that would be a black mark. We (Dev and Test) follow the .Net Design Guidelines stringently, FxCop everything, yadda yadda yadda.
  
  Of course, just because you get a black mark doesn't mean you're out of the running. <g/> We know that not everyone has found the Design Guidelines religion yet. If you do well enough on everything else we're willing to train you up.
  
  But if you really do prefer Hungarian notation and prefacing variables, and you really don't like camel cased variables, then you are not going to be happy on my team.

• Anonymous
  April 09, 2004
  "The guidelines say not to use Hungarian notation and not to prefix field variables"
  
  I thought private member fields should be prefixed with an underscore, or has that changed now? I can't find the original guidelines doc which stated that, and in some of the examples in the class library guidelines they weren't..!
  
  I must admit, I do miss the hungarian notation too (especially for just glancing at code and seeing the type), and sometimes wonder what the rationale for the change was. Is it maintenance, or that the IDE can tell you the type, or just that Simonyi left :-) ?
  
  

• Anonymous
  April 09, 2004
  The comment has been removed

• Anonymous
  April 12, 2004
  Wow, I can't believe style would be considered a "black mark". That seems very inflexible. Over the course of a career, most developers and testers will work with a variety of coding styles, idioms and even programming languages. Every time you join a new team your coding style has to alter - sometimes slightly, sometimes a lot - so that you can understand and contribute to the existing style of the team. Heck, 5 years from now we might all be coding in D-Sharp instead. I can easily teach you where you should put your curly-brace, but I can't change the way your brain works at the higher levels. To penalize somebody because their last job liked the m_ prefix for members and thats what they instinctively write is a good way to miss out on great employees.
  
  When I perform interviews (admittedly for dev and not test positions), I'm much more interested in how the candidates think rather than the details of their variable names (as long as they're not just x, y z of course. :-) ). Do they understand the concepts of computer science? Can they analyze a problem and apply the appropriate algorithms? Do they understand various tradeoffs involved in their decisions? Can they decompose a complex problem into solvable chunks? Can they recognize security issues in their design (andor code)? Is their code (regardless of style) clear and maintainable? Is it well thought-out, with a clean design, good error handling, and a usable interface, etc, etc, etc.
  

• Anonymous
  April 12, 2004
  Of course I'm looking at those other aspects as well, and giving great weight to them. However, different languages have different accepted styles. A candidate that pretends to write C# but in fact seems to be writing C is a danger sign.
  
  Whether you follow the Design Guidelines is just one data point, but is an important one.

• Anonymous
  April 13, 2004
  The comment has been removed

• Anonymous
  April 13, 2004
  LCA will probably not be excited about you soliciting and reading third party code.

• Anonymous
  April 15, 2004
  [Serializable]
  public class CustomRemotableException : RemotingException, ISerializable {
  private string _internalMessage;
  
  public CustomRemotableException(){
  _internalMessage = String.Empty;
  }
  
  public CustomRemotableException(string message){
  _internalMessage = message;
  }
  
  public CustomRemotableException(SerializationInfo info, StreamingContext context){
  _internalMessage = (string)info.GetValue("_internalMessage", typeof(string));
  }
  
  public override void GetObjectData(SerializationInfo info, StreamingContext context){
  info.AddValue("_internalMessage", _internalMessage);
  }
  
  // Returns the exception information.
  public override string Message{
  get {
  return "This is your custom remotable exception returning: ""
  + _internalMessage
  + """;
  }
  }
  }

• Anonymous
  April 16, 2004
  Yes, you would get dinged for using an underscore. You use it consistently, though, so that's a point in your favor. Your code is organized in a logical manner, so that's another point in your favor.

• Anonymous
  June 17, 2004
  Ah hungarian, it's a religous issue. My problem with the "banning" of hungarian is the usual justification given, in that Intellisense will tell you what type an object is. Which is nice.
  
  What's my problem then? Simple. Not everyone uses Visual Studio. Not everyone has intellisense turned on. There's always the situation where you fire up notepad to fix just one small tiny problem on an aspx page. Where's intellisense then :)
  
  I enjoy arguing this, doing it in an interview would be a bonus. Heh.

• Anonymous
  October 18, 2006
  I tech screened a tester this morning for a position on my team. I always ask the candidate to describe

• Anonymous
  November 29, 2007
  So you made it past the Recruiter? Now what?? As a follow-up to my post on HR Screens , Michael Hunter

• Anonymous
  December 17, 2008
  So you made it past the Recruiter? Now what?? As a follow-up to my post on HR Screens , Michael Hunter , a Test Technical Lead here at Microsoft, posted his thoughts on the equally (if not more so) dreaded &#8220; Tech Screen .&#8221; Not all teams choose

• Anonymous
  January 14, 2009
  So you made it past the Recruiter? Now what?? As a follow-up to my post on HR Screens , Michael Hunter , a Test Technical Lead here at Microsoft, posted his thoughts on the equally (if not more so) dreaded &#8220; Tech Screen .&#8221; Not all teams choose