<?xml version="1.0" encoding="UTF-8" ?>
<?xml-stylesheet type="text/xsl" href="http://blogs.msdn.com/utility/FeedStylesheets/rss.xsl" media="screen"?><rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:slash="http://purl.org/rss/1.0/modules/slash/" xmlns:wfw="http://wellformedweb.org/CommentAPI/"><channel><title>Screen Door</title><link>http://blogs.msdn.com/micahel/archive/2004/04/07/109145.aspx</link><description>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</description><dc:language>en-US</dc:language><generator>CommunityServer 2.1 SP1 (Build: 61025.2)</generator><item><title>Passion in the workplace</title><link>http://blogs.msdn.com/micahel/archive/2004/04/07/109145.aspx#109666</link><pubDate>Thu, 08 Apr 2004 11:34:00 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:109666</guid><dc:creator>Flatlander</dc:creator><description>micahel: &amp;quot;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.&amp;quot; Amen. Ability is important, of course it is, but ability without commitment, enjoyment or</description></item><item><title>re: Screen Door</title><link>http://blogs.msdn.com/micahel/archive/2004/04/07/109145.aspx#109892</link><pubDate>Thu, 08 Apr 2004 15:54:00 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:109892</guid><dc:creator>Modian</dc:creator><description>&amp;quot;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. &amp;quot;&lt;br&gt;&lt;br&gt;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 &amp;quot;int nCount = _arrItems.Count;&amp;quot;?</description></item><item><title>re: Screen Door</title><link>http://blogs.msdn.com/micahel/archive/2004/04/07/109145.aspx#109914</link><pubDate>Thu, 08 Apr 2004 16:32:00 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:109914</guid><dc:creator>The Braidy Tester</dc:creator><description>Yes, that would be a black mark.  We (Dev and Test) follow the .Net Design Guidelines stringently, FxCop everything, yadda yadda yadda.&lt;br&gt;&lt;br&gt;Of course, just because you get a black mark doesn't mean you're out of the running.  &amp;lt;g/&amp;gt;  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.  &lt;br&gt;&lt;br&gt;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.</description></item><item><title>The Technical Screen</title><link>http://blogs.msdn.com/micahel/archive/2004/04/07/109145.aspx#110606</link><pubDate>Sat, 10 Apr 2004 00:21:00 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:110606</guid><dc:creator>Technical Careers @ Microsoft</dc:creator><description /></item><item><title>re: Screen Door</title><link>http://blogs.msdn.com/micahel/archive/2004/04/07/109145.aspx#110636</link><pubDate>Fri, 09 Apr 2004 22:39:00 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:110636</guid><dc:creator>PeteB</dc:creator><description>&amp;quot;The guidelines say not to use Hungarian notation and not to prefix field variables&amp;quot;&lt;br&gt;&lt;br&gt;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..!&lt;br&gt;&lt;br&gt;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 :-) ?&lt;br&gt;&lt;br&gt;</description></item><item><title>re: Screen Door</title><link>http://blogs.msdn.com/micahel/archive/2004/04/07/109145.aspx#110756</link><pubDate>Sat, 10 Apr 2004 06:11:00 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:110756</guid><dc:creator>Andrew</dc:creator><description>Passion is something I've been recently thinking about a lot too, but from a slightly different perspective. You talked about the hugely important need to hire engineers with a lot of passion, but all of that effort is for nothing if the organization doesn't maintain that level of passion in its people.&lt;br&gt;&lt;br&gt;There are so many ways to suck the passion out of people. Constant sustained overwork will burn a person out, too little work can turn an engineer into a lethargic ghost, endless repetitive work will reduce someone to an automaton (love the Sacrifice One Person pattern!), layoffs get everybody looking over their shoulder, and so on, etc, yadadada. &lt;br&gt;&lt;br&gt;The solution, as I see it today, is to ensure people are always thinking. In my experience a thinking engineer doesn't get bored, gets vocal before crossing the burnout event horizon, is constantly learning and inspires creativity and passion in others. Of course creating and maintaining a thinking environment is easier said than done, but I see it as a key part of a technical lead's role.&lt;br&gt;&lt;br&gt;Too many places hand out technical lead roles to engineers whose main skill is being good at blowing their own trumpets (environments that encourage code ownership and fiefdoms seem particularly prone to this). For me it's almost the reverse. A technical lead should be the one ensuring everybody else on the team is thinking and that all the thinking is heading in the right direction. Managers typically struggle with this as they lack the visibility into the current state of each contributing mind that comes from a day-to-day immersion in the technical depths of a project.&lt;br&gt;&lt;br&gt;Hmmm, I seem to have meandered somewhat. I should probably stop now.&lt;br&gt;&lt;br&gt;Andrew</description></item><item><title>re: Screen Door</title><link>http://blogs.msdn.com/micahel/archive/2004/04/07/109145.aspx#111687</link><pubDate>Mon, 12 Apr 2004 17:14:00 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:111687</guid><dc:creator>Random Interviewer</dc:creator><description>Wow, I can't believe style would be considered a &amp;quot;black mark&amp;quot;. 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.&lt;br&gt;&lt;br&gt;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 (and\or 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.&lt;br&gt;</description></item><item><title>re: Screen Door</title><link>http://blogs.msdn.com/micahel/archive/2004/04/07/109145.aspx#111795</link><pubDate>Mon, 12 Apr 2004 20:07:00 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:111795</guid><dc:creator>The Braidy Tester</dc:creator><description>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.  &lt;br&gt;&lt;br&gt;Whether you follow the Design Guidelines is just one data point, but is an important one.</description></item><item><title>The Technical Screen</title><link>http://blogs.msdn.com/micahel/archive/2004/04/07/109145.aspx#112346</link><pubDate>Tue, 13 Apr 2004 19:14:00 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:112346</guid><dc:creator>Technical Careers @ Microsoft</dc:creator><description /></item><item><title>re: Screen Door</title><link>http://blogs.msdn.com/micahel/archive/2004/04/07/109145.aspx#112439</link><pubDate>Tue, 13 Apr 2004 17:48:00 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:112439</guid><dc:creator>Jeremy C. Wright</dc:creator><description>Hey Michael,&lt;br&gt;&lt;br&gt;Had a look but couldn't find what team you work with. In your post you noted that you were looking for passionate people who could code to join the team in roles like Program Manager (the job I'm looking for at Microsoft).&lt;br&gt;&lt;br&gt;But, without knowing what the team really does it's difficult to tell if I'm passionate about it.&lt;br&gt;&lt;br&gt;The coding samples aren't a problem (I 'grew up' as a designer and developer), but I don't want to waste your (or my) time.&lt;br&gt;&lt;br&gt;Feel free to drop me a line: jeremy AT ensight.org.</description></item><item><title>re: Screen Door</title><link>http://blogs.msdn.com/micahel/archive/2004/04/07/109145.aspx#112689</link><pubDate>Wed, 14 Apr 2004 00:17:00 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:112689</guid><dc:creator>Anon</dc:creator><description>LCA will probably not be excited about you soliciting and reading third party code.</description></item><item><title>Would I be dinged for this?</title><link>http://blogs.msdn.com/micahel/archive/2004/04/07/109145.aspx#114399</link><pubDate>Fri, 16 Apr 2004 05:32:00 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:114399</guid><dc:creator>Larry Curly Anon</dc:creator><description>[Serializable]&lt;br&gt;public class CustomRemotableException : RemotingException, ISerializable {&lt;br&gt;   private string _internalMessage;&lt;br&gt;&lt;br&gt;   public CustomRemotableException(){&lt;br&gt;      _internalMessage = String.Empty;&lt;br&gt;   }&lt;br&gt;   &lt;br&gt;   public CustomRemotableException(string message){&lt;br&gt;      _internalMessage = message;&lt;br&gt;   }&lt;br&gt;   &lt;br&gt;   public CustomRemotableException(SerializationInfo info, StreamingContext context){&lt;br&gt;      _internalMessage = (string)info.GetValue(&amp;quot;_internalMessage&amp;quot;, typeof(string));&lt;br&gt;   }&lt;br&gt;&lt;br&gt;   public override void GetObjectData(SerializationInfo info, StreamingContext context){&lt;br&gt;      info.AddValue(&amp;quot;_internalMessage&amp;quot;, _internalMessage);&lt;br&gt;   }&lt;br&gt;&lt;br&gt;   // Returns the exception information. &lt;br&gt;   public override string Message{&lt;br&gt;      get {&lt;br&gt;            return &amp;quot;This is your custom remotable exception returning: \&amp;quot;&amp;quot; &lt;br&gt;      + _internalMessage &lt;br&gt;      + &amp;quot;\&amp;quot;&amp;quot;;&lt;br&gt;      }&lt;br&gt;   }&lt;br&gt;}</description></item><item><title>re: Screen Door</title><link>http://blogs.msdn.com/micahel/archive/2004/04/07/109145.aspx#114870</link><pubDate>Fri, 16 Apr 2004 20:19:00 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:114870</guid><dc:creator>The Braidy Tester</dc:creator><description>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.</description></item><item><title>re: Screen Door</title><link>http://blogs.msdn.com/micahel/archive/2004/04/07/109145.aspx#159153</link><pubDate>Fri, 18 Jun 2004 11:29:00 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:159153</guid><dc:creator>Barry Dorrans</dc:creator><description>Ah hungarian, it's a religous issue. My problem with the &amp;quot;banning&amp;quot; of hungarian is the usual justification given, in that Intellisense will tell you what type an object is. Which is nice. &lt;br&gt;&lt;br&gt;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 :)&lt;br&gt;&lt;br&gt;I enjoy arguing this, doing it in an interview would be a bonus. Heh.</description></item><item><title>Tester Mentality</title><link>http://blogs.msdn.com/micahel/archive/2004/04/07/109145.aspx#839987</link><pubDate>Wed, 18 Oct 2006 23:29:21 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:839987</guid><dc:creator>The Braidy Tester</dc:creator><description>&lt;p&gt;I tech screened a tester this morning for a position on my team. I always ask the candidate to describe&lt;/p&gt;
</description></item><item><title>The Technical Screen</title><link>http://blogs.msdn.com/micahel/archive/2004/04/07/109145.aspx#6601706</link><pubDate>Thu, 29 Nov 2007 22:50:01 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:6601706</guid><dc:creator>Microsoft's JobsBlog</dc:creator><description>&lt;p&gt;So you made it past the Recruiter? Now what?? As a follow-up to my post on HR Screens , Michael Hunter&lt;/p&gt;</description></item><item><title>The Technical Screen</title><link>http://blogs.msdn.com/micahel/archive/2004/04/07/109145.aspx#9231238</link><pubDate>Wed, 17 Dec 2008 20:45:54 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:9231238</guid><dc:creator>Microsoft JobsBlog</dc:creator><description>&lt;p&gt;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 &amp;amp;#8220; Tech Screen .&amp;amp;#8221; Not all teams choose&lt;/p&gt;
</description></item><item><title>The Technical Screen</title><link>http://blogs.msdn.com/micahel/archive/2004/04/07/109145.aspx#9319028</link><pubDate>Wed, 14 Jan 2009 20:15:32 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:9319028</guid><dc:creator>Microsoft JobsBlog</dc:creator><description>&lt;p&gt;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 &amp;amp;#8220; Tech Screen .&amp;amp;#8221; Not all teams choose&lt;/p&gt;</description></item></channel></rss>