Category: Software engineering career tips
Letter to ’12 Grads – How to Pick a Job and a Mentor
Cue ‘Pomp and Circumstance’ – hit play below to enhance the reading experience (or don’t, it’s just a song)
Dear Graduating Senior and Future Technologist,
First, congratulations on earning your degree! A degree is generally considered as a ‘nice to have’ and not a firm requirement for most programmer slots these days, and hopefully you learned quite a bit about software development in your classes. Having that parchment could be an advantage over other candidates entering the competition for technology sector jobs.
Based on conversations I’ve had with other recent graduates, it seems you have probably received some bad advice and misinformation recently from professors, career placement advisers, your peers, and even your parents regarding your new search for employment. I certainly mean no disrespect to those trying to help guide you, but it is important that you also get some input from people ‘on the front lines‘ in the field. Some academics tend to be insulated from what is really happening in the software industry, and your parents may think that a good pension plan is what you should really be after.
First I will outline how your job search (as an entry level technologist) is unique and much of the generic material that you have read re: job searches will not be applicable. Then we will analyze how to best choose your job, and what to do when you start.
GETTING YOUR FIRST JOB OFFERS
There are quite a few things to keep in mind when trying to get your first job offer(s). I assume by now you’ve read a considerable amount of information on interview techniques and resume tips. Most interview prep info is applicable across the board for all experience levels. Regarding resumes, the first thing to keep in mind is that in most cases the value of your education > job experience, so details on your school projects and classwork should be highlighted and placed prominently on your resume. I don’t recommend an ‘objective’ section for experienced candidates, but for recent grads it is a good tool for conveying your drive and desire.
Companies are going to view many resumes and conduct several interviews with entry-level candidates. Hiring managers are well aware that a significant majority of new engineers will not be immediately productive upon hire. The decision to hire an entry level candidate is essentially an investment for the firm, where said investment has little current value (low productivity) but should hopefully reap dividends in the long-term. A company’s interview process becomes due diligence to weigh the risk and reward for any individual.
Why should someone hire you?
What makes you a better investment than your classmate?
The most important attributes for entry-level engineering hires are:
- Willingness to do whatever is asked, and some things that are not explicitly asked – The tasks given to an entry level engineer will generally be the least interesting, so you will need to pay some dues. Remember Ralph Macchio waxing cars and painting fences in The Karate Kid? (Oh, class of 2012, almost forgot – did Will Smith’s kid wax cars in the remake?) For the first few months of the job, you will be Ralph Macchio – go buy a headband. Sure, Ralph got a bit lippy with Miyagi from time to time, but he finished the jobs and learned his craft. Convey in your resume and during interviews that you are a team player and willing to do what is necessary to further the goals of the company. Bonus points if you can show initiative (I recently had a candidate that was given the task of writing a small application at home as part of the interview process, and she decided to write a test suite and readme file that were not part of the assignment – brilliant!).
- Desire and ability to learn – The desire to learn will be an intangible that may be best demonstrated by any extracurricular engineering-related activities that you do. School tech clubs, user groups, hobbies, and conferences all apply to your curiosity. Ability to learn might be shown via an anecdote about a school project where you had to pick up a new tool or language with little guidance to complete the task.
- Youthful exuberance and enthusiasm – Injecting young talent into an organization can give a spark to any disillusioned engineers who may be losing passion. Someone with great positive energy (even combined with limited skills) has great value as a catalyst. In sports, these are players that may be referred to as ‘good locker room guys’. Don’t do cartwheels in your interview, but showing managers a contagious energy that people can feed off is a real benefit that you could provide immediately while learning the trade.
- Malleability – One good thing about not having any job experience is that you should be somewhat free of any bad habits. When given a choice between entry level and someone with just a bit more experience that has some potential baggage, companies will most often take the blank slate. The team will help mold you into being productive specifically within their environment and development methodology. It’s difficult to demonstrate malleability in interviews, but be willing to let it happen.
CHOOSING YOUR FIRST JOB AND WHAT TO DO WHEN YOU START
It seems that many of you were recently told how vitally important your first job is and to be extremely selective in making a choice, and I agree that your first job in the industry can be significant. However, it is probably not quite as important as you think, and based on many conversations it is not nearly as significant as you are being told. You are entering a field that is known for a high turnover rate with available statistics tending to fluctuate in the 10-25% range (often higher for first jobs), so odds are you won’t still be at this first job in a few years anyway. So let’s consider how to get the most out of the experience.
When I speak to entry-level and junior engineers and ask them about their job search criteria, I generally get similar answers to the ones I get from more experienced pros. “Interesting technologies and problem domains, challenging responsibilities, good people/culture, competitive compensation and benefits, stability…” Does knowing that the software engineering field has historically had a high turnover rate change any of your criteria?
“But my professor said I shouldn’t take a job using certain languages, my adviser said I should be paid at least $63,200 per year, and my parents told me I need to be looking for job stability.”
No, no, and no! The language is just a tool to use while learning the trade (noting that some tools/skills are more marketable than others), the money will come to you if you take the right steps in your career, and I hate to be the bearer of bad news, but there is no such thing as stability anymore. The first job search should not be about trying to get rich quick, nor should it necessarily be about finding an employer that you will be with forever. Did you plan on marrying the first guy/girl you dated? If it happens, great, but let’s not go into this first search with unrealistic expectations. What is really important about your first job?
The single most important thing you should be looking for at the start of your career is to work in an environment where people are both able and willing to teach you how to become a better engineer.
Other factors will obviously come into play, but be sure to weigh those with the above in mind. Just because a software shop pays the highest salary, uses the newest technology, has plenty of customers, offers you the most job responsibility and passes the Joel Test doesn’t make it the best place for a freshly minted engineer (but it does sound pretty tempting).
Being ‘taught‘ doesn’t mean that you should seek out companies that provide formal training sessions in air-conditioned lecture halls, as that was what college should have been. It also doesn’t mean that you will be coddled and have your hand held every step of the way. Swimming lessons are taught in the pool for a reason, and the deep end can be more useful than the shallow end for certain training purposes.
Able to teach would be characterized as a team with strong developers (preferred size is debatable but somewhat irrelevant) and communicators that have good habits and a track-record of writing quality code. Ideally the team is busy and productive enough where new engineers can learn to function in a fast-paced environment with deadlines, but not so chaotic that the company doesn’t have the luxury of letting you make the occasional mistake. Aside – You are going to make mistakes, so be prepared to accept some blame for a problem you created, learn from the mistake, and don’t compound the problem by passing the buck.
Willing to teach can be a little complicated with both personalities and time constraints being potential inhibitors. You want need to find a mentor, and strong technologists will need to have their egos stroked a bit (protip – you will find a few egos in the tech world). The search for a mentor is not a race and shouldn’t be taken lightly. Some may argue that finding the ‘right’ mentor could be as important as finding the ‘right employer.
Take a few weeks to try and figure out who the best engineers are in your team/department, and who you could learn the most from (note that the best engineer often does not equal the best mentor). Which developers are tasked to explain things to other team members and which ones conduct internal training activities? Once you have some ideas as to who the best engineers are, maybe try asking them a few test questions to see how responsive they are to helping out the newbie. Finally, choose the best fit based on all these factors and tell her/him that you are interested in being mentored. If this person likes you she/he will most often be flattered, and hopefully you now have your first guide through your early career. If this person refuses or seems hesitant, go ask your second choice. Repeat as necessary.
Once you’ve found your mentor, pay careful attention and try to figure out what makes this person such a good engineer. Note their work habits, interactions with both technical and business teams, reading materials/bookmarks, how they handle working under duress, etc. How does he/she respond to unrealistic deadlines, his/her own bugs, dissension within the ranks? Continue to ask questions and be conscious of any social cues your mentor might be sending out (i.e. learn to differentiate the ‘Not now, kid’ leer from the ‘You could just Google that question’ stare).
Now that you have a mentor, show your mentor your appreciation by both being grateful and working hard. Don’t be the last one in or the first one out, as people notice those things for new hires. Your performance will now reflect somewhat on your mentor, so even if your actual contribution is somewhat low your effort should never be in question.
Remember that as an entry-level developer you are an investment for the company, and the harder and smarter you work the more apt you are to begin paying dividends. Don’t make them regret their decision to invest in you. Chances are you won’t be at this first job for more than a few years, so absorb as much information as you can from your the opportunity and your mentor.
How Employers Measure Passion in Software Engineering Candidates (and how to express your passion in resumes and interviews)
Over the past few months I have had some exchanges with small company executives and hiring managers which have opened my eyes to what I consider a relatively new wrinkle in the software development hiring world. I have been recruiting software engineers for 14 years, and I don’t recall another time where I’ve observed this at the same level. Here are two examples.
The first incident was related to a candidate (‘A’) resume that I submitted to a local start-up. A was well-qualified for the position based on the technical specifications the client gave me, and I anticipated that at worst a phone screen for A would be automatic. I even went as far as to share A’s interview availability. A day after hitting ‘send’, I received feedback that the hiring manager was not interested in an interview. A large part of the manager’s reasoning was related to the fact that A had taken a two year sabbatical to pursue a degree in a non-technical discipline and subsequently took a job in that field for a brief stint, before returning to the software world a few years ago. I clarified information about A to be sure that the manager had full understanding of the situation, and the verdict was upheld – no interview.
My second anecdote involves another candidate (‘B’) that I presented for a position with a different client company. B was someone I would classify as a junior level candidate overall and probably ‘borderline qualified’ for the role. B had roughly the minimum amount of required experience with a few gaps, and I was not 100% confident that B would be invited in. B was brought in for an interview, performed about average on the technical portions, and shined interpersonally.
As this company does not make a habit of hiring average engineers, I was at least a bit surprised when an offer was made. I was told that a contributing factor for making the offer was that B’s ‘extracurricular activities’ were, according to my client, indicative of someone that was going to be a great engineer (though B’s current skills were average). B’s potential wasn’t being assessed as if B were an entry level engineer with a solid academic background, but rather the potential was assessed based on B’s interest in software.
There are obviously many other stories like these, and the link between them seems obvious. Software firms that are hiring engineers (smaller shops in particular) appear to be qualifying and quantifying a candidate’s passion with the same level of scrutiny that they use in trying to measure technical skills and culture fit. Historically, companies have reviewed resumes and conducted interviews to answer the question, ‘Can this candidate perform the task at hand?‘. For my purposes as a recruiter of engineers, the question can be oversimplified as ‘Can he/she code?’. It seems the trend is to follow that question with ‘Does he/she CARE about the job, the company, and the craft?’.
If you lack passion for the industry, be advised that in future job interviews you may be judged on this quality. Whether you love coding or not, reading further will give you some insight. Engineer A is a cautionary tale, while B is someone the passionate will want to emulate. Let’s start with A.
Candidate A never had a chance, and I’ll shoulder partial responsibility for that. A was rejected based solely on a resume and my accompanying notes, so theoretically A could be extremely passionate about software engineering without appearing to be so on paper. Applicants do take some potential risks by choosing to include irrelevant experience, education, or even hobbies on a resume, and I will often warn my candidates of items that could cause alarm. In this case, A’s inclusion of both job details and advanced degrees in another discipline were judged as a red flag that A might decide to again leave the software industry. A similar conclusion could have been reached if A had listed hobbies that evidenced a deep-rooted drive toward something other than engineering (say, studying for a certification in a trade).
Another related mistake on resumes is an Objective section that does not reflect the job for which you are applying. I have witnessed candidates being rejected for interviews based on an objective, and the most common example is when a candidate seeking a dev job lists ‘technical lead’ or ‘manager’ in the objective. Typical feedback might sound like this: ‘Our job is a basic development position, and if she only wants to be in a leadership slot she would not be happy with the role’. Listing the type of job that you are passionate about is essential if you are going to include an objective. I prefer that candidates avoid an objective section to avoid this specific danger, as most job seekers are open to more than one possible hiring scenario.
Since the search starts out with the resume, be sure to list all of the details about you that demonstrate your enthusiasm. This should include relevant education, professional experience, and hobbies or activities that pertain to engineering. When listing your professional experience, emphasize the elements of your job that were the most relevant to what you want to do. If you want to strictly do development, downplay the details of your sys admin or QA tasks (a mention could be helpful, just don’t dwell). When listing your academic credentials, recent grads should be sure to provide specifics on classes relevant to your job goals, and it may be in your best interest to remove degrees or advanced courses unrelated to engineering.
In my experience, the most commonly overlooked resume details that would indicate passion are:
- participation in open source projects
- membership in user groups or meetups
- conference attendance
- public-speaking appearances
- engineering-related hobbies (e.g. Arduino, personal/organizational websites you built or maintain, tech blogging)
- technical volunteer/non-profit experience
If any of the above are not on your resume, be sure to include them before your next job search.
Assuming that you get the opportunity to interview, try to gracefully and tactfully include some details from the bulleted list above. Your reading habits and technologies you self-study are best mentioned in interviews, as they may seem less appropriate as resume material.
Conclusion: Most candidates should feel free to at least mention interests that are not engineering related if the opportunity presents itself, as companies tend to like hiring employees that are not strictly one-dimensional. Just be sure not to overemphasize interests or activities that could be misinterpreted as future career goals. Passion alone won’t get you a job, but it can certainly make a difference in a manager’s decision on who to hire (candidate B) and who not to even interview (candidate A). Make sure you use your resume and interview time to show your passion.
If you found this post useful, you may find my ebook Job Tips For GEEKS: The Job Search very helpful. You can also follow Job Tips For Geeks on Facebook, Twitter, and Google +.
The Future: Polyglot Programmers
I wrote an article three years ago, “Become a Better Java Programmer – Learn Something Else“, that was subsequently picked up by JavaWorld and DZone and received moderate positive and a bit of negative feedback. The negative was primarily aimed at my assessment that “perhaps 80%” of the best local Java talent were familiar with at least one of a set of other languages I listed. Some readers felt the 80% was pulled from thin air (or pulled perhaps from somewhere else), and I concede the number was simply an estimate. And of course the “best local Java talent” line was also subjective, but time has shown I am a good judge of that.
The gist of the article was that the best Java pros that I knew at the time were either fortunate, curious or ambitious enough to learn other languages and platforms. Perhaps they wanted to improve their Java skills, to simply climb a mountain because it was there, to have a Plan B in case Java went downhill (article published June ’09, Oracle/Sun deal announced April ’09), or maybe they knew something I admittedly didn’t know regarding where things were headed.
When I wrote the article, I was offering career advice targeted to Java developers who wanted to continue to be Java developers – learn another language and you should become more effective using Java. I don’t think I had any real instincts that things were going to change dramatically over the next several years. I think the dramatic change is now happening, and it’s time to pay attention if you haven’t been.
The concept of polyglot programmers and polyglot programming isn’t new by any means, and I realize that I’m certainly not the first person or the most qualified person (I may be the tallest) to think or write about the subject. Neal Ford mentioned it over five years ago in a blog post that was quite prophetic.
Think of it this way: Years ago if you were living in Germany, chances are you only spoke German. As travel became easier and business spread to different countries, the world got smaller, and it was advantageous or even necessary to learn new languages because the chances of encountering a non-German speaker were greater. Now many Europeans speak at least a couple languages fluently out of necessity. If you are a bartender in Rome, chances are you know how to say ‘beer’ and ‘thank you’ a few ways. The software development world and the options within it have grown vastly, but the need to be productive or conversant in more than one programming language has not historically been a requirement to get ahead. I feel that has changed, and will continue to change in the years to come.
Since writing my last newsletter I had a couple interesting and vastly different conversations with two technologists that made quite an impression. One was with a very experienced (>10 years) Java programmer who admittedly had no real programming experience beyond the more common Java tools and API’s (some MVC, JSP) and invested little time trying to keep up with industry trends. She had many years with the same company and saw very little change in the tech environment. The second conversation was with a grad student finalizing a Master’s in Comp Sci who had academic, internship, and professional experience (< 2 years) with Python, Java, C++, and Ruby. He was involved in various tech communities and technology was a hobby in addition to being a chosen profession.
Right now, both of these candidates are quite employable, and as you would expect the experienced Java programmer will earn more at present. If I had to buy stock based on future earnings and career advancement in these two candidates today, I’d put all my money and mortgage my house on the grad student. This Java pro is, at this point, not even aware that the world has passed her by.
Historically, most software shops were hung up with hiring requirements that listed minimum amounts of acceptable experience with a technology. I can recall having to explain to a client a few years ago that the only person that might have had the amount of Spring experience they were seeking was Rod Johnson (true story). When I speak to my clients now, it is clear that most are more interested in aptitude over experience with specific languages or tools, as well as an understanding of certain core engineering concepts and principles (perhaps multi-threading or functional programming) in addition to a set of character traits that tend to result in productive engineers.
The metaphor I often use is to liken engineers to athletes. A great athlete can throw a football or a baseball skillfully and is able to use both a hockey stick and golf club to make solid contact with a puck or ball, once the athlete makes some simple adjustments to the chosen object. Likewise, a truly great engineer should be able to succeed using any of several languages, once they understand the syntax and basics.
With the wide variety of robust languages and platforms currently available and ready for prime time, it is hard to imagine that any one or two will become as dominant a force as Java and .Net have been over the past 10+ years. I believe the days of hearing ‘We are a Java shop’ or ‘We are a Python shop’ are behind us. The most innovative shops are mixing technologies based on using the language/platform that is the best fit for the task while also factoring in the experience level of the team members. To remain valuable and relevant, it is becoming necessary to write software in more than one language. Having the ability to produce in more than one language may be a luxury today, but it is becoming very clear that this will be a necessary skill for tomorrow’s engineer.
If you found this post useful, you may find my ebook Job Tips For GEEKS: The Job Search very helpful. You can also follow Job Tips For Geeks on Facebook, Twitter, and Google +.
