Scott Louvau's Blog

The Skills

ScottLouvau — Thu, 16 Apr 2009 05:28:00 GMT

You decide you want to become the best Software Engineer you can be. You start working on your coding and debugging and code design skills, and you get great at them, but you are still not there.

There are many skills you need to be a great programmer which have nothing to do with code.

What about the skills to make sure you’re building the right product? The ones you need to get a team together around the same goal? To make sure you’re hiring the right people? To convince your boss that spending more time to rearchitect something is the right call, or that you should really remove this part of it altogether? To plan out a project and have it get done when you thought?

It’s those I’m stuck on.

College Interview Feedback

ScottLouvau — Tue, 03 Mar 2009 20:49:00 GMT

I just returned from a college recruiting trip to Simon Fraser University in Canada, where I met a number of great students. The trip reminded me of common problems people have in technical interviews and the biggest things which I think helped me to succeed at mine and get hired by Microsoft.

Here are some suggestions for preparing for interviews, some curriculum ideas for Computer Science, and sample questions and things I look for during an interview.

Suggestions to Prepare

Participate in Programming Contests

These have problem solving, require quick, clear communication (for teams), and require practical coding for algorithms and data structures. Nothing prepared me as well for my daily job.

Use Mock Interviews

These are great for getting used to the format, thinking about what you want to say about yourself and in what level of detail, and just getting comfortable with interviews. Nervousness is a common problem and practice can help.

Read Great Books

For Developers, Code Complete and The Pragmatic Programmer are absolutely fantastic. They are heavily focused on how to treat programming as a process and about what makes great code great. I consider reading and following them to be equivalent to several years of additional professional experience.

Curriculum Suggestions

Unit Testing and Test Driven Development are things I wish we had throughout programming courses. If every CS student learned to write unit tests from the first day they wrote code, the industry would be better.

Debugging is something I would make a class of. The most common thing I teach people when they start to work is how to go from a bug to a hypothesis to a fix. Have students debug code they didn’t write and have examples of easy and hard to debug code. Have them analyze what happened, how the code helped or hurt debugging, and how they could’ve narrowed down on the real problem fastest.

Software Testing would be a great course. The industry knows a lot about solid practices to build different kinds of software and very little about solid practices for testing. Most testers I hire have talent but no experience testing.

Sample Interview Questions

Here are some sample questions (for a developer (SDE) candidate), and a few of the things I look for in each:

You chose the Development role. What attracted you to that role?

· Did they misunderstand the roles?

· Are there signs they might be best suited for another role? (Developer -> I love writing code and then making sure there are no bugs in it. Possible Tester?)

Tell me about a project which highlights your development skills.

· Were they excited about it? Why?

· Did they learn something?

· Are they thinking about the user? Are they focused on the overall goal?

Follow-up Questions about the Project, like:

· Tell me about a key challenge that came up. (Was it fixed? Did they learn something?)

· How did you test it? (Was there a process? Do you know how it worked? How was the relationship with testers?)

· What are the next steps for the project? (Do you know where it’s going?)

When you look at code, how do you decide whether it is bad code, good code, or great code? What properties does great code have?

· Do they prioritize their answer well and have a rationale for it?

· Does their answer suggest they’ve gotten better at coding over time?

Implement String Remove – a method which takes a string ‘text’ and a string ‘value’ and returns a new string which is like ‘text’ but with all instances of ‘value’ removed. For example, if I pass “Hello, Hello” as text and “el” as Value, “Hlo, Hlo” should be returned. Use the language of your choice.

· Do they have a process for programming, or just muddle through? (*Most important*)

· Do they think about an algorithm before coding?

· Do they understand allocation?

· Do they write a good loop? (Safest choice, progress each iteration, avoid off-by-ones?)

· Do they run through an example with the code and catch problems without help?

Follow-up Questions about Code, like:

· Can you walk me through how this works for the example?

· Can you walk me through how this works for (choose input which exposes a bug)? (Do they find it? Do they fix it properly?)

· What is the runtime complexity of this function? (Do they know? Do they worry about the cost of calls they’re making? Do they compare it to what they think it should take?)

· Could you make it faster? (Can they assess the minimum expected cost? Are they confident if they did choose a solution on that scale?)

· One problem is that you don’t know how big to make the final string up front. What are your options for dealing with this problem? (Do they know the space/speed tradeoffs and major choices?)

· How would you test this function?

· How would this function work for overlapping matches? (“banana”, “ana”) (Do they see this was ambiguous? Do they ask me what it should do here?)

Regex Builder

ScottLouvau — Thu, 06 Dec 2007 07:31:00 GMT

