DevSource: What's the dumbest thing you were ever asked in a technical job interview? What was the best question you were asked?

Currie: I don't recall a single interview question that stands out as the dumbest, but there are two categories of questions that I consider to be very dumb.

The first category is brain teasers. These are the questions that usually require either some big "Aha!" or having heard the question before in order to successfully answer it during an interview. The stupid "three lightbulbs" question is a great example of a brain teaser.

DevSource: Three lightbulbs?

Currie: There are three lightbulbs in a small room that are wired to three standard switches outside the room. I will close the door to the room, give you the opportunity to manipulate the switches however you like, open the door, and then examine the lightbulbs however you like. From this one cycle of manipulate/examine, tell me which lightbulb corresponds to which switch. (All lightbulbs start in the off position.)

The Solution: Turn one switch on. Leave one switch off. For the third switch, turn it on, leave it on for a minute, and then turn it off. Then enter the room. The lighted bulb corresponds to the switch you turned on. The unlighted bulb that is cool to the touch corresponds to the switch you left off. The unlighted bulb that is warm to the touch corresponds to the switch that you turned on, then off. (Note that this solution doesn't work well for LED or flourescent lights.)

These questions tell you very little about the technical skill or problem solving capabilities of the candidate. Sometimes you'll get clever and creative answers to these types of questions, but clever and creative people will likely give you similarly impressive answers to questions that are substantially more interesting.

The second category of very dumb interview questions appear to be designed to determine if the interview candidate is a walking programming language specification document. In these cases, the interviewer will pick out the pettiest possible detail of a specific programming language (C++, C#, VB, Java, whatever) and present a programming problem that reveals the candidate's knowledge of this obscure syntactic idiosyncrasy. At Microsoft, and more specifically on my team, I much prefer to have a coworker who is smart enough to solve hard problems (and maybe learn some crufty language syntax along the way) than someone who has an encyclopedic knowledge of any given programming language. And this is coming from someone on the C++ compiler team, where knowing a lot about the deep details of the C++ language can be more useful than on most teams.

I've never been asked what I consider to be the best and most essential interview question. When I am interviewing candidates for the Visual C++ team, I will normally pick the most recent project from their resume and ask, "Who were your customers and what do they care about?"

I don't care if you are a developer, QA, manager, college student, or English professor. If you can't answer that question quickly, confidently, and correctly, you either haven't thought hard enough about the problem you are trying to solve or you don't have the right priorities. You can't do your job effectively without knowing the answer to this question. What are your key scenarios? What features do you build? How do you limit the scope of a given feature for this release? What does the user model for the feature look like? What does the UI look like? What scenarios do you test? How do you prioritize bugs against each other? What should the performance characteristics look like? What should your timetable look like? You can't answer any of these questions without knowing your customer and knowing what they care about. You might be surprised how many people don't even know who their customers are.

DevSource: Programmers have different ways of solving problems. Some people are detail oriented, others try to grasp the whole picture before they write a line of code. Some create an entire back end before they punch through a "hello world" user interface, while other people write UI-centric code (and tack on a back end afterwards). How do you approach coding?

Currie: It really depends on how hard the problem is. Since we have so many issues competing for our attention, we have to be practical and make the right calls about how to best spend our time.

If we only need to adapt existing technologies to solve the problem rather than developing substantially new technologies, we will usually examine the problem in a meeting with the technology and scenario experts and come to a consensus on the right solution. That solution will be specified in a document and reviewed by the team. Detailed developer implementation and QA test plans may also be prepared depending on the scope and impact of the proposed solution. Then it's just a matter of scheduling work and driving it to completion.

For problems that require new technology, we invest much more. In these cases, I want to have a firm handle on the customer scenarios, design issues, algorithmic issues, the UI issues, anticipated performance bottlenecks, test strategy, resource allocation, and expected cost before I write the first line of code or ask a developer on my team to do so. Of course, as unanticipated problems are discovered, schedules are changed, new partners are introduced, requirements and dependencies are adjusted and a variety of other changes take place, these plans need to be modified. Consequently, I'll usually try to do some thinking about the flexibility of the strategy we are taking on the problem and how likely we will be able to maneuver around these issues as they arise. Of course all of this understanding must be encoded in documents that are reviewed by all of the key stakeholders within the company and sometimes key stakeholders outside the company, as well. Failure to do this level of planning will usually result in at least one rewrite of the entire solution. Trust me. I know from direct personal experience!

DevSource: You've worked with a lot of ISVs and other developers who use C++ a lot. What mistakes do you see made most often?

Currie: The developers I've worked with have universally been very smart and passionate about their customers. From a technology perspective, they have overwhelmingly been making the right decisions for their business, customers, technical domain, available resources, and other factors.

There is one consistent mistake that does come to mind, though. Most of our customers don't fully leverage many of the great resources that Microsoft and our strong customer communities have built on the Internet.

I usually ask our customers what their daily and weekly reading lists look like. Since our customers are always trying to push the limits of what is possible for each product release, they don't have much time left over for watching channel9 videos or reading a variety of blogs, devcenters, newsgroups, or articles. In many cases, they aren't even aware that these resources exist. Currently, a substantial time investment is often required to find some of the most relevant community content for their business and technology.

To a large extent, this falls back to Microsoft and the community. We need to find better ways to make this information available and discoverable to members of our community. In the meantime, our customers would be more effective if they took 15-30 extra minutes a day just reading community generated resources. These resources provide great information about scenarios, technical details, pitfalls, tips, tricks, and other valuable content. They will be able to avoid potentially major mistakes and know much more about the platforms and tools that they use every day to build their products. Get started by looking at http://blogs.msdn.com and http://msdn.microsoft.com/visualc.

DevSource: How (if at all) have blogs and discussion areas (such a channel9) changed the way you work?

Currie: I think that blogs are very effective at the type of communication that customers previously got only if they had a 1:1 conversation with a Microsoft employee. The rationales behind the decisions we make, the passion for our customers and technology, and the cool things we have planned for the future rarely get communicated to developers through other channels.

So, how have these resources changed the way we work? At least one person on every team is likely to be an active blogger. That means that we get much more transparency out to the community, we get frank feedback from customers about this more transparent view into Microsoft, and ultimately we make decisions that better satisfy our customers. In the future, I see blogs being part of a much larger community connection strategy that we'll use as a more integral part of our formal product process. Maybe we can do another interview about that once more of it is ready to go online.

DevSource: There seem to be some kinds of errors we each have to make personally; others can't "educate" that knowledge into us. Hopefully, we make those mistakes on a small scale, so the lesson isn't terribly painful. For teenagers, it's "This is the wrong person for you to fall in love with." For computing end-users, it's "you really do need to back up your data." What do you think are the "you have to learn it yourself" lessons for software developers?

Currie: Beginning developers seem to believe that if they think hard enough about it, they will get an accurate picture of how customers use their products. This turns out to almost never be the case. Moreover, for all but the simplest and highest level scenarios, developers cannot be taught how customers actually use the software they develop. You have to sit down in a room with your customers and watch them work. There is absolutely no substitute for this.

DevSource: What do you think are the big unresolved issues in the software development process? How come we haven't solved them yet?

Currie: There are a large number of unresolved issues in the software development process, but I want to focus on one in particular that we have the ability to impact significantly in the next 5-7 years.

The tools currently used in software development, those produced by Microsoft and other companies, generate tremendous amounts of information about the customer's program, use that information for a highly specialized purpose, and then promptly discard that information. For example, a modern optimizing compiler computes detailed maps of dependency chains, memory aliasing, and a wide variety of other program characteristics. The compiler effectively uses this information to perform optimization, but none of the other development tools are able to use it to accomplish their tasks. Tools like PREfast compute their own versions of some of this information, but they could be much improved by having access to the superior data generated by the compiler back end.

Even more interesting, the IDE could visualize much of this information in useful ways to enhance design, debugging, and code editing experiences. Let's say you have a funky value sitting in some memory address, and you want to figure out where it came from. How would you like the IDE to instantly give you a list of every code location that could have modified that memory? No need for memory breakpoints. No need to step through code. The information that is statically generated by our developer tools, in combination with runtime information from the debugger, could provide this experience. And this is only the tip of the iceberg.

It is just disappointing to see how much information is being generated and wasted and what kind of amazing user scenarios could be enabled if that information was preserved and effectively leveraged across the entire toolset.

Within Microsoft we are doing some interesting things to try to solve this problem. One of the cool things is a new compiler backend that exposes all of its internal data structures out through a rich set of APIs for other tools to use. It's called the Phoenix project and you can find more information about it here.