Last night, I gave a talk at Towson University to a section of software engineering students (a friend of mine is their professor). The goal of the talk was to share advice and experiences that would help them in their careers. What follows is the notes I spoke from, with revised and extended remarks (indicated by [extra]).
Overview
- Intro/bio
- Internship(s)
- Interviews(s)
- Work
- Beyond Work
- Keep in touch
- Keep learning
- Keep your skills sharp
Internships
Imagine being paid to test drive a car for 12 weeks. That’s what an internship is—the only opportunity you may have in your working life to take a job and a company for a 12-week test drive. You’ll get to see if you like the day-to-day of your particular role. You’ll get to see if you like your boss, your co-workers, the culture of the organization. When you are choosing your first real job, they can be a very useful filtering mechanism to determine which companies you should consider seriously and which ones you should skip. If an internship works out really well, that company could give you your first full-time job.
If at all possible, don’t graduate without one. A successful internship puts you ahead of recent college graduates without one because you have proof that you can do real work.
Internships are also a great opportunity to begin to build networks beyond your classmates. Even if you’re a natural introvert, make an effort to be social. You never know when a friendship might result in a reference, an interview, or a job—for you, or a friend you make.
I was an intern at The Washington Post the summer before I graduated from Maryland. Halfway through the summer, they asked if I could return in the fall as a part-time employee and I accepted. At the end of the year, the Post made an full-time offer for a help desk position. I got better offers and took one of those instead, but I have no doubt it would have been much harder without that internship and part-time experience.
[extra] I said during the talk that all other factors being equal, the candidate with an internship wins over the candidate without one. To be more complete, I should have said that a candidate with a lower GPA and an internship can and does beat a candidate with a higher GPA and no internship. My undergraduate GPA was just shy of 3.0. But because I had a successful internship, 4 months of part-time work experience at the same company, and a great reference from my boss, I had multiple offers before graduation.
Interviews
When it comes to interviews, expect to be asked about anything and everything on your resume. So if you can’t back it up in an interview, don’t put it on your resume. I interview people for jobs on a regular basis, and always ask questions to find out if they really know all the things their resume claims. If you have an internship under your belt, you’ll have real work experience to put on that resume.
Also expect to write code on the spot for a problem you’ll have had no advance notice of. If you’re not asked to write it on a whiteboard, the interviewer may just put a laptop in front of you with an editor and wait for you to write it. In interview situations like these, it’s very important that you verbalize what you’re thinking as you develop your solution to the problem. If you stare at the whiteboard or the laptop for a long time without saying anything, the interviewer might think you’re stumped—even if that isn’t the case. If you aren’t sure about some aspect of the question, it’s better to ask for clarification and be sure than to assume and be wrong. I ask a simple LINQ problem in every interview—and nine times out of ten, the candidate gives the wrong answer because they assumed they knew what I was asking for instead of making sure.
[extra] The following is a version of the LINQ question I ask in interviews:
Given the following:
var listOfNumbers = new List<int>{3,6,9,12,15,18,21,24,27,30,33,36};
write the LINQ statement that returns every number in the list divisible by 12 and by 6.
Work
Software engineering involves a lot of collaboration. In my role, in order to develop a single feature or piece of functionality, there could be a handful of other people involved:
- business analyst
- other developers
- project manager
- program manager
- tester
In addition to being able to write software well, it’s just as important—if not more so—to be able to communicate clearly and effectively and listen actively. As a software engineer, that means:
- Regularly updating your teammates and bosses on your progress
- Asking for help if you’re stuck
- Informing business analysts about missing, incomplete or unclear requirements
- Informing project managers if you’re going to miss a deadline
- Writing estimates of how long a task will take
I do all of things in my job, in addition to helping other developers on the team, designing and implementing software, and testing.
We’d all love to work on brand-new software, but most of us won’t get the chance. It is highly likely that the first work you do will be maintenance of and/or enhancements to an existing system. So developing an ability to find bugs in software (whether you originally wrote it or not) will be important to your success as a software engineer.
Beyond Work
Keep in touch, keep learning, keep your skills sharp (and add new ones). That’s a basic summary of the steps you need to take to go further in your career as a software engineer.
It is impossible to overestimate the importance of networking to your career (and I don’t just mean having a huge number of Facebook friends, Twitter followers, or LinkedIn connections). By networking I mean staying in regular touch with people you’ve worked with in the past or know from school that you’ve enjoyed working with (and would like to work with again). If you’re in the same geographical area, catch up with them in person once a year if you can manage it. If you don’t live in the same area, go beyond a word or two on Facebook. Don’t be the guy or girl who only checks in when they need something.
Having a strong one will not only bring you a wealth of useful advice and support when you need it, it will help you find work too. A couple of examples from my own experience:
a. I worked with a guy named Dave at USWeb. We worked together for a couple years before I left and the company folded. We kept in touch off and on over the years, but hadn’t had regular contact in awhile. Over 12 years after we actually worked together, he gets in touch because he’s looking for a job and trying to decide between two companies—the one where I currently work, and one I worked for previously. I tell him my current company is better (not just trying to be a good company man, my former employer was terribly dysfunctional) and write up a referral for him. He gets hired and over a year later he’s still having a great time.
b. Two other guys I worked with at USWeb—Murali and Allen. One was director of technology, the other a senior developer. I kept in fairly regular touch with Allen. So after almost four years at Ciena, I’m looking for a change. Murali, our former boss, is program manager at a local consulting firm and wants to surround himself with good people from previous gigs. He contacts Allen first, but Allen likes where he is and isn’t looking to make a change. But Allen gives Murali my contact information. I interview, I get hired, I work there a couple of years before moving on to a management role at a different company.
Don’t pass up opportunities to expand your networks beyond classmates and people you’ve worked with in the past. This area has plenty of software user groups. They’ll have stand-alone website or be on meet up.com. Join one. Get to know people that regularly attend. One of my current co-workers is someone I first met at a .NET user group in Rockville (RockNUG). A year-and-a-half later, when he got tired of commuting from Maryland to Virginia to work, we talked after a user group meeting about openings at my company. He’s been there six months now and is doing great work for us.
Figure out how you learn best. Some of us learn best through reading. Some through lecture. Some through examples. Figure out which one of these you are and spend regular time outside of work learning however works best for you.
Conferences and user groups provide great opportunities to network and learn. Smart companies use them to raise their profile and to recruit new talent. The companies I consider the best ones in my career are the ones that sent at least some of their employees to a conference or training every year. Even when I haven’t worked for companies that pay for employees to get training, I believe it’s important enough that I’ve paid my own way on more than one occasion for a particular conference. I went to SXSW Interactive last year and met up with former co-workers I hadn’t seen in 10 years. I met people from all over the world, as well as a few people who were literally across the parking lot from me. Seriously! I met a couple of programmers and a designer who work at a small firm in a building less than 100 yards away, but we had to fly over 1500 miles to meet.
Blogs, podcasts and screen-casts provide great learning opportunities as well. However you commute between home, school and work, it’s time you could spend listening to one of the many podcasts available on technologies or software development.
Starting a blog is a great way to practice and improve your written communication. I first started back in 2003, and my only purpose was to have a way to remember the process I went through to solve particular problems that I could access from wherever I wanted. On occasion, I would get a comment or two from others on the web that helped me solve a problem I’d posted about or improved on a solution I’d come up with. Sometimes a post has been useful to other developers than myself. I’ve even gotten requests for help in the comments. Once you have a blog, it also makes a handy place to publish a linkable copy of your resume. That’s a piece of advice your professor gave me many years ago, and now I have plenty of visibility to companies (and recruiters) without really having to bother with job boards.
Giving a talk is a great way to practice and improve your verbal communication. User groups are always looking for people to come and speak, and if there’s a technology that you know well (or want to know well), having to give a talk about it in front of an audience is one way to give yourself an incentive to research it and learn it well enough to be able to answer questions about it. I try to give a few talks every year to one of the user groups I attend in Rockville.
[extra] Starting a podcast is another option you might consider. I listen regularly to a few podcasts by veteran software developers (Hanselminutes, .NET Rocks, etc) and learn a lot that way. But I think we would also benefit from hearing software engineers who are relatively new to the work world, or even from interns. In addition to creating opportunities to hone both your writing and speaking skills, you’ll get to learn about audio and production.
With the amount of time you’ll spend working (and otherwise living your life), one of the habits that I’ve personally found the most difficult to maintain is writing code regularly that isn’t specifically for my job. One of the benefits of school, especially in a computer science program, is courses where you have to learn multiple programming languages and produce working solutions in a relatively short period of time. The diversity of languages is a great way to force yourself to think differently about how to solve a particular problem. To the extent you make it a habit to learn a different programming language every year or two, the better your skills in your main programming language will become.
Music, martial arts, sports and medicine are endeavors that have practice built into them. Software engineering doesn’t. We usually treat our work as our practice. You will improve more quickly as a developer if you practice designing and building software separately from the work you do everyday.
Practice! There are plenty of sites out there with different code katas (small problems that you write code to solve). Larger, longer-term side projects are also a great idea—especially if they’re tied to a hobby or something else that interests you outside of your job. In addition to these, the web is full of open source projects that could use contributors (github, codeplex, sourceforge, etc). Try to contribute however you can—even if it’s documentation—and you’ll benefit from the experience.
[extra] When it comes to practice in improving your software engineering skills, it works best if you consistently increase the level of difficulty. John Sonmez explains why here. He also links to an incredible example by Jennifer Dewalt. Programming contests (including things like TopCoder) may be worth your consideration.