Surviving a Career Fair

Introduction

I didn't have time this week to put together a regular post because of my weekend recruiting trip, so I thought I'd instead provide some tips for those of you in school trying to do well at career fairs. Granted, my tips are aimed more towards CS majors, but some of them are definitely applicable to all fields of study. I thought about these on the way back from 5 hours of non-stop career fair pre-screening, and the folks that I gave my highest recommendation to for getting interview slots based on my conversations with them all had these things going for them. This is by no means an exhaustive list, but it's the best I could come up with on short notice.

Hygiene

I have to admit that I'm a little surprised that this had to be included on the list. Please make sure you shower before going to a career fair. If it's hot outside where you are then plan out your transportation appropriately so that you're not all sweaty by the time you get to the fair. Also, brush your teeth! If I can see yellow gunk between your teeth, guess what I'm looking at? I didn't deduct points from folks for these things because I didn't think it was fair to, but the point is that you're trying to sell yourself and presentation is everything. It's harder to hold a conversation with someone who smells terrible - there's really no getting around that. I know almost for a fact that there are companies out there that won't be so forgiving if you have terrible hygiene, so get cleaned up and at least come business casual.

Shake the Representative's Hand!

A firm handshake is a pretty standard thing. It's a matter of politeness and tact. When you've been standing for hours and talking to folks nonstop, it really sucks when someone just walks up to you and sticks a resume in your face. That's a pretty bad first impression and given that you only have a few minutes to wow the representative, you don't have much time to make up for it. You want the entire experience to average out positive, and no greeting starts you out in the negative.

Eye Contact

This generally wasn't a problem for me, but there was one guy who I seriously thought was blind. To be perfectly honest, I spent a good 20 seconds trying to figure out if he was blind. It doesn't count against you if you're blind, but it does count against you if you're trying that hard to not look me in the eye. My end conclusion is that they guy was looking at the ground. Aside from showing a huge lack of confidence (you don't want to be self-deprecating here, it's basically an interview situation), it's really awkward. It felt like talking to a wall. Being a software developer involves a lot of communication, how can I endorse someone who's not comfortable talking with people? I'll come back to communication though.



Refine Those Resumes

My biggest pet peeve was seeing resumes that were clearly not properly prepared. It's really as easy as going to your school's career services and having someone go through your resume with you. I only have 3-5 minutes to talk to you, and I don't want to spend a minute reading an essay about your life while you stand there awkwardly. A resume is a concise summary of your professional career and what you're looking for, so don't give me every little detail. Highlight the key points and let me ask you questions about what I care about. Since different companies sometimes look for different things it doesn't make sense to try to explain everything in detail and hope for the best. The things I focused on the most were:

• Previous Degrees


• Graduation Date (do you want an internship, full-time position, etc.?)


• Skills (programming languages, familiar technologies, etc.)


• Relevant Coursework (more important for underclassmen)


• Technical Work Experience (people seemed to not like to mention what languages or technologies they used, or their role in the projects, and instead used a lot of ridiculous acronyms)


• Technical Independent Projects (which ones were done outside of the classroom and what technologies/languages did you use?)


• GPA (this was low on my list, but could help more than hurt people)


• Objective (not always necessary, but was important for folks where I didn't understand what role they were looking for at Amazon and it can't hurt to have it there on the safe side)

Another thing: don't print on the back of your resume because then I can't take notes on it. I know several companies take notes on the backs of resumes, and the less space you give me to take notes the less likely I'll be able to recommend you for an interview spot since I can't read my tiny notes in the margin. If you have to have more than one page (consult with your career services first) then use multiple sheets of paper and staple them.

Keep Your Resume Professionally

I expect for people to have swag bags and probably backpacks, but don't keep other junk in your hands and don't keep your resumes in your swag bag. For one thing, it took those people like 30 seconds to reach in their corporate swag bag for their resume, and it's just tacky. I literally paid $15 for a leather zipper case that I kept my resumes in back in the day and it worked great. Some people kept crumpled papers in their hand, which was also strange. Feel free to use your hands to help you speak, but don't use them to fidget with crumpled papers.

Offer to Summarize Yourself

Some people don't like this, but I do. When you hand your resume to someone, if they don't ask you to give a brief summary of yourself and what you're looking for, then ask them if they'd like you to. It can't hurt. Don't launch into the story of your life unprovoked, but I liked having the guidance as I read someone's resume of what they found most important. It was less awkward than the person just watching me read their overly long resume (in the cases where the resume wasn't well-prepared, I mean). It can backfire if you go into each thing in grave detail though because it's going to give me less time to talk to you and formulate a positive opinion of you (more on this below).