Regex Builder has moved to a new home, and I've released a new 2.05 version with a few fixes and new features. It now offers a VB or C# preview of the code to run the expression (automatically escaping string terminators in the target language) and offers the ability to unescape characters (helpful for going back from code to Regex Builder)

You can find it at http://www.codeplex.com/regexbuilder.

The Best Question To Ask

ScottLouvau — Thu, 06 Dec 2007 06:26:00 GMT

With a doubt, the one question that's done the most to make me a better programmer (and person) is "What will they say?" I wish I'd known about it when I first started working. Nothing makes you seem smart and prepared quite like having heard the question already and having the answer ready, and it's amazing how often you can predict those questions yourself.

About to get a Code Review? What will they say?
Which design choices will they ask about? What won't they like? What tests will they ask if you've tried? Over time, I've caught more and more of my own issues and been ready to explain difficult decisions when the reviewer first arrives.

About to ask someone a question? What will they say?
What details about the problem will they ask for? What debugging steps will they ask if you've tried? What will they suggest you look up? I can't believe how many problems I've solved while collecting the information I think someone else will need to figure it out.

About to demo something? What will they say?
What details will they ask about? What is awkward that they'll want worked on a little more? What is too slow that you have to talk over? What's "hand-wavy" that they'll see is missing? What will they be most excited about? Nothing helps me to polish a design quite like trying to make a real-world demo completely smooth. Great applications make for great demos.

I’m sure there are endless examples, but you get the idea. How about you? What question has helped you the most?

What is an SDET?

ScottLouvau — Thu, 30 Jun 2005 08:43:00 GMT

You might be wondering what exactly an "SDET" is. Microsoft has a few core "disciplines" who participate in software development: Program Managers (PMs), Software Design Engineers (SDEs, or Devs), and Software Design Engineers in Test (SDETs, or Testers). There is a fourth discipline, Software Test Engineers (STEs) which is currently being phased out.

Program Managers are the designers who define the features, represent the users, manage progress on the product, and evangelize the product. Software Design Engineers do the detailed design (code design) of the features, write the product code, and fix defects which are found. Software Design Engineers in Test manage the quality of the product, which means that they find the defects to be fixed, and decide when the product is ready to ship.

In the past, manually scouring the product for issues might've been enough, but many software products (especially those Microsoft develops) are too complex these days for that to do the job. At Microsoft, the SDET role is centered around defining, creating, and managing automated tests. I'm sure that doesn't appeal to everyone, but it seemed very interesting to me. There are a few unique benefits to the SDET role which I value highly, and which I expect will keep me in this role for quite some time.

First, the SDET role is highly technical. I spend the majority of my time writing and debugging code, which I don't think I could give up. Automated testing has some unique challenges as well - it's essentially writing code which will interact with the product code, but rather than using direct programmatic interfaces, network communication, or another often used communication mechanism to work with the other code, you are using the user interface. This is especially interesting because all applications have a user interface, so once you learn how to manage the interface you can work with any application (to some extent).

Second, I like the mix of breadth and depth I get in my job. PMs have a very wide view of the product, and can generally walk you through a quick introduction to almost any feature in the product. Unfortunately, being responsible for so many features means that they don't get to explore them in the same depth that I do. Developers, on the other hand, have incredible depth - complete knowledge of the workings of the features they own. However, each developer can only own a few features, so they often don't know as much about the rest of the product. I'm sure that each technical person has a unique mix of the two they prefer, and for some reason the mix of depth and breadth I have appeals to me. I feel like an expert user of the product - I'm very familiar with some features, and the familiarity is centered around the way I use them rather than the way they might work underneath. There are features I know very little about as well, though I do get a rough overview of them.

Third, playing with the product is a part of my job. We don't spend a huge amount of time this way, but there is formal calendar time in the schedule when testers are asked just to play with the product to come up with something neat (App-Building). For Visual Studio, this means write some code and play with the VS features. In addition, there are specific days allocated where we just wander the surface of the application looking for (usually) smaller bugs (Bug Bashes). These days aren't as much like play as App-Building, but it's really nice to be able to go over the product and scrub out the spots that don't look right, or don't make sense in some cases. The usual result of a Bug Bash is that a few weeks later, we have a much more polished-looking product. (And I didn't have to fix all of those nasty little things).

Finally, testing is something of an "unexplored frontier". There are many areas of Computer Science which have been well explored (and documented) by academic and business programmers of the past. Testing, and automated testing in particular, is not one of them. Few courses and books exist that talk about testing, especially automated testing, and they have much less detail than you'd find in a Compiler book, for example. As a result, I have the opportunity to shape the way testing software happens in my job - I can figure out what a good test looks like, how it works, and how it communicates with the outside world. This fourth point, by the way, is one major reason I have this blog. I am working on the problems of defining what good tests are and looking for strategies and tools for making them work well, and I intend to publish some of those efforts here both to share my hard-won experience and to try to pick up experience from others who stop by and have been where I'm going.

