Over the past several years, I worked on an expanding team and interviewed many candidates for software engineering positions. What follows is my advice for those of you seeking a new software engineering job. The advice is also relevant to those of you looking to add to your team. See also Joel Spolsky’s Guerrilla Guide to Interviewing, there’s great stuff in there.
Programming is a Team Activity
I’ve been programming for multiple decades. I learned to program when I was 13 by running some programs on a minicomputer (
TUT25 on an HP 2000 if you must know); it was a very weird thing to do. Microcomputers hadn’t yet penetrated the schools (first it would be the Apple II, later the IBM PC and compatibles) and computer literacy wasn’t even yet a term that was being used in the context of education. Within a year or two, I was being paid to program. In these early stages of my career, I thought the ideal job was one where I would get my own office and I could shut the door and just cooooooooooooode! The irony is that the most enjoyable environment at the time was a big open room with everyone working on their own little thing, but collaborating with other people in the room when you got stuck. We often had group discussions about different ways of getting the computer to achieve some sort of result or discussing some detail of how the minicomputer hardware, operating system, or some particular program worked.
Modern software development is a team activity, not a solo performance. The global demand for software is so high that there is a shortage of good engineers and what companies want to build almost always takes more than one person in order to satisfy scope, schedule or both. When you look at the dynamics of a high functioning modern software engineering team, you don’t see the “cowboy coder” working alone in their office. As an engineer you will most likely be joining a team and your team will interact with other parts of the business on a regular basis. It doesn’t mean you have to be the life of the party, but if this is your first job out of college it is likely to be a very different experience from what you did while working on homework projects.
So what can you do about it if you don’t have any experience working in a team? Collaborating over the internet is one easy way to get some experience. Even better is to find someone else locally that is also passionate about programming and get together with them at a local hack night and work on something together. If you don’t have a local hack night in your area, start one! Turn your hack night into a team activity by pair programming on something together. If you and your pair want to work on different things, then divide the time up on both projects and pair program on one project for an hour, then pair program on the other project for an hour. By discussing and explaining what you’re trying to do with your pair, you’ll find you not only get better code faster, you also gain a better understanding of the problems!
You Pick the Company
A friend of mine advised that the best way to get a satisfying job is to research the companies in your area and pick your next employer instead of letting the employer pick you. Research the companies and the products they make. There is software in almost everything now and even companies whose primary business is not software may have a software development team in their organization. Go find the company that interests you and ask them for a job, even if they don’t currently advertise any job openings. Let the company know that you are interested specifically in working for them. If they say that no positions are open, thank them for their time and put them on your “call back later” list. Wait a couple of months and contact them again and let them know that you are still interested in a job with them. If they are a company that is growing, they will be creating positions over time. When they create a position that fits your skill set, they will remember you first because you are the one saying “I think you’re great and I want to work for you!” instead of just another name on a pile of resumes.
When you interview at a company, come prepared with a list of things you want to know about the company. Not just the usual things about their benefits package and so-on. Ask about the culture of the company and the development practices. Do they pair program? Do they work in isolated cubicles/offices or do they work in a shared space? Does the team sit near each other? What is it like when a release is nearing completion? How much overtime do they work? Also ask about the engineering aspects of the product. What is their code base like? How much duplication do they have? Are they obtaining metrics about their code base? How much unit testing do they do? Do they write the test first? How much automated testing in general do they apply to their products? What build system do they use? Do they measure what customers actually use in their products? How often would you meet customers? Do they attend trade shows or other events where they meet with users?
Build a Public Portfolio of Code
When you work for a company, it’s usually on their closed-source software and although you can list your accomplishments on your resume, you won’t be able to share any source code from the time at your job because that is the intellectual property of the employer. This makes it difficult for you to share your actual accomplishments with a potential employer instead of just prose summaries of those accomplishments on a resume. As an employer, I’m much more interested in seeing actual code written by an applicant instead of a prose description on the resume.
The best way to build a public portfolio is to make a significant contribution to an open source project. An employer will be able to browse not only the specific code you’ve contributed, but also browse the commit history for the project and see the way you participated in a project over time.
When you share source code with a potential employer, it is likely to be the first impression made upon the employer and the team and not your resume. If I look at someone’s resume and they provide their github URL, I ignore the rest of the resume and immediately look at their source code.
What’s that you say? Noone ever looked at your source code in school, only the executable results? How ironic! Once you get a job, all your peers are going to judge you by the quality of your source code because they’re going to be reading that source code much more often than you’re going to be writing it. I’m not talking about pretty printing it, although that can help establish a good first impression. I’m talking about designing for readability. Everyone thinks their own source code is obvious, particularly for small projects, because they know what it does. However, try reading the source code of some large, existing open source project and ask yourself how easy it is to understand that code. Then go back and look at your code that you’re about to share with a potential employer. Is your code as readable as it could be?
Short of making a significant contribution to an open source project, what else can you do? You can complete exercises on exercism.io and share a list of links to those completed exercises. An employer will be able to see your answers to a series of simple programming problems as well as feedback from the community and the iterations you went through as you revised your solutions based on feedback.
If you need something now, don’t have time to work on anything public and have recently taken programming classes where you worked on projects, consider submitting to them the source code of one of your projects. The easiest way to do this is to upload the project to github and share the URL with the employer.
Build a Portfolio of Agile Skills
As I mentioned above, modern programming is a team activity. Modern programming means being responsive to the marketplace, developing in “internet time”, and generally shortening feedback cycles throughout the software development process. That means adopting agile development practices, such as those described in Extreme Programming Explained: Embrace Change by Kent Beck. All other things being equal between two candidates, I will always take the one that knows how to unit test over one who hasn’t done it. I will always take the candidate that understands the difference between rewriting code and refactoring code. I will always take the person who is comfortable with pair programming over the one who wants to work alone.
What if the two candidates aren’t equal? I will still prefer the one with the agile development skills over the one who hasn’t done any agile development, even when the agile candidate has acceptable skills for the position, but might have less domain experience or less overall experience. Why? Because working effectively in a rapidly changing environment is what agile skills are all about. It won’t matter that the other candidate has more experience if they can’t help my team quickly adapt to changing conditions, can’t get up to speed on the code base because they refuse to pair program or requires more labor to achieve acceptable quality because they don’t unit test. Simply put, agile development practices aren’t a fad, they are a competitive advantage. Any candidate wanting to join my team puts my team at risk of losing competitive advantage when they themselves don’t bring competitive advantage to the team.
If you are a student fresh out of school, you may not have had exposure to agile development practices. However, this is a problem that is readily solved. Find a company doing agile development and ask to pair program with their team for a day in order to practice or acquire these skills — be prepared to sign a non-disclosure agreement and contribute code for free in return for gaining or improving your skills. Participate in user group meetings, code camps, or a global day of code retreat to get more practice. When you contribute to open source, practice test-driven development by writing the test before you write the functionality. Practice with exericsm.io or other coding web sites that emphasize test-driven development.
Treat Programming Problems Seriously
If the employer asks you to submit an answer to a programming problem before the interview, take that problem seriously. Even more than your resume, the code you submit to the employer in response to any problem they send you is going to the most important first impression you will make on them. Write unit tests for your code. Make sure your code compiles, executes and passes any test cases the employer has given you. Run a spell checker on your code. Pay attention to the way your code is formatted; use consistent indentation and identifier naming conventions. Don’t include any files that aren’t needed when you send them the code. If possible, send them a ZIP file of your source code repository (git, mercurial, subversion, etc.) so that they can see the commit history of your code as you worked on it. (The use of a public github repository may not be the best choice here as the employer is likely giving the same problem to many applicants and they don’t wish examples of the solved problem being readily found on the internet.) If the problem isn’t clear or you have questions, then ask the employer. If the position is asking for skills in a specific programming language, be sure to submit your solution to their programming problem in that language. Why would I be interested in a Python solution to our problem if the position is for a C++ developer?
As an interviewer, we used programming problems to weed out inferior candidates. We didn’t give them a hard problem, but the way a candidate responded to it told us more about what they would do if hired onto our team more than any amount of Q&A. When we got a solution that didn’t compile, that discounted the candidate immediately. When we got a candidate who did well on our programming problems, we always hired that person. Sometimes we saw complaints on employment feedback sites from candidates who were asked to do our programming problem. If you’re unwilling to show us your programming skills in order to obtain a programming job, what does that say about you? Frankly, we were glad we didn’t have to interview people who were turned off by the idea of doing some programming before the interview. High functioning teams want passionate developers who love programming, not time clock punchers who just want a paycheck.
Offer to Pair Program as the Interview
Pair programming for the interview is better than Q&A, both for you and for the employer. You will find out what it is like to work with members of this team by simply working with them. They will learn the same about you. Pair programming interviews can take half a day or a full day, depending on the size of the team. The larger the team, the more people you will want to pair with so that you have a chance to see what each person’s personality is like. As an applicant, you’ll have time to get over any interview jitters you might have as you get focused on coding with the team members and they’ll have a chance to see your day-to-day personality instead of your interview nervous personality. You’ll find out what kind of tools they use: IDEs, editors, programming language, naming conventions, code review practices, testing practices and so-on. You’ll get a much more accurate picture of what it is like to work with this team by pairing than you would ever get by Q&A. These are also advantages for the team that is considering you; each person that pairs with you will get a feeling of what it is like to work with you and how your development style fits in with the team’s development style.