Tough Programmer Interview Questions: Project Management

Programmers are often surprised when a job interview shifts from technical questions to questions about project management. I just saw a great example of this in a recent Head First C# forum post:

This is a lot more common that developers realize. I’ve seen a lot of discussion lately about how to do effective programmer job searching, especially for relatively new developers who have three years of experience or less. Did you ever ace the tech part of an interview, only to find that you didn’t get the job? I bet that a lot of the time it comes down to questions that seem peripheral or less relevant – to the a junior developer.

Not to a lot of senior developers. That’s one of the biggest differences in attitude that I’ve seen between people who are new to development and people who have been doing it for a long time. And in a lot of cases, I think it really does come down to attitude. So my goal with this post is to outline the basics of project management, the core things that really matter.

Why should you care about project management?

There’s a flip side to project management, too. A colleague of mine once asked me, “What’s the most important part of project management?” I told him that it’s managing stakeholder expectations – making sure that the people who have control of the project or are affected by it are in the loop on all the important developments as the project rolls along. If bad things happen, they know about them in advance, and are prepared. The reason for this is that some projects fail (more than you think!), often for reasons that have nothing to do with the team. If you manage everyone’s expectations, get them on the team’s side, then the developers can come out as heroes fighting a lost cause. On the other hand, a project can be a roaring success, but if everyone expects something that’s not exactly what was delivered, the developers could be blamed for something that they had no control over. Expectations matter, communication matters, and these things can have a big impact on the project and the team.

And that’s why developers should care about project management: it affects your life, even when your job is to keep your nose buried in code all day.

A lot of developers have a very poor opinion of project management and project managers. I’ve spent a lot of my career writing books and giving training to help project managers improve their skills. Over the years, I’ve met many different types of project managers. And, unfortunately, while there are plenty of great ones out there, there are a lot of really bad ones as well. In any field, there is a wide range of skill level and aptitude. If you’re a developer who’s only ever worked with poor project managers, it’s not surprising if you ended up with a dim view of the project management as a whole.

But even if you’re a developer who doesn’t have a high opinion of the field, you should at least acknowledge that learning more about it can have an impact on your own career. I’ve personally seen employers pass on good developers who didn’t know enough about project management, even ones who had the technical skills to do the job.

I’ve also conducted a lot of developer interviews, easily several hundred of them over the last decade. And one thing that I’ve noticed is that really good developers have a healthy respect for exactly the same things that really good project managers care about: the work and the features needed to create the software, the team that crafts it, the effort required to build it, and the quality of the final product. That’s why I think that learning more about project management can help make you a better developer.

In the next part of this post, I’ll outline those things, and make a case for why they should matter to you. (And I’ll see if I can come up with an answer to the questions posted on the forum.)

Ever since Jenny and I wrote Head First C#, I’ve gotten a lot of e-mail and questions from developers just starting their careers. (I think it has to do with the fact that our book has become one of the most popular ways to learn how to program in C#.) But there’s a big topic that we don’t cover in the book, a topic that a lot of our readers really want to know about: how to get a better development job once you’ve finished the book and feel pretty confident with C#.

We get this question every now and then on the book’s forum. And when it comes up, I usually point people to something I posted there earlier this year. I’ve gotten a lot of good feedback from people who were happy to see that advice. But I’ve been getting more e-mails from people who want a little more information. More and more people are looking to improve their job prospects, maybe because they’ve been reading headlines about the economy. So I wanted to delve a little deeper into managing your career in software development.

First things first. It sounds a little silly to state it outright, but it’s worth repeating: the most important thing that makes a good professional programmer stand out is his programming skill. Our readers already know this, because we said it in the intro:

There’s only one way to learn to program: writing a lot of code. And that’s what you’re going to do throughout this book. Coding is a skill, and the only way to get good at it is to practice.

That’s why we included a whole lot of programming puzzles and exercises throughout the whole book – not just pen-and-paper puzzles, but actual programming problems that need to be solved by writing code. One thing that a lot of junior programmers don’t realize is that programming is about more than just coding. It’s about solving problems, sometimes really tough ones. Solving the kind of problems that you come across at work is a skill, one that improves with practice. And the only way to get practice is to find problems and solve them.

Obviously, Jenny and I think that Head First C# is a great way to get that practice. But it’s certainly not the only way. There are all sorts of projects that you can do. And if you don’t have a project that needs to be done, try thinking of one. That’s what I did back in 1994 or so, when I wanted to learn Perl and I also wanted to learn about these newfangled web servers that everyone was talking about. So I decided to give myself a project: write a simple web server in Perl. Doing lots of projects like that (sometimes for myself, sometimes for others) made me a better programmer, and doing lots of projects will make you one, too.

There’s another thing that I think really helps expand your programming horizons: learn more than one language. There are a lot of peculiarities specific to any one language. On the other hand, there are many general concepts that are common to entire classes of programming languages, or all languages in general. If you’ve only worked with one language, then it’s very hard to know what’s specific to the language you know.

So if you’re starting to feel comfortable as a C# programmer, I definitely recommend giving yourself a Java project; if you’re a Java programmer, do a little C# coding. The two languages are very similar, but you’ll learn a lot from the differences. But if you really want to push yourself and learn something valuable, move away from managed languages and try writing a little C or C++ code. Try picking up a functional language like LISP. Personally, I love assembly languages, and I’ve had a lot of fun learning about microcontrollers over the years. Simply taking a few days to learn enough about a new language to do a simple project can be a very valuable experience for a programming starting out a career. Plus, it gives you something to talk about in an interview!

Coding and problem solving aren’t the only skills a professional software developer needs. There’s another necessary skill, one that’s arguably just as important: working with a team. That’s something I’ve been thinking a lot about lately (since it’s the subject of our next book): what makes a good team, and what programming team members and leaders can do to work better and build better software. There are so many facets to working with project teams, from understanding and interacting with different personalities to finding and fixing roadblocks that keep the work from getting done. And while there are certainly some great books on project teams and teamwork, a lot of them probably won’t make all that much sense to someone who’s completely green.

This used to be a catch-22: you need experience on a software team to get a job working on one, but you can’t get a job working on a software team without experience. But there’s a solution to the problem now that wasn’t available when I was first starting out. There are plenty of open source projects looking for contributors, and even a new developer can make a valuable contribution.

Even if you just volunteer as a tester, or try your hand at fixing a few bugs, you’ll learn a lot about how people work together on software teams. In fact, you can learn a lot just by lurking in the forums and learning how the project is set up. What kind of version control system does it use? Can you figure out how to check out the code and get it to compile? Do they use a continuous integration system like CruiseControl to automatically do periodic builds? How do the team members review each others’ code?

Before you start working on an open source team, I highly recommend reading Karl Fogel’s excellent book, Producing Open Source Software. You can buy it from O’Reilly, but you can also read it for free on the book’s website. It will teach you a lot about both the mechanics and culture of open source teams. (A little disclosure: I was a technical reviewer for the book, and was really impressed with it when I read it.)

I originally meant this to be advice for people looking to start a programming career. But reading back over this, I think that veteran programmers could learn from it too. Of course, if you’re looking for a programming job, clearly there’s no substitute for actually putting years working as a professional developer. But doing these things can help push your career forward, even if you’re already partway through it.