How about a different perspective? Our group recently picked up a few college interns called "Explorers", who spent a day or so job shadowing full time members of our team in each discipline. Here are some things they had to say about the experience of watching SDETS specifically:

* Most of the internal tools written here at Microsoft are written by SDETs. Due to the nature of the SDET job, they might have spare time with which they are encouraged to put towards the use of personal projects. These can range from doing community support on the forums, maintaining an employee blog, or writing a whole new tool to make your life (and those of others in the company) easier. Often, people will collaborate informally on a tool, and when it goes ‘public,’ (ie, others in the company start using it), other users are usually allowed to make their own changes or implement their own features.

* There are about 55,000 test cases in ASP.NET, with several thousand per feature (>4,000 for the database connectivity stuff alone). Although that sounds like an enormous number, it becomes more plausible when you consider the scope of each feature; the data connection stuff, for instance, can connect to a SQL database, an object file, XML, etc, etc. Then there are sub-features of each, and you have to test the way everything interacts with each other. After a while, the numbers start to add up, and you start wondering if 55,000 really is enough.

* I need to get comfortable with using a debugger.

* Testers actually do quite a bit of coding! There is far more coding involved than I expected, and the system used to capture errors or defects is very elaborate. There is also much less ‘hands-on’ work with the product being tested than I anticipated – they can run a battery of tests and verify that a feature is not working correctly without manually interacting with the product. Very cool, and I definitely learned a lot.

Regex Builder

ScottLouvau — Wed, 29 Jun 2005 08:20:00 GMT

One thing I'd better post about is a tool I've written and posted on the Internet, Regex Builder. You can find it on a GotDotNet workspace. In my own work (testing my parts of Visual Studio) I frequently work with strings, and I've discovered that Regular Expressions are a very nice way to take care of many tasks. Unfortunately, they can be very painful to debug when something is wrong; the framework can't tell you much more than "Nope, no match".

Regex Builder is a tool designed to help with that. It's not terribly complex - you provide the Source Text, the Expression, identify the options. It will tell you about the Exception thrown, if any, and otherwise will indicate the number of matches. It will also give you a tree of all of the Matches, Groups, and Captures in your expression. You can select anything in the tree to see it highlighted in the Source Text, which is useful for seeing how whitespace is being matched. Also, you can select a portion of the expression to execute just that portion. I use this to separate the components of my expression to quickly determine where the problem is. Finally, there's a menu which helps by showing you many of the syntactical elements of .NET Regular Expressions and easy links to the help.

Want an example? Today I was trying to write an expression to verify that two Label controls in an ASP.NET page were placed directly next to each other. The (desired) markup looks like this:

<asp:Label
    id="Label1"
    runat="server"
    Text="Label" /><asp:Label id="Label2"
    runat="server" Text="Label" />

My initial guess at a match for the expression was this: <asp:Label[^>]+Label1[^>]/><asp:Label>. Conceptually, I'm looking for a Label which contains the string "Label1", without leaving the tag, followed immediately by a second <asp:Label>. This, of course, didn't match.

Fortunately, the support code which executes my expression grabs the failure and generates an XML file with the Source, Expression, and Options, and this file format can be read by Regex Builder. It then writes to the log a command I can run from the command line to diagnose the problem. I copy and paste this into a command line, and I'm seeing the non-match.

First, I selected the first half of the expression, "<asp:Label[^>]+Label1[^>]/>". This didn't match anything, so there's a problem here. I selected just "<asp:Label[^>]+", which did match, and then noticed that the second [^>] does not have a '+' after it. This means I only want one character after Label1 - oops!. I changed this half to "<asp:Label[^>]+Label1[^>]+/>", which successfully matched the correct part of the file.

However, the whole expression still isn't matching. Hmm.. The end portion is quite simple, and I notice that I put the '>' right on the end of it - I've been working on reviewing the documentation recently and that's the way they write out tags. I removed that, and now things are working nicely. Three minutes spent, and "<asp:Label[^>]+Label1[^>]/><asp:Label>" became "<asp:Label[^>]+Label1[^>]+/><asp:Label".

Who am I?

ScottLouvau — Wed, 29 Jun 2005 07:21:00 GMT

My name is Scott Louvau, and I'm an SDET on the Visual Web Developer team at Microsoft. I'm blogging to talk about my work and my product, and about some aspects of my personal life as well. I'm interested in connecting with my peers and my customers, and particularly in learning from them!

Welcome, and I hope you read something interesting here. =)

-Scott