How to Write Your First Developer Resume

I am returning from a recruiting trip to interview students on campus.  Because of this trip, I had a chance to read a good number of resumes.  Some were well done, many, however, were not.  They contained irrelevant information or were missing important items.  It’s very hard writing your resume for your first job.  You don’t have a corpus of work history that tells a potential employer that you will make a good employee.  It’s not immediately obvious what to write down and what to leave out.  What follows is advice.  It is only one person’s opinion, but I have been interviewing for jobs at Microsoft for about 14 years so it is an experienced opinion.  As with all opinions, others will have differing ones.  I encourage others to respond in the comments if they have supplementary or even contrary opinions.

It is important to understand the purpose of a resume before writing one.  If you understand what your resume will be used for, it is easier to craft the resume.  If you are applying for a technical position at a software company, your resume will serve two purposes.  First, it will be used to decide whether to interview you.  Second, it will be used to provide conversational hooks during the interview itself.

The resume will be read by someone from Human Resources or perhaps by a technical manager.  They will read it to determine if you are worth talking with further.  Each will be looking for slightly different things.  A person from HR will not understand most of the words and acronyms on your resume, but they will match them with the job requirements.  A “skills” section is often a good way to convey this information.  In it you would list the languages you know, the frameworks you understand, and the tools you have used.  While the HR person will likely only scan this list, know that anything you list here is fair game for an interviewer to ask you about later.  Don’t bluff. 

What sort of skills should you list?  Certainly list any programming languages you are comfortable with.  I have seen people rate their level of experience and find this to be a useful practice.  This allows you to list Perl which you used in one class even though you wouldn’t call yourself an expert in it.  List major frameworks that you have used.  This includes UI toolkits like WinForms, GTK, or Direct3D.  It includes Web frameworks like JQuery or ASP.Net MVC.  One rule of thumb to use here: if there are books written on the subject and you have experience, list it. 

Another important thing to list are the tools you have used.  You can list operating systems you are familiar with.  You probably won’t get benefit from listing obsolete systems.  Saying that you know Windows 98 won’t gain you points.  Mentioning a quirky, but respected OS might make you stand out.  If you used the Amiga or BeOS, saying so can be noticed.  The person reading your resume might have been a fan too.  You don’t need to list that you know Windows XP and Vista and 7.  Just say Windows.  List any major, relevant, software packages you have used.  Relevance is useful here.  Listing Microsoft Office won’t help unless you programmed for it.  It will be assumed that if you can program, you can use an office suite.  Certainly list difficult to master software like Matlab or Photoshop.  List relevant server technologies like Apache or Node.JS.  You might list the IDEs you are comfortable with.  I saw some people list the source control systems they had used.  I’m not convinced this helps.  It will be assumed that you can come to master Git or Subversion. 

The technical manager screening your resume will likely look past this list of technologies more quickly than the HR person.  He or she will be looking for your experience.  What have you done?  “Not much” you might be thinking, “I haven’t had a job in the tech industry yet.”  That may be true, but if you think you are skilled enough to land a job as a developer or test developer, you must think you have relevant skills and those skills were gained through experience.  There are three ways to expose these to your screener: classes, interesting projects, and relevant jobs.  It is fortunate that these are also the same things your interviewer will likely key off of in their perusal of your resume.

It amazes me how few students list their classes on their resume.  It helps to know if you’ve taken data structures or databases so I know what kind of knowledge you are likely to have.  These may also help you be considered for jobs you otherwise would not.  If you have taken an AI class, you are more likely to be considered for a job with a search relevancy team.

No resume of a college student or recent graduate should be lacking a list of interesting projects.  Yet probably a quarter do not have one.  Especially if this is your first technology job or internship, the projects section is the only place you can talk about what relevant experience you have.  Many if not most CS classes have a final project.  Pick several and talk about them.  List not only the name of the project but describe a) your role on it, b) what it accomplished, and c) what technologies (languages/frameworks) it used.  Don’t stop at school projects.  Even more impressive is the work that you did on your own because that demonstrates true interest.  Did you contribute to an open source project?  List it.  Did you program a game or a phone app with your buddies over Christmas?  List it.  Do you help maintain a MUD or create objects for Second Life?  List them.  Don’t be shy here.  Just because you weren’t paid or graded on your work doesn’t mean it isn’t interesting to us.

