I'm relatively new at Microsoft. Additionally, my team here (Managed Languages) recently went through a reorganization, and we're now looking to hire some good Developers and Testers. Naturally, the process of finding and hiring people is on my mind. I went through the grand interview process at MS not long ago, so I figured I'd share some of my interviewing insights here.

The interview process usually begins with a phone screen or campus interview. After that, a candidate may be asked to fly to Redmond for a day of interviews - usually four or five of them across one or two teams. For my internship and full time position I took part in a total of 16 different individual interviews. I became quite familiar with the process. This is what I learned:

The interview is only the end of the hiring process.

It's true that the interview is an opportunity - but it's not where the opportunity starts. What matters more than the interview itself is the knowledge and experience that you build up before your interview. This process starts weeks or months before you talk to Microsoft (or any company, for that matter). What are you learning in class, on the job, or through personal study? Are you interested in new technologies? Do you have personal projects and/or do you contribute to an open source project? Inevitably the answers to these questions determine what you'll talk about in your interview.

The interview is not a test - it's a chance to show your knowledge.

I remember thinking, before my interviews, that they would be a big ordeal that I may or may not get through. I expected that I would face a series of questions, like a test, and I would either know the preordained correct answer or not get hired. That was a silly way to approach the process. In truth, the interview is simply a chance to show what you know. The technical questions do have right and wrong answers, but there are often several ways to arrive at the right answer. Your interviewer cares more about how you think and articulate your thoughts than anything else.

It helps to know who you're talking to.

An interview is not just Microsoft's chance to evaluate a candidate - it's the candidate's chance to evaluate Microsoft. This applies to MS as a whole, as well as the particular team that's hiring. Microsoft is a big company, it publishes many products, and it certainly helps to know at least a little about them. If you have an interview lined up, spend some time learning about that team's products, history, and competitors. This shows initiative and preparedness, and provides good material for discussion in your interview.

Finally, remember that the interviewers is an individual person, just like you. In a day full of interviews you'll speak to a handful of people. They all have their own opinions, experiences, and interests about Microsoft, Computer Science, Seattle and Redmond. There's a lot you can learn from comparing their experiences, and it will help you determine if you'd like to live and work out here.

If you'd like to apply for work at Microsoft, you can find information on the career site. Additionally, if you have interest in the Managed Languages Team, which includes work on C#, VB, F#, IronRuby and IronPython, feel free to contact me through this blog.

What is F#?

F# is a new functional programming language that is being developed here at Microsoft. Don Syme invented the language. Currently, the Managed Languages team is taking Don's work and turning F# into one of our production languages, alongside C#, Visual Basic, IronRuby, and IronPython. Since I find the project interesting, I've undertaken to learn F#. Don Syme invented the language. Currently, the Managed Languages team is taking Don's work and turning F# into one of our production languages, alongside C#, Visual Basic, IronRuby, and IronPython. Since I find the project interesting, I've undertaken to learn F#.

I'm learning F#

My Comparative Languages class back at Virginia Tech was one of my all-time favorites, but it involved only a meager treatment of functional programming. I wrote a little Scheme, but that was it. To learn F#, I expect my biggest task is simply to understand functional programming in general: to understand how it differs from imperative and object-oriented programming. To this end, I chose a language feature of F# to investigate: the forward pipe. Also, I chose an arbitrary task to code up, to flex my limited F# knowledge. 

What is the Forward Pipe?

In F#, simple function calls in F# look like this:

String.split [' '] text

In this case, String.split is the function, and [''] and text are the parameters. The parameters come after the function name. The Forward Pipe operator ( |> ) changes this order.With the Forward Pipe, a parameter preceding the function name is "piped" to the function, like this:

text |> String.split['']

It's important to note that the piped parameter is the last parameter in order (so text is ordered after [''] in this example).

More examples of the forward pipe can be seen in this code:

#light
//you may have to change this reference path:
#I @"D:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\v3.0\"
#r @"WindowsBase.dll"
#r @"PresentationCore.dll"
#r @"PresentationFramework.dll"

//opening namespaces
open System
open System.Windows
open System.Windows.Controls

//simple object manipulation
let win = new Window()
win.Title <- "Keats"
win.Show()

//function definition
let labFromText text =
    let newLab = new Label()
    newLab.Content <- text
    newLab
    
//function definition
let surroundWithPanel objs =
    let pan = new StackPanel()
    List.iter ( fun x -> pan.Children.Add( x ) |> ignore ) objs
    pan

//lots of forward pipes here:
win.Content <- "When I have fears that I may cease to be" 
|> String.split [' '] 
|> List.map labFromText 
|> surroundWithPanel

//this code allows the app to be compiled and run:
#if COMPILED
[<STAThread()>]
do
    let app =  new Application() in
    app.Run() |> ignore
#endif

  I'm Daniel Rathbone.  I started working for Microsoft about six months ago as a tester on the C# IDE team in the Developer Division.  Here's a link to my personal blog, which I hope I won't regret posting.

What's this blog all about?  Truly, I don't know yet.  I'll start by posting a variety of topics that interest me, centered around C#, and over time perhaps I'll work into a niche topic.  After reading my brainstorm of post ideas below, be sure to leave a comment to let me know what you'll find interesting.

Here's some post ideas:

• Comparing Visual Studio to Eclipse
• What's the .NET market share?
• Tech book reviews
• Getting hired at Microsoft

Finally, a word about style.  I'll include some personal commentary to give my blog some character.  If a post is non-technical, I'll tag it as non-technical, so as not to distract the technical reader.  For the most part I'll try to get to my points quickly.

Thanks for reading!

Hello and welcome to my hideously-named blog.  In most blog's first post the author writes some 'about me' information.  I'd like to break that trend and start with something useful.

Here at work I have two monitors connected to my main dev machine.  Also, I typically run three or four Terminal Server (also called Remote Desktop Connection) windows full-screen to interact with other machines.  On the whole, this is a great setup. 

I'm also a relentless shortcut-key user.  For example, most people don't know that pressing Alt and Space together brings up the window options for the current window.  I use this a hundred times a day.  Conveniently, the TS settings allow me to send keyboard shortcuts through the TS window, so that I can happily use the shortcuts to control the remote machine.

When I want to minimize the TS window itself, though, I have a problem.  My Alt-Space-N command is sent through the window, and does not operate on the window.

The solution is this:

• AutoHotkey (a well known hotkey re-mapper)
• this guy's script
• the TS window's Ctrl-Alt-Break shortcut

The TS window's Ctrl-Alt-Break shortcut changes the full-screen TS window to regular window, and when the TS window is regular, it consumes shortcut key commands, and does not send them to the remote machine.  The AutoHotkey program and that guy's script afford a convenient way to move the TS window between monitors.

Hooray!