Lately I’ve seen quite a few requests for advice from younger programmers, asking questions either directly to me or in public forums about a career decision they are being faced with that is causing some level of stress. Reddit’s r/cscareerquestions is a hotbed for this type of activity, and you might see the occasional similar post on Hacker News. After 15 years in business, I’m quite comfortabel providing insight on the potential benefits and drawbacks of say, taking a job doing mostly Python versus a position exclusively using a rarely seen proprietary language and platform, or accepting a pure technical management position versus staying more hands-on.
Generally, I want to tell all these people the same thing. If you really enjoy the work and want to be successful in the business for a long time, you should try to make decisions, think like, and become an engineer’s engineer.
I know quite a few people I’d describe as an engineer’s engineer, and most of them have some gray hairs or are young but sound like a throwback to times past. Fortunately, some less experienced developers are benefitting from being able to work alongside someone in this category, who are more often that not open to mentoring and showing the way. As a recruiter I look at and treat these engineers like gold, as they are the types that any of my clients would want to hire – plus they tend to teach me new stuff in every conversation.
Who is the engineer’s engineer?
- Utility player – In baseball, it wasn’t uncommon in the early years for players to play several positions. Specialization has happened in baseball to the point where there are now pitchers who only pitch in the 9th inning. Similarly, software development shops are now often filled with segmented roles for build engineers, dev ops, QA, architects, performance engineers, database developers, etc. The engineer’s engineer is a utility player that can jump in almost anywhere, and doesn’t see the demarcation as a boundary that cannot be crossed. Little is considered beyond the scope, and they will not want to silo themselves into a singular function.
- Initiative – If they see something that is broken, they fix it. Will automating a task make our lives easier? If so, let’s do it, and only ask permission when absolutely necessary. This requires some level of autonomy.
- Technical integrity – By this I mean that an engineer’s engineer will have some opinions about decisions being made (if this person isn’t calling the shots) and will make that opinion known when there is disagreement. Instead of just saying an idea is bad, an alternate solution will be given. This is the desire to do things correctly over taking short cuts, which is likely to conflict with the business at times.
- Can’t be bought with money or title – This group will never take a job purely based on salary or rate, and are driven by the ability to solve interesting problems and work with a strong team. Job title means absolutely nothing. In my experience, most engineers factor money heavily in job decisions and sacrifice a better career move or additional job satisfaction for what amounts to a difference of $2.00 an hour. If you’ve chosen a job based on a 5K salary difference, this is you.
- Sharing – The engineer’s engineer wants to share, whether it be information on how and why they arrived at a particular solution, their favorite tools, or anecdotes about past projects. This is based on a combination of pride in their work and interest in teaching others. Open source is often a part of this equation, where there is a desire to share your solution for the outside world to see and use.
- No limitations – The engineer’s engineer doesn’t want to have the toolset options defined and thrives in an environment where they have autonomy over what will be on their machine. Having a company mandated IDE or OS will be a turn-off, as will any roadmap listing few acceptable tech options. Heavy bureaucracy, regulation, or barriers to being able to solve problems are an issue. The shop ideally will be engineering-friendly.
- No personality conflict, less ego – Of course, many strong programmers (and some weak ones) have quite a bit of ego about what they do. The engineer’s engineer does not come across as overly self-important, and can be more humble than those much less-skilled. This group isn’t alway the most friendly or popular person on the team, but is never the most hated.
- Movement – This group wants things to be progressively moving forward with few delays. Low latency in their process and little downtime at work.
- Has the back of team members – Solidarity among other engineers is their goal, and they tend to stay above or away from the drama of interoffice politics. They are there to solve technical problems, and have no interest in gossip or attacks on others.
- Know that they are not their code – These people can separate a technical criticism from a personal attack.
- Doesn’t need to be a leader – They are often more happy when they are not in charge, and are not instinctively driven to tell others what to do.
Note: In thinking about and doing some mid-article research for this piece, I came across Paul Graham’s 2004 piece Great Hackers which identifies some of the same traits listed here as being shared with hackers. The hackers he describes should share the workplace desires and drive as the engineer’s engineer, but may not always have the same personality or behavioral traits.
Today’s software professional is under constant pressure to maintain a high skill level with an ever-changing palette of languages and tools, and the fear of potentially becoming somewhat irrelevant can be daunting. Those that do not keep up with industry trends and movements are at some risk of losing marketability, but even those that do closely follow tech news need to make choices on which skills to pursue (time permitting), which to ignore, and what methods to use in the pursuit.
The first instinct to learn something new would naturally be to find some good resources online and perhaps acquire a couple books. You can find presentation slides and videos, articles and blog posts, and even attend live meetups or conferences in addition to your reading. Over the years I have seen hundreds of engineers (accomplished and junior) that invest an extraordinary amount of time to reading about different languages and tools, many of which they may never even get to use professionally. Some even read with the goal of some certification, which they feel will demonstrate mastery of a new skill.
I have also come to know another group of technologists who are inclined to learning in a different manner. This group starts off with some amount of reading as well, which might be limited to the product documentation and a quick tutorial, and then immediately transition into a more hands-on approach. Once they have a basic understanding of a language or tool, they actually try to build something.
As a recruiter, I have had candidates do a quick study on a new language (used by the potential employer) and throw together some common interview coding problem or even a simple app in a GitHub repo. As a Java user group leader, I have had presenters build small apps to help familiarize themselves with a framework they will be describing to others, and then demo the app live. The offer to present could be “I think X looks pretty cool. I’ve read about it but haven’t used it yet, but I’ll build something and present on my experience with X. I can be ready in a month.”
It appears that many technologists are very comfortable with the reading portion of learning, but focus there too long and never get around to creating something. This seems to be common for some college graduates, who obtain a wealth of classroom experience but very little time spent doing. Even if what you build is entirely useless to the world, your creation has value. Learning by doing is not a new concept, so the educational value is obvious. What other value is there?
Marketability and interview advantage
I was prompted to write this post about book learning when I was reviewing my recruiting placements for the past year. The developers I’ve helped into new jobs over the past year have (with few exceptions) had one thing in common – a portfolio of products and code. This was rarely the case ten or even five years go, but today it has become the norm. The Android and iOS developers I’ve placed had at least one app available for download. Web developers were able to demonstrate sites with accompanying code samples. Even the programmers who focused on back end had something to show in interviews.
The biggest example of the value of ‘learning by doing’ and a portfolio is probably exemplified by the mobile app space. It’s hard to sell yourself as a mobile developer if you don’t have any mobile app to show, and “Do you have an app?” is probably the first question mobile devs will be asked. Software developers in most other areas are usually not subject to or judged on this direct a question. Put simply, mobile developers know that in most cases having an available app makes you more marketable.
Programmers who work in more secure environments, such as those who build defense systems or financial software, often find it impossible to produce a work sample when seeking new employment. Without being able to show your past work and with no personal projects, these candidates are much more liable to be subjected to a language interrogation and the game show style of interviews that many job seekers dread. Marketability may be more tied to experience and somewhat arbitrary measurements of skill instead of demonstrable accomplishment for these candidates.
Having a portfolio gives an interviewee a distinct advantage, in that the interviewee has at least some control over the topics that will arise. Walk into an interview empty-handed and the possibilities for question topics are endless, and chances are you won’t have endless answers. If a candidate brings a work sample to an interview, it will almost certainly be included in the discussion, and one would hope that the code’s author should fare better on questions regarding that sample than on questions on random topics. Even average developers should see performance improvement in interviews when the topic is their own code.
Read enough to get going, then build something. Don’t worry about whether your something is going to change the world. Save what you build, and occasionally look back and improve upon it. Bring what you build to interviews, and practice talking about your creations.
A recent Hacker News post by a man named Andrew was voted to the front page and received over 50 comments (as of my post). The post was called Ask HN: Would you hire me?, and Andrew specified that he was talking about a junior level position.
He provided the following details about himself:
- 28 years old with a Finance Degree from a non-Ivy league school
- Spent the last two years living overseas teaching English and learning to code
He also included links to his:
- GitHub – handful of repos, 7 months as a member, pretty active over the last quarter
- Stack Overflow profile – 521 reputation, top 37% this quarter, 16 badges
- Blog – Attractive UI, 7 overall posts (a few with some code), with the highlight being details of a Chrome extension he built and demonstrates in a video
Andrew received a fair amount of positive feedback, and not one single poster gave a ‘you are not hirable‘ response. No CS degree, no professional experience, yet a highly technical audience were either mostly positive and at worst neutral on hiring (considering is more accurate) this potential applicant. Only a couple responders mentioned looking at the one project he listed, and none referenced the quality of his code samples on his blog or GitHub, so we might assume that no one even bothered to look at his code. Interesting.
Part of the explanation for the positive response is undoubtedly the makeup of the Hacker News crowd, which does not include a large contingent of HR reps from large companies who control a great deal of the hiring decisions. Place this resume and story on Monster or Dice, and I expect that Andrew would receive responses from less than a quarter of his viewers. Possibly less than a tenth.
I admit, if I were to see this candidate’s resume (assuming it reflected the details he put on HN), I would absolutely want to speak to him. The clients I represent, which are mostly startup and early stage software companies, are more representative of the HN crowd (at least in terms of evaluating engineers) than most larger companies. And even if I did not have a great opportunity for him today, I would think that a few years down the road he will be someone that I’d want to represent.
What is it about this candidate with no experience and no highly relevant education that gets our attention? Of the details we have about Andrew, how many could have impacted my decision to speak to him?
When evaluating talent and the decision whether or not to interview a candidate for a software job, I must rely on several attributes that have historically been attached to quality talent that were successful in receiving job offers from my clients.
Let’s break it down.
28 years old with a Finance Degree from a non-Ivy league school – Most readers, including myself, probably didn’t give this any thought. His degree in finance should indicate some math background, and if he had listed his specific school that would have had an impact. Although most might be reluctant to mention it, the age demographic is probably a positive based on the industry, as he obviously has some life experience and maturity but will not fall prey to any old dog/new tricks bias.
Spent the last two years living overseas teaching English and learning to code – Teaching any subject to any students is valuable experience for almost any profession, and should indicate some level of communication skills. The international aspect adds a bit more interesting background than if he were teaching domestically. Some who chose to speak to Andrew may have been strongly influenced by the oversas aspect, as this could also show some willingness to face risk and change.
GitHub, Stack Overflow, and Blog – For those that make decisions about technical talent, the fact that Andrew has both a GitHub and Stack Overflow account is probably more of an indicator of possible talent than what is actually in the accounts. Most candidates in my experience don’t have a GitHub/Bitbucket or SO account, but those who do have accounts are historically more successful with my clients than those who don’t. The attractive blog and few technical posts are yet another indicator, showing some passion as well as the ability to articulate his ideas in writing.
What other details may have led to the decision of HN readers or people like me who would at least want to speak to Andrew?
He reads Hacker News – Even if he isn’t a senior developer, he at least appears to have spent some time in one community where they frequent.
He comes across as modest and doesn’t appear to feel entitled – You don’t see anywhere in Andrew’s post a reference to how awesome he is or how he is ‘kicking CSS’s ass on a daily basis’. His responses to feedback are very positive, grateful, and polite. The choice of ‘well versed’ over some other terms that may be linked to overconfidence was wise. Andrew also will not be accused of sounding entitled to a great dev job, and on the contrary he comes across as someone who knows he has to earn it. Perhaps that is a function of his lack of a CS degree, but either way he appears to be taking the right approach.
He’s already creating product – Although he is only early on in his tech studies, Andrew has a product on the market that you can find in the Chrome Web Store that you can download. There are developers with 20 years of experience that haven’t built any of their own tools or products yet, but this guy is two years in and has that mindset. Some may question how great (or even good) a product someone at this level of experience could build, but the desire to produce and distribute a tool is something that perhaps can’t be taught.
Note: Other indicators I use regularly include:
- Past employers – Some companies frankly have a higher standard of hiring
- Technical hobbies – Arduino, build robots, or create things at home
- Speaking or writing – Presentations and publications are usually strong indicators
- Tool choice – What blogging platform or operating system you run at home
- User group and meetup – Shows interest and passion
Conclusion: Hiring managers and recruiters are making quick decisions to interview and consider candidates, and as demonstrated by this HN post it seems that there are several recognized indicators of possible talent. For job seekers, you may want to display links to your accounts prominently, and highlight details such as independent product development.
Of course, these indicators are not perfect. I, too, have a GitHub and Stack Overflow account and a blog that covers technology (and I even run one of the best Java Users’ Groups in the world) – but I don’t write code. Readers of HN should not hire me.
Discuss here or on Hacker News.
Programmers often experience a high degree of frustration during the interview process, and one primary source of annoyance is how the programmer perceives the line of questioning or exercises. In a buyer’s market where supply exceeds demand, hiring managers will often be a bit more selective in evaluating candidates, and talent evaluators may request or require more specific skill-sets than they would if the talent pool were deeper. These tactics are short-sighted but deemed necessary in a crunch.
I recently stumbled on two articles with an identical theme. “If Carpenters Were Hired Like Programmers” was written in 2004, and “What If Cars Were Rented Like We Hire Programmers” was posted very recently. The tl;dr of these posts is essentially that programmers being interviewed are asked incredibly esoteric questions or are grilled about experience with irrelevant topics (wood color for carpenters, car wiring for car renters). The comments sections on Reddit and Hacker News are a mix of agreement, criticism, and various anecdotes about interviews that reflected the articles’ theme. No analogy is perfect.
There are surely companies that are ‘doing it wrong’ and asking questions that will reveal little about a candidate’s potential as an employee, but I’m getting the sense that many candidates are starting to claim that even appropriate lines of questioning and requests are now somehow inappropriate. More importantly, it appears that candidates may not understand or appreciate the true value of certain questions or tasks.
To continue the carpenter analogy, let’s look at the types of questions or tasks that would be both useful and appropriate in evaluating either a carpenter or a programmer (or anyone that builds things) for potential employment.
- Overall experience and training – No one
willshould argue these.
- Experience specifically relevant to the project at hand – This is where we may first see some candidates crying foul, particularly if the relevancy of the experience is judged predominantly by the level of experience with very specific tools. Learning a new programming language is probably not equivalent to learning how to use a different brand of saw, but engineers can sometimes be overconfident about the amount of time required to become productive with a new technology. The relevancy of experience factors into a hiring decision most when project delivery is valued over long-term employee development.
- Answer some questions about your craft – When hiring managers ask questions, candidates should keep in mind that there can be a few reasons why a question is asked. Obviously, one objective may be to truly find out if you know the answer. However, sometimes the interviewer asks a difficult question simply to see how you may react to pressure. Another possibility is that the interviewer wants to reveal if you are the type of person who may confidently give a wrong answer to try and fool the interviewer, if you are more likely to admit what you do not know, and to evaluate your resourcefulness by how you would research a problem with an unknown answer. A genuinely, laugh-out-loud stupid question may be asked to see how well you may deal with frustration with a co-worker or an unruly customer. Lastly, the interviewer may simply want to see your method of approaching a tough question and breaking it down. Candidates that are quick to complain about being asked seemingly minute or irrelevant details often overlook the true purpose behind these exercises.
- Design something – I’m always amazed when candidates call me in a state of shock after being asked to do a whiteboard exercise in an interview, as if these types of requests were either unfair, insulting, or a ‘gotcha’ technique. Anyone who builds things should be somewhat comfortable (or at least willing) to either visually depict a past design or attempt to design a quick solution to a problem on the spot.
- Show us how you work alone – Assigning a short task for someone to complete either in an interview setting or at home before/after an interview is absolutely an appropriate request, which candidates can choose to accept or deny. It is both only an opportunity to demonstrate skills and to further express your interest in the position by being willing to invest time. Providing a bit more than the minimum requested solution is a valuable method to differentiate yourself from other candidates.
- Let’s see how you work with a team – As candidates are often hired to build things collaboratively, a short pairing exercise or a group problem-solving activity could be the best way to efficiently evaluate how well one plays with others.
- Show us some samples – Professionals who build things have the unique interviewing advantage of actually showing something physical that they have built. A carpenter bringing a piece of furniture to an interview should be no different than an engineer offering a past code sample. Companies are increasingly using past code as an evaluation tool.
- References – At some point in the process of evaluating talent, asking for references is a given. Being unwilling or unable to provide references can make someone unemployable, even if all other tasks are met.
If you go back and reread the articles about the carpenter and rental car interviews, you may have a new perspective on the reasons some questions may be asked. Think back on some interviews that you have had, and consider whether it’s possible that the interviewer had ulterior motives. It’s not always about simply knowing an answer.
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.