Finally, list relevant jobs.  It is important to know why you are listing jobs here.  Unlike when you are applying to be a Target Team Member, you don’t need to prove that you will show up on time and work hard.  Those things are assumed at this stage.  The fact that you have a college degree is proof enough.  That means you don’t need to list every jobs you’ve ever had.  The most important jobs to list are ones that are somewhat relevant.  This can be direct relevance like if you have an internship at Cisco testing router firmware, but it can also be tangentially relevant work like doing tech support for your dad’s small business or even running the light and sound for a school theater.  Working at Best Buy shows that you have an interest in technology.  If you have nothing relevant, feel free to list at least a few jobs even if they were burger flipping.  This will show that you have some employment history and aren’t a total slacker.

When listing a job, it is important to know why you are listing it.  If it is because of relevance, explain what you did at the job.  List the projects you were on, what your role was, and what languages/technologies you used.  Give enough information that we will know what you learned.  If you are listing the job merely to demonstrate employment, just list that you had the job and for how long.  Telling me that you “created a safe pool environment” while working at the YMCA doesn’t help your cause.  The fact that you “Provided excellent customer service” at McDonalds doesn’t make me more likely to interview you over the next guy.  The same is true of extra-curricular activities.  While you may be proud of the multicultural banquet you organized last month, it won’t gain you a lot of points.  Don’t spend much space describing it. 

These things will all make you more likely to get through the screening process.  Once you have passed the initial screen, your resume serves a secondary purpose.  Keep this in mind when writing it.  The people interviewing you—either for an initial phone screen or an in person interview—want to know what you know so they can ask you about it.  Toward this end they will ask you technical questions.  They might have you reverse a string or find the 4th element from the end of a linked list.  Perhaps just as important, though, they will want to gauge your passion and understanding.  This will be done by asking about your experience.  They will want to know about the research project you did or the Windows Phone app you wrote last summer.  For this to happen, they need to know what you have done.  Luckily, this is the same information you already provided to the technical manager.  What did you do at your jobs?  What projects have you participated in recently?

Sometimes the interviewer will want to get to know you as a person.  Listing a few activities or interests can help here.  Most of the time this section will be ignored, but if you happen to enjoy something in common with your interviewer, it can provide an opportunity to build a relationship.  Feel free to list that you enjoy sea kayaking or playing chess or that you were part of a Romeo and Juliet production at the Shakespeare festival last summer.

<soapbox>Please consider whether your objective statement actually helps you.  Most of the time, it does not and you shouldn’t have one.  I know that the helpful person at your career center told you to put one on your resume.  They are wrong.  Most of the time an objective statement boils down to “I want a job.”  Yep.  That’s why I have your resume in my hands right now.  Unless your objective statement can somehow help differentiate you from your competition, leave it off.  Everyone whose resume I have in front of me wants a job.  They even all want a software job.  Telling me that doesn’t help.  It just wastes space and makes it less likely that I’ll read something which does make you stand out.  In my experience, the objective statement provides value only when used for the purpose of *limiting* the scope of what you will consider.  If you really only want a job programming microcontrollers, put that in your objective statement.  We’ll pass you by for the kernel programming job.  If, on the other hand, you—like most people in school—just want a job in the field of computers, leave it off. 

Here is an example of the kind of objective statement that is all too common:  “Objective:  Seeking to expand my experience and technical knowledge and gain experience in a corporate environment.”  Thanks.  That differentiates you from every other resume I’ve seen.</soapbox>

Steve Jobs on the Value of Saying No

I ran across a great segment of Steve Jobs talking at the WWDC in 1997 just after he returned to Apple.  Similar to my post about pruning the decision tree, he speaks about the power of saying no to the bad ideas.  "Focusing is about saying no," he says.  His analysis of what was wrong with Apple at that time was that they had terrible engineering management.  They were doing too many things--interesting things--but had no direction.  When he took over, the decisions that had to be made were not to cut things that were bad, but to cut things that were unfocused.  A lack of focus makes the whole less than the sum of the parts.  Good focus allows the whole to become greater than the sum of the parts.

 

Two segments are worth watching.  The first is Steve Jobs explaining his philosophy:

The second is him responding to a question about why they cut OpenDoc.  The interesting observation is that OpenDoc was probably better than anything else at some things.  That, by itself, wasn't enough.  It had to be part of a larger vision or it had to go.

 

 He ends with a great observation about how you have to let the vision dictate the technology and not the other way around.

How much did Steve Jobs Mean To the Tech Industry?

 

