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.