Talk Concisely

Please do not ramble. Please! If you ramble when you're nervous then go through some mock interviews with your career services. Even though it's not a full-blown interview it still is a very small one. Be concise in your answers and feel free to politely ask if you properly answered their question or if they'd like to hear more, but don't offer more information than was asked for. Aside from being irritating, it means that the representative has less time to ask you for the information they really care about, which gives them less evidence to build the case they'd have to make on your behalf to get you an interview. Also, if there's a line behind you then that's even worse because it's impolite to those people and is going to encourage the representative to cut your time short prematurely because they want to keep the line moving since they're not going to get to ask you what they need to ask you in under 5 minutes.

Be Confident

This is a pretty tricky one. You want to be confident, but never arrogant. There were a few people that were kind of unsure on my questions that were, in my opinion, intentionally pretty softball and they used the words "I think". It's one thing if I'm grilling you in an interview with a trick question and you're trying to think out loud about a solution. If I'm asking you to define something like a hash table though, you should really know the answer. I don't want someone to say "I don't know" because I don't want them to give up though, I'd rather see them persist and ask for hints. You don't want to confidently give an answer you really don't think is right, but you also don't want to give a sloppy answer. If you need guidance then just talk it out with the representative and let them guide you. I didn't ask a single difficult question that I didn't preface with "this is kind of hard so it's ok if you get it wrong", and I only asked them to folks that I was already impressed with. Odds are that the person at the booth isn't trying to grill you, they're just trying to figure out if you stand out among the rest.

Be Articulate

I want to say that just having the talent is enough, but it's not quite all of it. You have to be able to communicate, plain and simple. Communication is key to software development at pretty much every good company. If you're being asked a softball question, it's probably to see if you can elegantly talk about something very simple that you ought to be very comfortable with. If you can't talk about something simple, how can you help brainstorm solutions to critical operational problems with your team? You don't have to be a toastmaster (though participating in your local chapter would almost certainly help you with this), you just have to be able to articulate technical and non-technical answers in an easily understandable way. The easier it is for me to understand what you're getting at and the more efficient our time together is, the better my overall impression of you will be and the more time I'll have to take notes about how great your answers were.

Bring Questions

Bring good questions about what you're interested in working on or even questions about the general process. Don't ask stupid questions about the company that you know they can't answer. For example, a recruiter can't comment on a rumor or a recent scandal, so don't ask about it. That can actually leave a bad taste in the mouth of the recruiter and hurt their overall impressions of you. Feel free to ask questions about their experience at the company or what they do or why they still work there, just don't ask anything irrelevant to your potential future at the company.

Warm Up and Don't Get Discouraged

It's a good idea to start out by visiting a few companies you're not all that interested in just to whet your whistle and shake off any anxiety you may have. Then move on to the places at the top of your list. You don't want to launch into your top choice cold turkey.

Also, don't get discouraged too easily. If you don't get the company interested you want one semester, just try again the following one. Don't let one bad experience with one person get you down. Most companies won't blacklist you because one person didn't like you in some career fair. They'll usually give you another chance if you give them another chance.

Conclusion

It all boils down to this: you're at a career to sell a brand. That brand is you. Any good tech company is looking for a solid, well-rounded individual. Not someone who is a guru in one thing and nothing else, but someone who is smart, has the aptitude to learn very quickly, and can communicate effectively. Of course, some core technical knowledge is required, but past that any good tech company is looking to see if you can grow into an exceptional, rock star developer. That drives their long-term growth. No good company wants a code monkey, and no reasonable company expects you to already be a seasoned professional out of college, but they're looking for something intangible that's very hard to detect so you need to make it as easy as possible for them to find that in you.

My tips aren't a sure fire way to get you an interview in the aftermath of a career fair, but they definitely go a long way. You still have to put in the effort inside and outside the classroom to build up your talent, of course.

What I Wish I Learned in College

Introduction

Before I get started on this, I don't want to mislead you into thinking that I didn't like the University of Texas (UT) or that I didn't feel like I got a good education in UT CS. I've already established, in fact, that I loved my time at UT. I use a lot of the stuff I learned in school all the time (though some of my non-major courses, like Electricity and Magnetism, have been less useful). However, there are some things that I don't think any American university (possibly not even universities around the world) teach you that are invaluable in the real world. I've only been working full time for a little over a year, but there are 3 key lessons that I didn't learn until I got into the real world though they're invaluable skills. Aside from what you do learn in school, I feel like you can't excel as a software developer without these things at any good company (if you're at a company that doesn't value these things, you're probably at the wrong place). You don't learn them in school because they're hard to teach, but if you can learn these things before you get out there then you have a leg up on the competition. To give you a brief overview: after I talk about those things I'll give some honorable mentions to other useful talents and then I'll go over the things I'm really glad I did learn.