This picture says it all.  The front page of Hacker News is completely dominated by the news of Steve's death.  Even as someone who never owned an Apple product, he had a huge influence and raised the bar.  Not just once, but at least 5 major products from him changed the state of the industry.  The Apple // was a watershed for personal computers.  The Mac for UI.  The iPod and especially iTunes for digital music.  The iPhone completely changed the phone business.  The iPad created a whole new category of devices.  His influence will be greatly missed.

Pruning the Decision Tree in Test

Yesterday I wrote about the need to reduce the number of things a project attempted to do in order to deliver a great product.  Too many seemingly good ideas can make a product late or fragmented or both.  The same is true of testing a product.  Great testing is more about deciding what not to test than deciding what to test.

There is never enough time to test everything about a product.  This isn’t just the fault of marketing which has a go-to-market date in mind.  It is a physical reality.  To thoroughly test a product requires traversing the entire state tree in each possible combination.  This is analogous to the traveling salesman problem and is thus NP-Complete.  In layman’s terms, this means that there is not enough time to test everything for any non-trivial program.

When someone first starts testing, thinking up test cases is hard.  We often ask potential hires to test something like a telephone or a pop machine.  We are looking for creativity.  Can they think up a lot of interesting test cases?  After some time in the field, however, most people are able to think up a lot more tests than they have time to carry out.  The question then becomes no longer one of inclusion, but one of exclusion.

In Netflix’s case the exclusion was for focus.  This is not the right exclusion criteria for testing.  It is improper to not test the UI so that you can test the backing database.  Instead, the criteria by which tests should be excluded is more complex.  There is no single criteria or set of criteria that work for every project.  Here are some to consider which have wide applicability:

• Breadth of coverage – Often times it is best to try everything a little rather than some things very deep and others not at all.  Don’t get caught up testing just one part.
• Scenario coverage – Look for test cases which will intersect the primary use patterns of the users.  If no one is likely to try to put a square inside a circle inside a square, finding a but in it is not highly valuable.
• Risk analysis – What areas of the product would be most problematic if they went wrong?  Losing user data is almost always really bad.  Drawing a line one pixel off often is not.  If you have to choose, prefer focusing more on the data than the drawing.  Another important area for many projects are legal or regulatory requirements.  If you have these, make sure to test for them.  It doesn’t matter how well your product works if the customer is not allowed to buy it.
• Cost of servicing – If forced to choose, spend more time on the portions that will be more difficult or costly to service if a bug shows up in the field.  For instance, in a client-server architecture, it is usually easier to service the server because it is in one spot, under your control, rather than trying to go to hundreds or thousands of computers to update the client software.
• Testing cost – While not a good criteria to use by itself, if a test is too expensive to carry out or to automate, perhaps it should be skipped in favor of writing many more tests that are much cheaper. 
• Incremental gains – How much does this test case add to existing coverage?  It is better to try something wholly new than another slight variation on an existing case.  Thinking in terms of code coverage may help here.  It is usually better to write a case which tests 10 new blocks than one which tests 15 already covered blocked and 2 new ones.  It is very possible that two test cases are both great, but the combination is not.  Choose one.

There are many more criteria that could be used.  The important point is to have criteria and to make intentional decisions.  A test planning approach that merely says, “What are the ways we can test this product?” is insufficient.  It will generate too many test cases, some of which will never be carried out due to time or cost.  It is important to prune the decision tree up front so that the most important cases are done and the least important ones are left behind.  Do this up front, in the test spec, not on the fly as resources dwindle.

Pruning the Decision Tree

A great post by Marc Randolph got me thinking.  He tackles the question of why Netflix made the moves they made recently.  Specifically, why did they spin off their DVD option as a company called Qwixter?  The answer: focus.

What separates successful ventures from failures is choosing to do the right things.  What separates great successes from merely good ones is choosing not to do the wrong things.

When faced with a question about whether to add a feature, the decision often revolves around whether customers will like it.  This is a good first question, but stopping there leads to sub-optimal results.  It is important to ask the next question:  What can we not do by doing this?  Resources are limited.  For each feature that goes into a product, something else(quality, time, other features) comes out.  If that is forgotten, the product will end up with too many features that are good but not great and a product that feels the same.

Shipping a great product then is about the decisions about what features not to implement and what bugs not to fix.  Netflix demonstrates what it looks like to take this very seriously.  They are jettisoning what is a popular part of their company so they can focus on what they think is the future.  Only time will tell if they chose the right strategy, but one has to commend them for making a clear choice.  

