If you've been working (or idling) for a year or more since you hung up your full time academic cap and gown, the microsoft recruiting machine considers you an industry candidate. Many of my comments in the prior post about campus candidates will apply to industry candidates as well. In fact, I would say that ALL of it applies. They still do spare time coding projects outside work; they are constantly trying new technologies and reading to keep themselves technically sharp. The pick up on technology trends and can expound on where they think they should go. They are smart AND hard working. But for industry, the bar goes up (and it should!); they now have practical experience that should translate to a more polished set of skills.

Preparation

So back to how to prepare yourself. If you are a developer and you want an SDE or SDET position at microsoft, the best way to prepare youself is to write code, read code, dream code. There's no secret here. Have it reviewed by others so that you get better.  You'll want to take a  4 pronged approach to what you code:

• A solid general knowledge across the board in areas like file I/O, 2d/3d graphics, string manipulation, databound apps, whatever you haven't tried, broaden your horizons. You never know what kind of interview question you will get, and having a broad knowledge from which to drawn on will help you.
• At least one area of deep expertise. Something that you've written tons of code in, and have much deeper knowledge of the problem space such that you could be a strong resource for your team in this space. You should be, above all, passionate, about this area, whatever it is.
• Use multiple languages and learn the pros/cons of each. When you're asked one of my favorite questions “What's your favorite coding language“, you'll be able to answer most correctly “that depends on what the problem is.“  It goes back to the old saying, if you only have a hammer in the toolbox, everything looks like a nail.
• Become an expert on your tools and leverage tools to make yourself better. Think about a master trade craftsman. If you asked him why he bought his DeWalt (or Ryobi, or Snap-on, etc, etc) tool, what kind of answer would you expect. Ask him what the advantages are with it over other tools he could be using. Why does he need a special diamond tipped wet saw? Because it ensures clean cuts on hard ceramic tile. For a software engineer, tool knowledge equates to efficient coding. Understanding what your tools are good at, and where you might upgrade demonstrates that master craftsman approach. Why do you use Lutz's Reflector? Why do you write all your code using EMACS? What do you hate about intellisense? How does late binding affect your coding? What 10 features do you wish you could add to your coding environment?

Interviewing

During the interview process, you'll be asked lots of questions, from coding problems to open ended questions designed to test your creativity, to fundamental questions like math/logic based puzzles designed to evaluate your approach to problem solving. 

• Coding: I would tell you to try writing code on paper or in notepad or on a whiteboard. For today's rad tool environments, intellisense coding is so helpful that it can be crippling you if you need to interview.
• Creativity: I don't know how to develop this, either you have this or you don't. 
• Problem solving: I don't know of a single way to prepare for these type of things, except to have a solid mathematical foundation and be both creative and inquisitive. If you don't feel your math skills are up to par, upgrade them! Generally coding across a broad space can keep you sharp enough to solve these kinds of problems.

And of course, don't be afraid to ask what kind of question this is. Why is a man hole cover round? Is it a logic problem, or a creativity problem? That really depends on who is asking it.