08 May 2012

Want to get a job after college?


The question I aim to help answer is this: how do I get the skills I need to get an entry-level job that already requires the skills I need?


I have noticed recently from several of my in-town colleagues in the software business that there seems to be a shortage of qualified, interested people seeking open positions. The key word here being “qualified”, with “interested” not being far behind. There is no shortage of applicants, but it seems like well more than half are so unqualified that they are job-seeking for the sake of job-seeking, yet not actually looking for a place to work in return for a paycheck. I know in the minds of many people there is an apparent unsolvable problem where you cannot find a job because you do not have the skills, but cannot get those skills because you can only learn them while on that sort of job. My aim here is to explain what skills those are and how you might go about acquiring them without having true, full-time, paid job experience. Please note that these comments are my own opinion and not those of guidance counselors, hiring managers, or others that are far more in-the-know than I am.


Even before addressing skills, however, there is something to be said about the non-technical parts. Number one is to do a little research. Find out something about the organization you are joining. What sorts of projects do they do? Who are the managers and team leaders, and what are their areas of expertise or research? What is the working environment like? Do people wear jeans and shorts to work or neckties? Seeking an entry-level position, you are not going to get away with looking unkempt, wearing flip-flops and jeans, and still get that contested entry-level position.


Number two is to be enthusiastic. An employer is going to invest in you. They don’t want to hire someone to see them leave after a year or two. Organizations often take six months to a year to really bring someone up-to-speed to start working independently, and until then it’s a loss of productivity in another developer or two. If you don’t care about the work you are doing, you are less likely to want to do it well. Employers can see that when you talk to them, and are more likely to hire someone that wants to be there than someone that does not, despite slightly less experience. Not wanting to be where you are and not caring if you produce quality output is a quick way to kill motivation in a programming team. Prove to your future employer that you will be a benefit.


Now on to the technical skills. The main point to remember is that when starting out, familiarity can be much more helpful than expertise, and broad familiarity even more so than specific expertise. Especially for a new hire, you are likely not to have much exposure to the useful and important day-to-day tools of a professional development team, but your learning curve will be much easier if you expose yourself to some of what you may see. Every shop is a little different, but most have the same basic pieces in place. Get to know some etiquette and get familiar with the types of tools you will be using. My point here is that each organization has their own practices and tools, and you will need to learn how they do things. It is helpful to ask questions and contribute, but don’t expect to have their policies become your policies as a new employee. You will need to learn their way of working, and the faster you do the more productive you will be and the team that got stuck with you as a time sink will like you and respect you more and treat you as an asset sooner.


Your number one technical skill to build is using a development environment. Many Java developers use Eclipse, perhaps even most developers do. Some use it for everything, fully embracing the integrated nature of the environment, and some use external tools out of preference. Developers for other languages use other environments, such as Microsoft Visual Studio. Some use a system-default text editor and command-line. You don’t need to know about all IDEs, or even be an expert at one. What you must do is know what they are capable of and what benefits they provide. Learn how to navigate around code, outlines, and project explorers; searching all files for a function name by string is a thing of the past. Get used to using shortcut keys. Learn some of the paradigms of the popular IDEs, such as where to find menus and toolbars, whether most things are done via shortcut key or context menu, where to find help documentation, and where to tap in to the user community.


Number two on technical skills is a source code management system. Git is becoming increasingly popular in the open source world due to the workflows it can handle. Subversion is still quite popular. CVS is still used in many environments and being phased out in others. Learn the benefits of source code management and versioning. Learn how to check out, check in, properly annotate a commit message, branch and merge, deal with other developers on the same few files. Learn about patch files. Learn the pros and cons of the most popular systems, and look up why groups are migrating from one to another. Learn some of the ways these systems integrate with IDEs. Learn about the various workflows that are commonly used, such as tiered approaches or having a single central repository.


Number three on technical skills is issue tracking. Bugzilla has been around a while and most commercial and open source developers have at least heard of it. Trac is another popular option that also brings in connections to a repository, code browsing, and Wiki. Again, don’t try to learn them all, or even the names of all the ones out there. Find out what some popular ones are, look at the features they offer, look at how organizations use them, and get some practice. Some open source projects use Bugzilla for a discussion forum as well as defect investigations and enhancement requests. Others strictly use their forums for discussion and then open a ticket when they have good reason to believe it is a new issue. Learn some of the ways organizations use this kind of tool.


For number four I will group the rest of the tools that may be useful. These start to branch out wildly depending on the industry you are in, but the key here is to not be taken completely unaware that something exists. Some examples in no particular order: ANT, word processing, spreadsheets, database systems and SQL, XML, JSON, image editing (e.g. Gimp, Photoshop), email and instant messaging, Skype, javascript, python, differences among web browser engines. Also try to be familiar with some of the pros and cons of operating systems for different needs. Linux, Windows, Mac OS, various smartphone systems, tablets, and how they are tuned for servers, gaming, software development, portability, battery life, photo and video editing, customization, malware control, etc.


Now how do you go about learning all of this useful stuff? If you are at a college or university, find or start a student organization or club. I recommend a game developers organization, which brings together designers, programmers, artists, and musicians. If you are not at a college or want another path, jump on an open source project that interests you. Look on SourceForge, Google Code, github, or see if any software you use is open source and how you might be able to help. Get into a situation where you are working with other developers on a project. Practice using a source code repository and issue tracking system. Practice working with other people on a common task, collaborating and sometimes conflicting. Learn how to resolve conflict. Dive into a project being managed and learn something about project management, deadlines, bug assignment, and just teamwork in general using the tools of the trade to coordinate and communicate.

No comments:

Post a Comment