Lesson #1: Working Well in a Team

Even though I was part of the executive body of a student organization, did peer programming for multiple courses, and worked two internships, I didn't really have a good understanding of dealing with team dynamics. While every team has its own way of doing things, there are general ideas that are applicable to all teams. It's important to ask questions when you can't find the answer to something in a reasonable amount of time, but it's also important to be polite and non-obtrusive is asking for help. Doing code reviews is a delicate balance of being constructive in your criticism because you're reviewing something that a team mate likely worked very hard on. You have to learn to trust your team mates' decisions and their work, or else maybe you're on the wrong team (if you're at a good company though, it's more likely that you're just being paranoid).

What I'm really getting at is that a one-man team isn't going to go nearly as far as a team of competent engineers. As great as rockstar programmers are, they're not going to be able to get as much done as a team of great engineers. Aside from the bandwidth of a single person being less than a team, a rockstar programmer can always improve himself by feeding off the talents of others (it's a good relationship though because everyone else learns from him). Your success as an individual hinges on your ability to work well with your team. It's amazing how much you can improve the design of something by walking to the right teammate's desk and having the right conversation with them (i.e. talking to him in an optimal way). Tackling a big problem alone is inefficient and is not likely to lead to the best solution in most cases. We once had a major operational issue where I felt like we hit a brick wall, but then a team mate came in with one great idea to help, and that inspired another out of me, and we kept brainstorming to a point where we turned a seemingly impossible situation into one with a path to resolution.

Part of working well on a team is not getting too big for your britches. Sometimes, you have to do work you don't enjoy. The way I've learned it is, if you're spending at least 80% of your time doing what you enjoy doing, then you're sitting pretty. Getting to 100% is practically impossible though. Tasks shouldn't be seen as only for a higher seniority person or a lower seniority person, and you should be willing do whatever needs to get done to facilitate your team's goals for that sprint/month/year/whatever. You should also trust that everyone else on your team is humble and share useful information proactively rather than waiting them to come to you for help.

Of course, a team is only as strong as its weakest link. If you have one person who's too lazy to find answers before asking teammates or who just writes terrible code then the team will never work as well as it could without him. You have to be able to recognize the warnigns signs of a weak link and either try to remedy what's causing him to bring the team down (or even just yourself if he only affects you), or talk to your manager about whether this person is the right fit for your team.

I've only scratched the surface here of what it means to be a good team player. Some of these things seem conceptually obvious, but they're not that easy in practice and require, well, practice. The closest I've seen to a class in school teaching these skills is a Software Engineering course at UT where you and a team of people create a product from start to finish and then present to investors at the end of the semester. The bottom line is that you cannot be successful if you aren't willing to learn how to work well with a team and take advice from peers and mentors and managers on how to improve in that capacity, as well.

Lesson #2: How to Effectively Communicate

Working well in a team and effectively communicating definitely aren't mutually exclusive talents, but effective communication goes far behind just dealing with your team. Being a truly great engineer is more than just hacking away behind a keyboard, it's being a role model and a respected leader. How many great, respected leaders do you know who aren't also very good at communicating (in writing and in speaking)? Steve Jobs isn't CEO of Apple for his good looks.

In any software company there are always customers. Understanding how to deal with cusomers is paramount. I know what you're probably thinking, isn't that a manger's job? Yes and no. Managers tend to distill customer concerns and feedback so that developers can focus on getting products done, but they can't handle every little customer communication. When you have operational issues at 2AM, you can't wake up your manager to figure how to speak to your customers about it. When a customer stops you in the hallway to ask you a question, you can't just shrug your shoulders and point to your manager's office. Dealing with customers is a delicate balance. You want to tell them exactly what they need and want to know, and nothing more (or less). You want to use the right words because, especially in written communications, you don't want something lost in translation (in connotation and just technical terminology). I could go on and on, but the point is that you're not going to move forward in your career if your customers don't like you. Granted, there are likely to be a few who don't, but the rest really should or else maybe you're not doing your job.

Another area where communication is important is in design discussions. Getting your point across with peers with no tools other than your brain and a whiteboard is absolutely critical to your day-to-day. This also includes being a good listener and taking other people's points into consideration. People like being heard and hate being talked over.

