The On-Campus Interview Process at Microsoft

At Microsoft, on-campus interviews for external candidates typically go roughly as follows (transferring teams internally require interviewing too, but the process is slightly different):

1. Check in with the recruiter managing the interview process
2. Meet with the hiring manager for a short conversation about the team and an initial interview
3. Interview with about 4 members of the team
4. If all goes well, interview with an "as-appropriate" interviewer
5. Meet with the hiring manager and/or recruiter again to wrap things up

The first conversation of the day, with the recruiter, is light and informational. The recruiter will let the candidate know what the day's schedule looks like and possibly chat about the team and the location (i.e. Redmond, Silicon Valley, Charlotte, etc.). They will often suggest a few useful tips like to try to relax and have fun, to ask questions to get a feel for the team, etc.

The first conversation with the actual team is usually with the hiring manager. They will often tell you about the team and warm you up with conversation about yourself. Some hiring managers will conduct actual technical interviews at this time and others will just get a feel for the candidate's cultural fit, leaving it to the remainder of the interviewers to test the candidate's technical skills.

The interviews with the actual team will definitely involve some technical interviewing. For software engineers, this means getting up in front of a whiteboard and working out challenging design or coding problems. Typically, each interviewer will be evaluating a particular skill set (algorithms, design, coding, etc.). If a candidate doesn't meet expectations in an earlier interview, a later interviewer may assess one or more of the same areas since (most) interviewers acknowledge the fact that nervousness can affect performance during interviews. One may also notice that interviews often start off with 5 to 10 minutes of friendly conversation. This is to help the candidate feel comfortable in the hope that they won't feel as nervous during the technical portion of the conversation.

What kind of whiteboard questions are asked? This is highly variable depending on the interviewer. Over time, most interviewers develop a methodology for assessing candidates. For testing technical capability, I personally like to start with a simple coding question, followed by a more complex coding question, followed by an open-ended design problem. I sometimes reverse the order of the second coding question with the open-ended design problem to base the coding question off the candidate's response to the design problem. Whatever the case, I try to be consistent to make a fair comparison among candidates. Each of the interviews with the team are about an hour long, so there is definitely a time squeeze when trying to get through these three problems.

Most technical interviewers will also take some time for two additional things. The first is to find out a bit about the candidate's characteristics. This frequently falls into those first 5 to 10 minutes of friendly conversation. The second is to let the candidate ask questions about the team, product, and/or company. The candidate's opportunity to ask questions almost universally comes in the last 5 to 10 minutes of the interview. After the hour is up, the candidate is handed off to the next inerviewer.