Follow my adventures at //build/

This week I'm attending the //build/ conference where Microsoft is revealing many of the details about Windows 8.  If you want to see what is going on, follow my Twitter feed at https://twitter.com/steverowe,  I'm posting some pictures, linking to summaries, etc.

Listening to the team

There is an old saying in software that goes something like this, “Scope, Timeframe, and Budget: Pick two.”  Being a tester, I would rephrase this a little as, “Features, Timeframe, Budget, and Quality; Pick three”.  It’s usually possible to hit all three of the first choice as long as you are willing to sacrifice quality.  We’ve all seen products that do this.  They have such potential, but just don’t work.  Over the past year, there were lot of planning efforts going on around me and this was a great chance to observe different behaviors.  One pattern I have seen a few times is worth discussing.  That is managers trying to dictate all 4 aspects of a project.  There are two ways this tends to happen: the dictatorial manager and the persuasive manager.

Before we jump in, it is important to define the four levers.  Features represent the complexity of the product—how many things it can accomplish.  Timeframe is how soon the product needs to ship.  Budget is how much can be spent on the project.  For software projects, this corresponds largely with the number and skill of people that can be put on the task.  No discussion of budget can be complete without at least mentioning Brooks’ law.  Quality is the ineffable attribute representing beauty, greatness, or merely suitability for a given task.  In practical terms it means how many bugs are exposed by the product.  Increasing the expectations for any of these increases the pressure on the project.  Within reason, each can be relaxed to achieve the desired levels of the other three.  It is important that managers understand that when they ask to increase features, they are trading off time or that when they ask to reduce time, they are trading off features.

The dictatorial manager is the more obvious of the two.  This is the person that just says, “You will have the following specs done by this date.”  Implied is that this will be done with a fixed number of people (never enough) and of high quality.  This is the pointy haired boss from Dilbert.  When the team raises objections, this manager is unphased.  They stick to their position.  If the team can’t get it done in the timeframe they ask for, they will find someone else who will.  It never occurs to the manager that perhaps what they are asking for is impossible.  The only good news is that this type of manager is often self-correcting.  They are not enjoyable to work for.  The best members of the team have mobility and will leave.  This slowly guts the team of the most capable people and the project slowly fails.  At a quality company this manager will be seen for who he is and removed from such responsibility.

The persuasive manager is less obvious but nearly as bad.  This is the manager who convinces their team that it can do the impossible.  In this case they don’t dictate an impossible situation, they merely get the team to agree to it.  This manager is usually a really nice guy who just can’t say no.  Instead they ask people nicely to sign up for everything marketing and upper management ask for.  Their team likes working for them, it just can’t figure out why it is so over-worked.  The quality of the project suffers as the team goes into an over-worked haze.  This sort of manager is not as quickly self-correcting.  The team does not leave except through burn-out.  They don’t blame the manager because signing up for the work was their idea.  Neither the dictatorial manager nor the persuasive manager will succeed.  Both will usually ship something close to on time because they cannot admit failure.  The quality, however, will be low.  People stop caring once they are made to attempt the impossible.  The team will be much weaker the next go-round because all of the good members leave through disgust or attrition.

A better model is to listen to the team.  Most times a manager does not have control of all of the levers.  Typically timeframe and budget comes down from on high.  A manager cannot magically hire more people.  Except through brinksmanship, they cannot cause the project to ship later.  They do, however, have control over the expect level of quality and the number of features.  A team will usually give signals if they think they are being asked to do too much.  The wise manager listens to this and adjusts plans accordingly.  This is the genius of systems like Scrum and Agile development.  A tenet of these systems is listening to the team.  Using a system of cost estimates and burndown tracking helps bring an objective view of the picture.  Likewise, if the team hesitates or balks at signing up for work, a good manager will re-evaluate.  This doesn’t mean automatically reducing the ask, but it does mean making sure you are convinced it can be done. 

If a manager senses that the workload is too much, it is their responsibility to reduce it.  As much of a manager’s job should be spent deciding what not to do as deciding what to do.  This may generate heat from upper management who wants everything in a limited time, with a fixed budget, and at the highest quality.  Helping upper management understand the situation and even taking the pain if understanding is not conveyed is the responsibility of the manager.  If failure is inevitable, it is better to fail in a place of your choosing (that with the least impact/priority) rather than risk failure on a broader scale at a later date.