Then there are technical talks. Being a rockstar engineer means that you're good at sharing your knowledge with others. If all you do is absorb knowledge and stow it away then you're not of much use to a company because you immediately become a single point of failure and a flesh covered encyclopedia. Sharing with others helps prevent co-workers from re-inventing the wheel, which makes your company more efficient, which saves money, which drives better software development.

You have to give presentations in school and write some papers, but the workplace has become inundated with communication via e-mail, meetings, teleconferences, instant messaging, and whiteboard gatherings. Each type of communication follows slightly different rules, and college only scratches the surface of any of them. An e-mail you send to your professor is not nearly the same as an e-mail you send to your director. Still, there is no ettiquette taught in school. Writing a short story or an essay is not the same as writing readable documentation for your software. This is something that's really hard to learn in the classroom, and really requires experience via internships and co-ops. Another useful place to start out is joining your local Toastmasters chapter.

Lesson #3: Proper Unit and Functional Testing

Last, but not least, quality assurance (QA) is the bedrock of any good software development shop. Being a QA engineer may not seem as sexy as being a software developer, but it's just as important (if not more so). Beautiful software that doesn't work, or only works some of the time and explodes at others, is pretty useless. If someone was trying to sell you an iPod Nano and told you that it usually worked great but had good odds of literally exploding without warning, would you honestly want it?



Of course, QA is really everyone's job on a team. A QA engineer can only do so much. You have to write good unit tests and functional tests so that your code passes some nominal bar of what you expect it to do. If you just write your code and don't run it, how do you know if it worked? Even more important: how will someone else know it works if you don't have unit tests proving your intentions for the code? And probably even more importantly, how will someone who modifies your code a year later know if they broke some key functionality in a module of 500 lines of code if there are no unit tests to verify its core functionality? Unit tests are designed to test each part of a module in as small of units as it can be broken into and functional tests are intended to test an entire module. QA engineers are then typically resonsible for integration tests (testing that your module works well with the rest of the system), but it helps if you understand the integration testing, as well. Another fringe benefit of testing, as a whole, is that it forces you to take another look at your code before you push it out for code review and is likely to help you catch a lot of careless bugs.

When I graduated, I conceptually understood unit testing, but had little experience with it and not really a full understanding of functional or integration testing. Granted, my degree was in computer science and not software engineering, but it wouldn't have hurt to have learned more about proper unit testing technique. My most rigorous edification on unit testing was in Operating Systems where our teacher had some tests for our project (a File System) based loosely on the requirement he had given us and we were responsible for writing our own unit tests to match the ones he wrote that we weren't allowed to see. I thought this was really unfair (especially since I failed the project), but he thought it was perfectly reasonable. He said that in the real world you'll get ambiguous problems and have to still come up with a good solution. This is true, except for that in the real world you also do iteration to account for hidden requirements and you don't get fired (what I consider the equivalent of an F) because you missed one of these hidden requirements. Also, you have a whole QA process and a team of engineers working with you to ensure that you don't make any false assumptions and miss something important, as opposed to a classmate who may or may not be very helpful to you (mine happened to be awesome, by the way). The point is that he took the wrong approach, in my opinion. He had the right intentions, but poor execution.

The right thing to do is to first teach students how to unit test. Until I came to Amazon, I didn't know about things like TestNG, EasyMock, and JMock that are very important to writing unit tests for many cases that I tend to run across. I don't feel like universities, as a whole, emphasize testing enough. There should be some instruction on technique rather than throwing students to the wolves and letting them hope for the best. To expect students to write good software for big projects without showing them the tools necessary for testing (or pointing them, at least, to the documentation for them) is like expecting someone to write a program in Java who's never programmed before in their life.

I also had never heard of Test Driven Development (TDD) before I came to Amazon. Granted, that's not as important as unit and functional testing, it would've been nice to know. There should be a required course in CS curriculum around just general Software Engineering like advanced use of debuggers, profilers, TDD, unit testing, etc. I cannot stress enough how valuable good testing is to the long-term success of a developer.

Honorable Mentions

There are some other things that I also wish I learned in college, but some of them were available in school I just didn't have the time for them while others simply aren't absolutely critical to success for everyone but can be very important.

• I took an optional course on Linux in school, which was a very good choice, but it was very basic. I wish I had exposure to more advanced Linux concepts before I got in the industry, like NFS and rpm and advanced Linux commands. Linux is definitely the best OS for developing software, in my opinion. Macs are good, too, but mainly because of having that command line. However, most Linux distributions are most stable than OS X, which is crucial to development.