One of the team interviews will be over lunch and will be less technical in nature (no, you don't have to code while eating). I have seen some interviewers discuss a design problem over lunch, but most will have a deeper conversation about the candidate to root out their characteristics and about what they are looking for career-wise. Clearly, there are no right or wrong answers here. Just be honest, reflective, and thoughtful. Always remember that it's best to identify a poor fit as early as possible. Not only will adding someone who is a poor fit to the team be damaging to the team, but it will also be harmful to the candidate, who will suffer career stagnation and will be generally unhappy in their job.

The as-appropriate interviewer is someone who has been a Microsoft employee for a long time and who has had more hiring experience than the other interviewers. This interviewer is usually focused on the candidate's long-term potential at Microsoft. Sometimes this interview is technical, but it is almost always heavily focused on on the candidate's characteristics. Unfortunately, it can be pretty hard to tell if you're interviewing with an as-appropriate interviewer, but if you are, it's a good sign. This interviewer is called "as-appropriate" because they don't participate in the interviews if the team doesn't feel positively about the candidate.

To wrap things up with the team, the candidate will often chat briefly with the hiring manager again. This is usually just to discuss how the candidate felt about the day, answer any final questions the candidate might have, and possibly sell the candidate on the team. Depending on the situation, candidates may also have a final chat with someone higher up the hierarchy than the hiring manager. If this happens, it is usually because the team already decided that they like the candidate and really want to sell the candidate on the team. As with the as-appropriate interviewer, this is a good sign.

Sometimes, candidates will also meet with the recruiter at the end of the day. The recruiter will probably have a few questions about how the day went and might offer some suggestions of things to do while visiting the area if the candidate is from out of town.

Although it is reasonable to be eager for feedback, don't expect any indication of the results until the recruiter follows up. The team will make a final decision within a few hours after completion of the interviews and may have other candidates to follow up with. Also don't execpt any information as to why or why not a hiring decision is made. Again, it is understandable why one would want additional information, but for legal reasons, it is inappropriate to discuss the reasoning behind the decision and such information simply won't be provided.

Candidates are typically notified of the final outcome of the interview by phone within two weeks. If the teams decides to extend an offer, the recruiter will follow up the phone call with an offer letter, which will include details such as salary, etc. If the fit wasn't right, this will be the final contact, but don't forget that if you feel Microsoft is an important part of the path to your goals, be persistent and keep trying!

For an example of a technical interview (one of the interviews from step 3 of the day), see this post.

Scaling a Portion of Xbox Live on Azure

It's been a crazy couple of weeks here on the Xbox Live team. We publicly released a major update to the console on the 6th and a bunch of new apps went live during each of the proceeding weeks. My sub-team with the broader Live team builds our services on Windows Azure. The scalability of Windows Azure has been a real asset in meeting the high demand brought on by the new releases, but there have also been some challenges.

Azure allows us to not wory about managing hardware. When we needed to bring up additional instances of roles (for those unfamiliar with Azure, this is analogous to adding additional VMs to the system) to meet demand, it was just a matter of a 15-second adjustment to a config and everything else was automatically handled by Azure within minutes. Because Azure uses upgrade domains (i.e. no more than a certain percentage of the VMs will be taken down at a given time) to perform upgrades, updates are performed without downtime. There are a couple of important lessons we learned about working with Azure from this experience.

1. Include consideration for Azure capacity limits in our scalability plan. Azure is built on clusters of hardware and services are run within a multi-tenant cluster of limited size. Because of this, it is possible to reach capacity within a particular cluster. The Azure team works to ensure all tenants in a cluster have space to grow, but some services are just too large. This was the case in our situation. To deal with this, the Azure team worked with us to provide the additional capacity we'll need for the near-term. However, in the longer term, we may need to be able to run across multiple clusters, which means running additional instances of our services. The challenge we foresee will be around routing requests to the various endpoints. This could be solved by having a front-door service, but if that has to scale beyond a single cluster, we will be in the same situation. A better solution may be an endpoint look-up service that can split traffic accordingly. However, this may also hit scalability limitations. At that point, we'd need to either work with Azure to figure out how to handle this or do some clever DNS tricks.
2. Plan ahead for the correct number of upgrade domains. In our system, we retained the number of upgrade domains used when we orginally deployed. As we began to scale, we realized that the number of upgrade domains we were using was too small as the number of role instances that were taken down at one time during upgrades was too large. It's important to keep in mind that when some percentage of role instances are taken down, the traffic that would otherwise be directed to those instances is now redirected to the remaining live instances. This means, the remaining instances must be able to support that flash of additional load without falling over. Something else to be aware of is that changing the number of upgrade domains requires deploying a new build rather than a simple config change.
3. Prepare for doing DNS swaps. Sometimes in-place upgrades and VIP swap upgrades aren't possible. There are a couple of changes we have made to our services in the past few months for which the standard upgrade procedures facilitated by Azure are not allowed. One such case is the addition of new endpoints in our services. A look-up service is a good solution to this problem since it allows us to redirect clients to updated service instances. However, what happens when we need to update the look-up service? In such situations, a DNS swap is applied. A DNS swap means that we bring up a second instance of the target service and change the DNS records so client traffic is routed to the new service instance. Some important things to keep in mind are that it's a good idea to have an additional service slot ready to deploy to since we wouldn't want to have to set this up under the pressure of dealing with scalability issues or other problems.
4. Account for the flood of traffic caused by a VIP swap or DNS swap. VIP swaps and DNS swaps can cause a set of endpoints to see traffic go from non-existent to very high in a very short time. One way to handle this is to seed the new service. For example, if caching is a concern, pre-populate the cache. This is not always possible though, so an alternative is slowly redirect traffic in stages, giving the new service a chance to ramp up before redirecting the entirety of the traffic. One important alleviation this provides is reducing the effect of the traffic spike on whatever persistent storage system is being used.

There are several additional lessons we learned from our use of Azure Storage. These lessons were primarily around understanding how our system consumes storage, what our user traffic looks like, and architecting the system accordingly. The properties of Azure Storage are fairly well publicized and it is important to keep Azure's behaviors and constraints in mind during the design of the target system. To be clear, this isn't meant to imply the waterfall development model should be used, with all the design being done up-front, but rather to keep the information in mind whenever thinking about design.

1. Know what assumptions are being made and their potential impact. There are many assumptions that are made during intial iterations of building a system. Some of these include what future client traffic patterns will look like, what level of scale needs to be reached, what parts of the system will be exercised most frequently, etc. These assumptions should be identified as early as possible and challenged with what-if scenarios. We made some incorrect assumptions about the level of scale certain parts of our system would have. For these particular areas, we were using reverse-timestamps as a prefix for our partition keys when accessing Azure Storage. This is a common scenario, as having the most recent items at the top of the table is useful for processing the data. However, sequential access patterns aren't handled well by Azure Storage, causing requests to get throttled as the scale increases. The best option is to randomize the partition key somehow. This is not always possible though, depending on the requirements around reading data. In our case, it made more sense to use a bucketing mechanism that divides the traffic into several buckets and within each bucket, use the reverse-timestamp. As traffic increases, so does the number of buckets, so that while we still end up with the desired sort-order, we are no longer bottle-necked by the storage limitation.
2. Design the system's storage access patterns. This is directly related to the above item. To know how the system will behave when traffic starts flowing in, one must be conscious of the storage access patterns it uses. We must take great care to design our storage access patterns so that they don't become a bottleneck in our system.
3. Understand where concurrency is an issue. It has been a recurring problem for us since we do a lot of asynchronous processing. The major issue is a typical one in distributed systems: agreement and dealing with failures. One significant limitation in Azure Storage is the throughput of an individual Azure Storage message queue, which is about 500 requests per second. Clearly, this is insufficient for a large-scale distributed system. Thus, one needs an agreement mechanism (most likely PAXOS). An obvious solution to increasing queue throughput is to pack multiple messages into a single message or to use multiple queues. However, packing multiple requests means risking data loss during accumulation, which is often unacceptable, and using multiple queues requires agreement about which processors should access which queues. It might seem straight-forward to say processors should do round-robin access of all queues, but we found that this can overload the queues if the workers synchronize in their round-robin selection, cause retrieval of the same message many times since Azure only guarantees messages are delivered at least once, and it can be a fair amount of work to develop a queue management system, which has many of its own problems. In the end, we decided to remove the use of Azure queues from our since the guarantees it provides beyond those of blob and table storage are unecessary for us. We do, however, expect to come back to re-evaluate the use of queues at a later time. To summarize, the following led us away from queues: messages can be processed multiple times, message order isn't guaranteed, and there is a low per-queue scale limitation. This means the processors must be idempotent, able to process correctly regardless of order, and require additional mechanisms to scale. Thus queues don't really save us any work for our particular case.

Xbox Gets Voice Control, Search, and More

Congrats to the Xbox org and the Xbox Live services teams at Microsoft! Today, we publicly released the latest updates to the console and the backend services supporting it. With the update comes a plethora of cool technologies like voice control, search, and more.

Xbox is in a great position to lead a revolution in the way we consume and interact with media. I believe this revolution is already in progress and it's not a unique opinion (see here). However, it is possible that I've just drinken the Xbox Kool-aid. Whatever the case, I'm excited about the future of interactive media and computing in the living room.

Television has offered the same consumption model for decades now. In about the last 10 years we have seen some movement from the likes of TiVo, Netflix, Amazon, Hulu, and others moving us in a new direction, yet I still see most people tuning into their favorite shows at the network-mandated day and time. What's worse is that we just pull the media in a passive manner. There's limited interaction whether with peers, other audience members, or the collective community. Why can't you chat with other viewers during the show? Actually, you can, but not in a seamless, appealing way. You can vote on shows like American Idol, but you have to send a text message from your phone. Why isn't this more fluid? We should be able to say the name of our favorite contestant a la Kinect to cast our vote at the end of the show.

I think Xbox and Microsoft are in a great position to change this. Amazing technologies have been released over the past couple of years and there are many more to come. Xbox is in tens of millions of living rooms with a large portion of those people subscribed to Xbox Live. Live provides access to some powerful services including a marketplace where developers can submit apps for consumers to download. There are cutting edge input mechanisms such as Kinect's skeletal tracking and voice recognition. The possibilities for innovation are boundless and startups are already working on creative ideas. In fact, Microsoft and TechStars are joining forces to co-sponsor a Kinect-based startup accelerator program.

With the stage set like this, I think it's safe to say that we have a very exciting year ahead!

Regular Expressions Rock!

A colleague at work recently cobbled together the following regular expression, but wanted help to better understand it.

^(?:(?!(core\.windows\.net)).)*$

This regex is intended to match anything that is not a Windows Azure Storage URL. It essentially looks for strings that do not contain "core.windows.net". Here's a breakdown of the regex from the inside out:

1. \.: Character match. Matches '.'. The '\' character escapes the proceeding character.
2. core\.windows\.net: Word match. Matches the text "core.windows.net".
3. (core\.windows\.net): Text grouping. Treats the "core.windows.net" text as a group.
4. (?!(core\.windows\.net)): Negated look-ahead assertion. From the point of evaluation, fails the match if the proceeding text is "core.windows.net".
5. (?:(?!(core\.windows\.net)).): A non-capturing match-all. The "(?:" means that that the contents of the grouping, which would normally be made available for retrieval after evaluation, are not captured for retrieval. The '.' matches any character, unlike the escaped "\.", which matches a '.' character.
6. (?:(?!(core\.windows\.net))*: Repeat the evaluation any number of times.
7. ^(?:(?!(core\.windows\.net)).)*$: Do not match if any character from the start to the end of a line is followed by "core.windows.net". '^' denotes the start of a line and '$' denotes the end of a line.

The key to understanding this is to really understand how the negated look-ahead works. Here's an excellent reference for regexes. The reference is specifically for perl, but the concepts are nearly the same across all systems that support regexes. A good question is why we can't just write something that fails if a body of text contains the target text? The reason is that regular expressions do not support such a simple negated expression, so what is shown here achieves that functionality through alternative means.

This regex is interesting because it requires a strong understanding of how regexes work versus a simple regex like ^abc$ (which matches lines containing exactly the text "abc"). To really understand it, one must understand the implications of the behavior of the negated look-ahead, which does not "consume" text. Likewise, the non-capturing grouping is about memory efficiency rather than having anything to do with the correctness of the expression.

Regular expressions are a very powerful tool for matching and retrieving data from text. They are usually concise, replacing lots of custom parsing with one clever expression. They are also easy to test in the same way the custom parsing would be tested. That is, pass them various texts and check for the expected output.

Thinking about the problem above actually leads to a great interview question. "Write a function to evaluate a set of strings to determine whether they contain <some complex pattern>?" An example complex pattern is valid email addresses. Clearly, it's possible to code up some custom parsing or devise a regex. Either way, the candidate will need to do some abstract thinking, identify edge cases, test for correctness, and explain why their solution works They should also be able to do this relatively quickly. If the candidate evaluates the trade-offs of using the different methods (regexes are not always simpler), it shows practicality in their approach to problem solving. Familiarity with regexes is also good in that it shows that they are knowledgeable about technologies that are not often taught in schools.

Characteristics of Successful Job Applicants: Coachable

This is the last in a series of posts on the characteristics frequently present in successful candidates for jobs at Microsoft. Previously, we discussed the importance of being a good communicator, persistent, passionate, a continual learner, and reflective.

Coachable

I the last few posts, we've talked a lot about learning from others, which leads to the last area covered in this series. Being coachable means being willing to accept the advice and experiences others share with you. It is critically important to understand that this doesn't mean you have to agree with what others are telling you. In fact, the conversations you'll learn most from are probably those in which you disagree with your counterpart. This is because having your views challenged forces you to provide supporting evidence and to consider alternative approaches. Being coachable is having open ears and a willingness to factor the advice and experiences of others into your evaluations.

Again, don't be scared to admit what you don't know and to seek help figuring things out. As discussed, extensive experiences are good, but if you have some guidance to reduce the amount of friction you suffer along the way, why not take advantage of it?

When I was in school, a big failure on my part was my reluctance to ask for help. When I had difficult programming assignments I would struggle for hours to find subtle bugs, refusing to ask for help from TAs or peers. I loved the tasks (passion), fought until I succeeded (persistence), and learned from my mistakes (reflection and continual learning), but in so doing, I probably lost hundreds of hours in aggregate, which I could have applied to more beneficial tasks like doing additional testing, reading for outside interests, or working on personal projects.

Another critical aspect to understanding what it means to be coachable is to understand that when people give you feedback, you really need to digest it. Don't seek feedback for the sake of marking off a checklist. If that's your goal, you can accomplish it without wasting someone else's time. When someone offers you feedback, use it. And if you want more feedback, be able to demonstrate that you used it. A common question among students looking for internships or jobs at Microsoft is what classes they should take. If you get a suggestion, either follow through or be able to explain your process of consideration and why you decided it wasn't in your best interest. If you come back to interview with that same person and you didn't take the time to consider what they suggested, it leaves a bad impression. Why would they want to hire someone who either doesn't take their opinions seriously or doesn't follow through?

Concluding Remarks

To wrap up this series of posts, observe how the different characteristics are inextricably linked. Passion drives persistence. Reflection helps understand passion and leads to learning. Good communication skills and the ability to learn are required to be coachable, which in turn increases the effectiveness of persistence. All of these characteristics are strongly correlated with success, which is why we look for them in candidates.

There are a few important things to keep in mind when reflecting (yes, that was intended - sorry, I couldn't help it) on all of this information. The first is that the descriptions of these characteristics may appear to have been very black and white, but the reality is that these characteristics do not manifest themselves as binary attributes with on-off switches. They are continually developed over a lifetime. The second is that they must be balanced. Spending the entirety of one's time focused on a single aspect and ignoring others is detrimental to one's development. It is much more effective to spread effort across the different characteristics and leverage them to enhance one another. Think of them as your vitamins for success. There are undoubtedly times when it is appropriate to increase the dosage of one, but you need to get enough of each of them to remain healthy. The last thing to keep in mind is that these are not the only important characteristics. They just happen to be fairly universal. Whenever you apply for a job, or identify any goal for that matter, take time to evaluate how you will achieve success and follow up with the appropriate actions to prepare yourself.

Characteristics of Successful Job Applicants: Reflective

This post is part of a series of posts on the characteristics frequently present in successful candidates for jobs at Microsoft. Previously, we discussed the importance of being a good communicator, persistent, passionate, and a continual learner.

Reflective

If you've been reading along with the series of posts, hopefully you've picked up on the recurring theme of being reflective. Someone who is continually evaluating themselves and their surrounding environment is someone who can identify opportunities for personal growth and to improve efficiencies. This is tightly coupled with being a continual learner. How does one know where to apply the bulk of their learning efforts, given the limited time capacity we all have? Through reflection and deep personal exploration.

Every experience is an opportunity to analyze the outcomes of actions taken against the intended goals. If you endure a significant failure, don't let it go to waste. Take the time to do a post-mortem and identify the shortcomings that lead to failure. When you have a major success, get a sense for how you were able to achieve that success. In some cases you will not be able to form a concrete answer due to the number of variables, but over time you will be able to identify commonalities across your various experiences. Aggregate experiences will lead to generalized problem solving skills and a large toolkit on which to rely. This is called "wisdom".

No matter how intelligent you are, it's still critical to your development to gain certain experiences. Admit what you know and what you don't know. I would wager that most interviewers at Microsoft can tell when someone is spinning a bunch of bullshit and when they genuinely know what they're talking about. Interviewers don't like having their intelligence insulted, so acknowledge your shortcomings and be prepared to demonstrate your strengths. If you're in the habit of reflecting on your skill set, you'll know where you fall short and where you excel. You've also hopefully been making a concerted effort to improve the areas in which you are week or have made the conscientious decision to avert attention to other areas for good reason, like the desire to be a specialist.

But what about learning from others? Don't forget that when someone takes an hour to explain a year's worth of experience, they are leaving out 8759 hours of detail. Most of that detail is probably mundane, but much of it is why they will be progressively more successful as they continue to pursue their goals. Consider the experiences of others as guidance. They help serve as a compass when we're searching for the right path, but to reach the destination, you still have to do the walking yourself.

Read the next article in the series here.

Characteristics of Successful Job Applicants: Continual Learner

This post is part of a series of posts on the characteristics frequently present in successful candidates for jobs at Microsoft. Previously, we discussed the importance of being a good communicator, persistent, and passionate.

Continual Learner

Here's something really hard to convince yourself of: it's okay to fail. It is not, however, hard to find numerous resources extolling the benefits of failure (if you watch the linked video, notice that Randy mentions lack of passion as a cause of a personal failures). If you need additional convincing, try doing a web search on "benefits of failure" or "failure is good".

For those who are (now) convinced, it's time to live up to this principle. Admit to your failures. That's the hard part. You can't talk honestly about the experience of failure or what you learned from it until you're able to admit to it and own it. And to be able to successfully interview at Microsoft, you want to be ready to have a conversation about your failures.

Many people preach the message of the importance of admitting failure and learning from it, but from my experience, a large portion of these people, including myself, do not practice what they preach nearly enough. A personal example is that for a long time I was unwilling to reveal that I had been rejected when I applied for a job at Google. I would talk about the experience of the interview and walk around the subject of whether I had received an offer. Why was it difficult to get to the point where I was willing to admit it? This has to do with the psychological response to rejection. Not receiving an offer made me feel like I wasn't good enough for the job. By itself, this was not so bad. However, a more difficult pill to swallow was that many of my friends and colleagues received offers for similar positions at Google. So I was dealing with both self-doubt and a sense of inferiority (relative deprivation) to those closest to me. Perhaps it is true that I am not as smart or qualified as my friends, but the truth is that it doesn't matter. I needed to admit to the failure, determine how it relates to my goals, and figure out what to do next. If the specific job is not required to reach my goals, I should include alternative options in my consideration of how to follow up. If it is required, I should identify the causes of failure and continue trying (persistence!). Until I admitted to the failure, if I had tried applying for a similar position again, I probably would have been met with same result. One who is unable to admit that they have failed is unable to admit that they have made mistakes. One who is unwilling to admit to having made mistakes is unable to identify how to fill the gaps that led to failure.

Over your career you should expect to fail many times. In fact, as you progress, you should carefully consider whether you're failing enough! If you never fail, you probably aren't pushing yourself hard enough. Seeing that someone is capable of learning and growing from both failure and success is important to Microsoft. We want to see people who will continually grow and improve rather than stagnate.

I've spent a lot of time talking about learning from failure, but that's not meant to trivialize the importance of learning from other sources. Clearly, high-tech jobs also require people to keep up with the rapid pace of change in technology and in business processes. This means finding various ways to learn about the newest technologies and practices. One who is versed in these trends will introduce new ideas into their organizations along with opportunities to capitalize on the potential efficiencies and competitive advantages those ideas bring. Such an individual will be rewarded with career growth as they become recognized for these contributions.

To keep things grounded in reality, we must also account for the need to keep everything in balance. If you spend all of your time experimenting with new technologies or processes, you leave little to no time to complete required tasks. Inability to deliver is just as bad or worse than the inability to adapt to change. Further, the benefits of new technologies and processes take time to materialize, meaning that if change is too frequent, the benefits never have a chance to surface, often resulting in more harm than good.

Outside of personal experiences related to success and failure, there are a multitude of sources from which you can learn. Some examples include co-workers, friends, books, the Internet, school, seminars, mentors, etc.

On a side note, I want to encourage everyone out there to go out and mentor someone (cheers to those already doing it!). Your experiences can really help someone else grow. If you're already employed, help college students who want to work in a similar field. If you're in college, help a high school student through the application and selection process. You'll find that the conversations you have with proteges will lead to your own personal growth, along with the development of leadership skills. Plus, it can be financially rewarding due to the benefits to your career!

Read the next article in the series here.

Characteristics of Successful Job Applicants: Persistent

This post is part of a series of posts on the characteristics frequently present in successful candidates for jobs at Microsoft. Previously, we discussed the importance of being a good communicator.

Persistent

I know that for some, the term "persistent" conjures up images of a car salesman who repeatedly lowering the price on a vehicle to stop you from walking out the door, each time complaining about how they're losing money on the deal. However, this is a mischaracterization of the term since it frames the situation around the questionable fact-skewing.

I believe that most people you talk to (including myself) will admit to endearment with stories about triumphing over significant challenges along the path to eventual achievement of one's goals. Usually, the more lofty the goals, the more challenging the journey. By definition, the protagonists of these stories are persistent. Outside the realm of fiction, think about what aviation would look like today if the Wright Brothers had yielded to the challenges they faced when experimenting with flight? Earlier this year, Airbnb received a $1B+ valuation, which wouldn't have happened if the founders had thrown in the towel at any of the many setback they've faced in building their business. This is a company that did some self-funding by creating and selling cereal, and which is still constantly embattled with new challenges like this, this, and this.

In short, people who are persistent don't give up in the face of adversity. Instead, they soldier on and accomplish great things. Microsoft prizes a person's ability to do this when evaluating long-term potential, which is a key factor in hiring decisions. This is also important for the day-to-day challenges software developers face like debugging, designing, and dealing with politics. Remember that interviews are about estimating how well you will do in the job and career you're interviewing for.

Software developers have to be able to focus and not give up when trying to solve difficult problems like finding and fixing obscure concurrency bugs. We can't justify deploying/shipping buggy code with the excuse that it's too hard to identify the problems. We dig in our heels, work through every line of code, write new tests, and crawl through references until we understand the problem and either fix it or determine that the fix should be postponed by weighing the cost of the fix against the severity of the issue. Every software developer I know has a story about spending days or weeks searching for the cause of a nasty bug. As a proxy for assessing your ability to do this, interviews for software engineering positions typically include time coding on a whiteboard. This test gives the interviewers insight into how you approach solving problems and whether your coding skills are adequate. The worst thing you can do during this part of the interview is to spend five minutes and give up. Although you may get a few easy problems in the course of your interview, you will definitely face a few problems that will be very challenging. Don't give up on these! If you get stuck, take a moment to step back and think about whether you're taking the right approach. Try to do this as early as possible so you don't spend too much time going down the wrong path. Also, proactively look for bugs. There's a good chance that you will have a bug you are unaware of because of some fringe case you forgot to consider. When your interviewer points this out, carefully analyze the code and figure out where the issue is.

Software design requires the ability to seek out the right technologies to build a solution to a problem and to figure out how to fit the pieces together. This is not necessarily as straight-forward as it sounds. When developing a web service, should we store data as XML, JSON, strings, a binary format, etc.? Do we need to implement client libraries to abstract access to internal services? What technology stack should we build on? We must insist on working towards a great solution and not just taking the first option we find each time we have a question. We must always be asking "why?" Another common component of an interview for a position as a software engineer is system design. For this type of question, you will get very open-ended design problem like how to build gmail. Interviewers will want to see that you're able to think through the requirements of the system, are aware of various applicable technologies, and are able to reason about which of the available options is most suitable to the system you are designing.

Questions around the right technologies to use brings us to politics. No matter where you end up working, you will face political issues (unless you are in the extremely rare position of having enough money to ignore everyone around you). In a big company, you will have to battle peers for the power and influence to push your brilliant idea forward despite staunch resistance from the status quo. Small companies might seem less political, but you still have to deal with satisfying investors and perhaps a few big key customers. Additionally, small fish look big in a small pond. In small companies, the little fish often let their perceived size go to their heads. On most days, you will deal with politics in some form or another and must have the resolve to fight for the right solution despite adversaries with greater political clout. During interviews, some interviewers may tell you there's a bug in your whiteboard code even though there is not. If you think through all the edge cases and verify that your code is sound, your interviewer may be looking for how you handle disagreement. If you think this is the case, be diplomatic in your approach to disagreeing with your interviewer.

In many cases, software engineers enjoy challenges like those listed here. They are like difficult puzzles that we eventually triumph over. We look for the same characteristics when hiring other developers to be on our teams. Aside from being prepared for whiteboard and design excercises, be prepared to talk about examples from your past that show off your ability to persist in the face of adversity.

One last comment about persistence. This is very important, so remember this. You must be persistent in pursuing your goals rather than in your approach to pursuing them. If you want to break down a concrete wall, you can be persistent about banging your head against it until it crumbles, but the wall will probably last longer than your head. As soon as you start to get a headache, you'll probably realize that a better approach would be to use a sledge hammer or wrecking ball. If not, you'll soon experience the cruelty of natural selection at work.

See the next post in this series here.

Characteristics of Successful Job Applicants: Passionate

This post is part of a series of posts on the characteristics frequently present in successful candidates for jobs at Microsoft. Previously, we discussed the importance of being a good communicator and being persistent.

Passionate

Thus far, we've covered persistence, with the interesting stories it creates, and good communication, which provides an engaging way in which to tell those stories. We still need a deeper understanding. The underlying driver one must be aware of is passion. Why are people persistent? Because they feel something deep down inside that pushes them to obsess over achieving some goal.

There are an infinite number of things one can be passionate about. A couple of examples include building systems that can scale to support millions of simultaneous users and security that is impenetrable to malicious adversaries. It's also common to have passions unrelated to engineering such as ensuring every child has an opportunity to learn or keeping families safe. Most people have multiple passions; the important thing is that you recognize what they are.

Passion essentially comes free since it doesn't need to be learned. It is inherent to being human. The other characteristics can take some time to develop since they require behavioral modification, but the only investment you need to make in regard to passion is to think a bit about what excites you. The easiest way to go about this is to repeatedly ask "why?" Take something you enjoy and ask yourself why you enjoy it. When you have the answer, again ask why that matters to you. After a few iterations, you will arrive at a core value, which you care about simply because it's part of who you are.

Let me give an example. I enjoy designing and building scalable systems. It's pretty awesome when a system scales to support tens of thousands of transactions per second or more. Why is that awesome? Because it's uncommon to have that kind of demand and when that demand exists, most systems fall over. Why does that matter to me? Because the that level of usage (hopefully) means customers love the product and it's very challenging to build a useful system that can support that transaction rate. Why does customer love matter to me? Because I want to enhance people's lives by enabling new experiences. And why am I interested in building things that are difficult to build? Because I enjoy challenges and the mental exertion involved in the process. We'll leave it at that for brevity, but you get the idea. As you can see, this exercise explores what defines us as individuals.

Showing passion is critical to your interview at Microsoft. If you are passionate about the work, you are more likely to enjoy the job and be a productive member of the team. Your passion will engender the persistence needed to uncover bugs, design and build complex systems, and navigate the waters of uncertainty that surround cutting-edge technology.

Your interviewer will want to know what drives you and it will be to your advantage if you've already thought about it. The typical method we use to try to figure out where your passion lies is to try to drive the discussion to a point where you basically forget that you're in an interview and begin engaging in fervent discourse. If your interviewer can't hit the right topics herself, that's a bad sign for the outcome of the interview. Usually this won't happen since you will have (hopefully) applied for the job due to a deep interest in some aspect of it. However, most people prefer to eliminate unnecessary risk from the equation. Don't be afraid to steer the conversation a bit and talk about the things you love. Just remember to be authentic; authenticity comes from understanding yourself, not from a rehearsed script.

See the next post in this series here.

Characteristics of Successful Job Applicants: Good Communicator

In the previous post, I shared some general thoughts about the mindset appropriate for pursuing high tech jobs. This post will be the first of several in which I will describe characteristics that are frequently present in successful applicants.

Good Communicator

Although it may not necessarily be a requirement of the job you want, it is very valuable to be a good communicator. This doesn't mean that you have to have the magic that evokes a standing ovation from an audience of thousands. It just means that you have to be able to have a meaningful conversation with your interviewers. You want to be able to express the thoughts in your head without leaving your counterpart confused about what you are trying to say. Suppose you solve the P versus NP problem... what difference does it make if you can't explain it to anyone?

It's also good to develop the ability to express your thoughts without extraneous chaff. While some explanations require a lengthy answer, being too wordy can annoy your interviewer, depending on their personality (recall that in the last post we touched on the need to assess your interviewer). This minor annoyance is innocuous, though, when compared to the risk you take of running out of time. There are many situations in which time is a critical factor and an interview is one of them. If you spend too much time explaining your answer or solution to the first question asked, you will not have time to move on to other questions. Imagine that there are two candidates interviewing for the same position and the first answers one question extremely well but runs out of time while the other answers two questions satisfactorily and one question poorly. In this case, the interviewer doesn't have a full picture of the first candidate. Maybe they would have bombed the second and third questions. With the second candidate, we have an understanding of both their strengths and their weaknesses. A known weakness is preferable to an unanswered question since many weaknesses can be overcome, but unanswered questions may hide unacceptable results.

In addition to being clear and concise, try to be precise. Misinterpretation can be dangerous in an interview. Any thinking the interviewer has to do on their own may lead to false impressions. I have a friend who interviewed at Microsoft and as part of her explanation as to why she wanted to work there, she said she loves the way Microsoft technologies like Live Messenger allow her to communicate with her family. Somehow the interviewer misinterpreted this as the desire spend the day chatting online. This mistake reflects negatively on the interviewer, but the point is to be aware that it happens. In the end, the interviewer is the one who will decide whether or not to recommend hiring you.

There is plenty of information around the web on the importance of effective communication along with some tips on doing it, so be sure to poke around and get a better understanding of both. Many colleges and public institutions, like libraries, have programs (often free) to help participants improve their communication skills. While at UCSD, I went through one such program that I believe helped me immensely.

Check out the next post in this series here.

How to Get a Job at Microsoft

I am involved in a variety of mentoring programs in which I interact with college and high school students. A frequent question that is asked is how to get an internship or full time position at Microsoft. There are many paths to landing such a job, so my preference tends to be to help potential applicants understand a few universal principals along with how to assess their unique situation, which will continually evolve over time. The things I typically talk about are (1) several characteristics that are beneficial to have (2) things my team looks for when interviewing, (3) experiences that friends and I have had, and (4) things to carefully consider when applying for a job. This post will discuss the topic of applying in general and follow-up posts will address each of the 4 items listed above.

Being smart is a basic requirement for just about every high-tech job (even though it doesn't always seem like it), so no matter how smart you think you are, always assume that there are 2 to 3 people who are smarter than you competing for the same spot. This is particularly true when the job is in a hot area of tech, at a prestigious institution, etc. This may seem like it casts a dour outlook on one's prospects for winning the job offer, but this is only true to the point at which one realizes that hiring is not based purely on intelligence. People are highly complex with a multitude of skills and characteristics. If someone is brilliant, but lacks the discipline to deliver, their value is highly diminished in most cases. Nearly every interview assesses the candidate for a variety of skills and characteristics.

Something else people often miss is that interviewers are people too. Just as job applicants are complex individuals, so too are the folks who participate in their interview loops. They eat, sleep, and poop like everybody else. They had to go through the interview process at some point in time and now they are in the position of interviewing you and having to make a decision about whether or not to recommend hiring you. Because they are individuals just like us, the exact same interview with two different interviewers may have a very different outcomes. In fact, the exact same interview with the exact same person could have very different results at different times of day! As hard as we might try to exclude emotion from objective assessments, we're just not going to be in a good mood after we dropped our laptop because we sprained an ankle chasing the bus we missed the day after our grandmother's funeral. So be ready learn how interviewers think and be ready for anything.

Uniqueness is further not just limited to people. It applies to groups of people, meaning teams, organizations within companies, and companies themselves. Think about it - in the end, each is made up of lots of individuals with unique personalities. Essentially, any organization, regardless of size, will exhibit unique characteristics that differentiate it from others. These unique characteristics are usually called culture. This is a big topic and I will definitely write more about it in the future.

So what this sums up to is that you must be able assess yourself, the job you're interviewing for, the people interviewing you, the team your are interviewing for, the company you are going to be a part of, etc. Make sure that you prepare by first gathering as much information as you can, then focusing on the right things to positively distinguish yourself from the other applicants. What makes you unique? If you are unable to distinguish yourself from other candidates, the decision will basically come down to a coin toss. You don't want to wager your career on a coin toss, right? When it comes to interviews, you have the ability to affect the odds. Study the position, study the team, study the company, and study yourself.

Check out a follow-up post on the characteristics of successful candidates.

Why blog?

As an indication of my age, I still remember when blogging first took off and everyone was openly exposing their life stories to the rest of the online world. While those stories were often relevant to readers within the authors' social circles, I always felt like the overall value was limited. Personally, I preferred to create deeper connections through in-person interaction. Because of this view, I neither followed blogs nor wrote one of my own for many years.

Over time, I have come to recognize that there are many stories out there that have helped me in many ways. I have found solutions to engineering and coding problems many times in blog posts by other engineers who dealt with the same problems. I've found clues on life and philosophy in the random musings of individuals half a world away. This abundance of information cannot be found in books. It is the seemingly trite details that these stories include that make them real and relatable. They are the difference between reading abstract theory and reading about the actual steps taken to reach the goal.

In the end, the question I have come to ask myself is no longer "why blog," but instead "why not blog?" There are several easy excuses including not having enough time, not having anything interesting to write about, etc., but the reasoning behind these excuses is lame. Anyone can take 15 minutes while waiting for the bus to jot down a few thoughts. Assuredly, there is someone out there in the estimated 7 billion people around the world (or at least the 360M with internet access) who will relate or benefit in some way from our real-life stories.

So, I embark on this journey in the hope that someone out there will find what I share useful. I know I have found your thoughts and stories to be of great value and thank all those bloggers out there who have been contributing to our collective story over the years.

In closing, here's a post from one of my favorite bloggers, Brad Feld, about why he blogs and what it has meant for him.