• I definitely didn't have to write as many scripts in college as I wish I had to. Knowing a couple of good scripting languages can save you countless hours of time in automating something without writing a bunch of code in a heavy-weight language like C or Java. When it comes to doing something quick and dirty for an operational issue, the poor performance of many scripting languages isn't as critical as being able to write something quickly that just works. I'm trying to invest time in learning Python or sed, but so far I've been limping along with my limited knowledge of Bash and Perl, which is still somewhat intimdating to me. We had courses on Perl, Python, and Ruby, but I just never had free hours for them.


• Being in a top CS program definitely makes you feel smarter than it should. If you've been in such a program and don't agree, then you're in denial. Let's face it, at one time or another, a CS student at a good school, whether or not he makes good grades, feels smarter than other people. Given that it has a unique vernacular compared to other majors, that already makes CS majors sound smarter, but making good grades boosts their ego even more. The cold hard truth is that you're not special when you come out of school, you have to earn it. This isn't to say that you won't get respect, but you'll lose it very fast if you don't humble yourself. There will always be someone smarter than you, and so you have to be able to take constructive critcism and realize that there's always more that you can learn if you're willing to.


• There are no grades in the real world. You can't easily measure your success. You have performance evaluations every year, most likely, and that's about it. This drove me crazy for a while because I didn't know how well i was doing. I had to learn to glean this from one-on-ones with my manager and feedback in code reviews and such. There are a lot of measures of success in the real world and none of them come with an easily attainable letter or a number. It's all about what you want to get out of your career and what your job demands of you.


• Simply shipping a product isn't all that matters. Aside from the cliched saying that the journey is more important than the destination, it's important to realize that getting the right results is key. You can't rush something out just to meet a deadline, because that's a short term gain for a long term loss. You have to be willing to make the right choices now so that you don't have to apply band-aids later. You need to also ship the right software based on what your customers want, not what you think is cool.

What I'm Glad I Learned

Of course, there are some things that I'm really glad I learned in school - things that I can't do my job without. There's no question that I wouldn't be half the developer I am today without my college degree. These are the things that I use all the time:

• It's really mind-boggling how often I come back to concepts I learned in Operating Systems. Aside from just multi-threading there's technical stuff you learn that's absolutely invaluable in debugging really hard problems, like memory management. If you don't know how a file system works, for example, how will you figure out that you've run out of disk space because you're out of available inodes? How will you figure out why your jobs are running slow if you don't know what swap memory is and why it could be getting filled up?


• Computer Architecture was another shocker. The concepts of the stack and pipelining alone are key ideas (the latter of which is fundamental for discussing performance in large systems), but knowing in great detail how a computer works helps you understand what kind of metrics to monitor in your systems so that you know when you're in trouble before you're in trouble. You can't drive to root cause without understanding what they really mean either.


• It almost goes without saying that courses in data structures and algorithms are the fundamentals of programming. Having a cursory knowledge of the building blocks is a pre-requisite to writing good code. Even past that, there's also the importance of learning design patterns and using them in brainstorming during design discussions.


• I have to admit that my 4 semesters of theory definitely have paid off. Automata theory alone is a goldmine when it comes to understanding at least regular expressions and context free languages. This is not to mention somewhat formally proving something in your head before you convince your boss that something is true. Of course, you'll need to distill your proof into English, but all the same I often use techniques I learned in automata theory as building blocks for my arguments.


• Obviously, learning programming languages themselves were important. I don't think that really requires explanation.


• I think that all CS programs should mandate a course in network security and privacy. How can you write safe software if you don't understand how it can be attacked? How can you figure out why your website is down due to a Denial of Service attack if you don't know what one is? How can you write a threat model for your software if you've never written a buffer overflow exploit? Aside from the obvious benefits, you also get a much deeper appreciation for the memory stack in a security course.


• Learning how to pair programming was a more than welcome skill as it's definitely necessary sometimes at work and was a good stepping stone for understanding how to work in a team even if it wasn't the full picture.


• A big part of any CS program is having to debug your software, and I don't see how anyone can be a developer without these critical thinking skills. They've served me well and are growing constantly. Without the foundation I got in college though in learning GDB and how to use the Eclipse debugger and marathon sessions at 4AM trying to squash bugs I don't know where I'd be today. Debugging is a huge part of my job in development and operational support.


• I took a course in management that I'm really glad I took because it taught me some great concepts regarding leadership and helps me understand stuff that my manager and her manager and her manager's manager do/say.

Conclusion

There's a lot of things a CS program and a good University can and will teach you that are very important in the real world, but there are some things you just can't learn in the classroom. I hope I've inspired some people to think about what they can do to learn the skills they might not get in school and set goals in internships and co-ops to focus in on these things. When it comes down to it, these are the skills that separates awesome developers from good developers. If you really want to succeed, there's no way around them.