To the Programmers on Programmers’ Day,
To the childhood spent with cassette players and VIC-20s, and Saturdays loitering in the local Radio Shack for a turn on the TRS-80.
To those who maybe weren’t always the coolest kids in high school, but were often the smartest.
To the Rubyists and Lispers and Pythonistas, the architects, and the web and mobile developers who are able to show their children what mom/dad made. And to the embedded engineers who write code most people don’t even know is there.
To the thousands of Googlers, Yahoos, and Microsofties who make our email work and build tools to find anything imaginable. And to the many millions more who build things to run our homes and our lives.
To the hackers, the makers, the tinkerers, the startup junkies, the hobbyists, the open source contributors, the newbies and the grayhairs, who live in IDE’s and editors by day and often by night.
To those of you who have some of the best jobs in the world, with the highest hiring demand, yet are sometimes prone to saying that spending several minutes deleting potential job offers from your inbox can be a chore. And to those that are hustling for their next gig.
To those who solve the most complex technical problems in creative and elegant ways, yet are forced to distill their career for most people down to “I work with computers”.
Today, we salute you. Thanks for all you do.
With the deepest respect,
Job Tips For Geeks
Many new entrants to today’s technology job market are obsessed with the handful of high-profile companies that set the trends in the industry, and the next generation of software engineers seem to think that the only companies worth working for are Google, Microsoft, Apple, Facebook, Yahoo, Twitter, and Amazon. Software development has become both a celebrity culture (where companies and their CEOs are the stars) and an oligarchy in the eyes of recent graduates and teens, who set their sights on employment with this small number of firms. Young developers in foreign countries appear to be particularly susceptible to this hyperfocus on a tiny segment of the hiring market. If you don’t know how widespread this is, I’d suggest a visit to Reddit’s CS Career Questions section to see what people are asking.
When Yahoo changed their remote work policy the web exploded in debate around the value of remote employees, and the more recent news around Google dismissing GPAs, test scores and answers to Fermi questions made many tech companies reconsider their hiring procedures. Not a day passes where a piece on one of these companies doesn’t hit the front page of most major news sites. A cottage industry has erupted with authors and speakers providing guides for aspiring engineers to create résumés, land interviews and answer technical questions to get jobs specifically at these companies. The focus seems to be less about becoming skilled and more about being attractive to a specific subset of employers.
These companies are glamorized amongst budding engineers much like Ivy League and top-tier schools are with high school students, and the reason you probably won’t work for Google is the same reason you probably didn’t go to MIT. Because they are highly selective, and they simply can’t hire everyone.
Of course some of you can and perhaps will work for Google and the other companies listed here, just as some of you may have attended top universities. But the majority of
you us won’t – and that’s OK. Follow your dreams, but be realistic about the outcome.
So here comes the good news! Beyond Google, Microsoft, Apple, Facebook, Twitter, Yahoo and Amazon, there are hundreds of awesome places to work that are highly regarded by engineers the world over, and most people outside the industry (and many inside) haven’t heard of most of them. Experience with these shops, much like the above list, will get you noticed. Companies like Netflix, LinkedIn, Salesforce, eBay and GitHub are well-known but not typically mentioned in the same breath as the top celebrity firms, though they certainly could be. I’d venture that most college CS majors haven’t even heard of 37signals or Typesafe, where smaller teams are doing work that is regularly recognized by the engineering community.
And again the bad news. You probably won’t work for these companies either. For most of the world, these are still reach schools that employ relatively few. Although they may not be held by the general public in the same esteem as that list up top, they are incredibly selective, and most in the industry will view the difference between this group and the Googles as incredibly slim.
And now for some more good news. Beyond the lists of companies above are thousands of great places to work that I guarantee you have never heard of. These may consist of startups that fly under the radar or smaller specialized technology companies that serve a niche market. They could be the development groups for major banks or 25 year old mom and pop shops that have an established customer base and solid revenues. Game developers, ecommerce sites, consulting firms, robotics – the list goes on.
In almost every city, this group is the one that employs the overwhelming majority of engineers. This is where most of us will likely end up – a company that you will surely need to describe and explain to your parents and significant other.
In the city where I focus my business (Philadelphia) and run our Java Users’ Group, we have some Googlers and I’ve known engineers who have worked for Amazon, Yahoo, and Apple. And I know many many others who either turned down offers or likely could have joined those companies, but chose instead to work somewhere else. Just as some students may reject the offer from the top-rated school to stay closer to home or to accept a more attractive scholarship package, many of the world’s top engineers simply don’t work for Google or Facebook, or anywhere else in the Valley for that matter.
Philadelphia is by no means Silicon Valley, yet there is a fairly robust startup scene and a large number of software shops that are doing valuable work. Over the past 15 years I’ve worked with hundreds of Philly companies to hire engineering talent, and 99% of these places would be unknown to the typical developer. I almost always have to describe my clients to potential candidates, as most of these shops have not built a reputation yet, and these are firms ranging from 20 to perhaps 20,000 employees. And the vast majority of them are great environments for technologists where developers work alongside at least a few top engineers that could (and some that did) pass the entrance requirements for the Googles and Facebooks of the world.
All the great engineers in the world aren’t in the Valley, and they don’t all work for Google. This fact is obvious to most, but fewer than I’d expected and hoped. If that is the goal, go after it. The rest of us will be here if it doesn’t work out.
Job Tips For GEEKS: The Job Search DRM-free ebook is available for $9.99 – more info here.
Generally speaking, when you walk into an interview you are at the mercy of the interviewers. Although you may be given some general information regarding the interview format and probably have an idea about the questions or exercises you may encounter, there are endless possibilities on the topics you may be asked about over a two or three hour session.
As was stated before, any item on your résumé is fair game, so one way to potentially avoid queries on unfamiliar topics is to keep those words off your résumé. Regardless of what is or isn’t on your résumé, it is quite likely that you will be asked questions pertaining to subjects that are not within your areas of expertise. Trying to fully eliminate the exposure of certain vulnerabilities is an exercise in futility, but there is one rather effective method to at least attempt to mitigate the risks.
There is an increasing trend in the technical hiring world for employers to request firm evidence of a candidate’s abilities that go beyond what a traditional résumé includes. For programmers, this typically can be achieved through a code sample. Front-end designers and developers may be expected to show off some UI or website that they built, and architects may be asked to share documents. Mobile developers may hear this more than any other group, and are routinely asked “Do you have any apps available?” as part of the vetting process.
One way to partially control the content and direction of your interview is to provide interviewers a work sample that will presumably become a point of discussion. This will turn what could be a technical interrogation into a version of show and tell. Even if the exchange about your sample only takes fifteen minutes, that is fifteen minutes of the interview where you hopefully will shine, and it is fifteen minutes less time for the interviewers to delve into other topics that are probably less familiar.
To employ this tactic, be sure to make it known at some point early in the process that you have samples of your work for review by request. A GitHub link at the top of your résumé, a URL to download your mobile app, or a link to sites that you developed are much more graceful than large file attachments. You can choose to extend an invitation to view these projects as early as your résumé submission, and when scheduling the interview you can express your willingness to discuss the projects in more detail and offer to bring a laptop with samples.
Independently volunteering to show representations of what you have produced will give an employer the impression that you are both willing and able to demonstrate the quality of your work. That act makes the applicant appear more open and trustworthy than someone who hesitates when asked for some samples. Recruiters and hiring managers alike will welcome résumé submissions that are accompanied by additional supporting evidence of a candidate’s abilities.
When you enter the interview, you can mention that you brought samples to show if the team is interested in seeing your work. This will typically be received quite positively and could lead to a deep dive into familiar territory.
This post is an excerpt from the recently released ebook Job Tips For GEEKS: The Job Search, available to purchase from iTunes iBookstore, Amazon, Barnes and Noble, Smashwords, and (soon?) Kobobooks. A sample from the iBook in PDF format can be found here.
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.
Over the past few years my clientele shifted from a mix of mostly mid-market companies and a few startups to almost entirely startups, and that shift has resulted in a wider palette of languages requested by clients. Where my business was about 95% Java for the first 10+ years of my career, today it is closer to 25%. As I’ve written before, my business veered naturally from a pure Java focus when a considerable amount of the Java talent I have represented in years past started to migrate and show interest in diverse languages and ecosystems.
Unlike the boom periods for startups in the past, it appears that today’s startup is much less likely to choose Java as the primary development platform. Many developers who did Java work for startups in the mid 2000′s sought higher ground in the late part of the decade when small shops took a hit, and found themselves working for large companies and more corporate environments.
Flash forward to the past few years and the resurgence of startups. Many of those engineers who took shelter in the larger firms are now interested in establishing themselves once again as a major contributor on a small team in a startup, and when I have represented some of these highly qualified developers to startups now, I’ve been met with the feedback ‘The candidate’s résumé appears too enterprisey‘. As an aside, I don’t get that response nearly as often for Java engineers that stayed with small companies.
The enterprisey label, in my experience, seems to be used in two situations that can often (but not always) go hand-in-hand. First, enterprisey is often used to describe candidates that come from large development shops regardless of the languages used (although Java and .Net platforms are the norm), where the bias is that the development culture and the broader company culture make that candidate less likely to succeed in the startup. This is the result of preconceptions surrounding development methodology, possible unnecessary complexity in applications, a slower release schedule, or the impression that developers in these larger environments are sheltered from tasks related to data, devops, sysadmin, and QA that are frequently handled by developers at startups. The label may be applied liberally to virtually any candidate coming from a company larger than the hiring firm.
The second common enterprisey tag is used on any developer using Java or .Net regardless of the employer size, due to the predominant viewpoint that other language communities have developed regarding Java/.Net being wrought with and plagued by dozens of frameworks and bloated stacks. As someone who sees thousands of résumés a year, it is clear that résumés of Java and .Net developers are often significantly longer than those of developers in other languages, but there could be several factors at play there beyond just the number of potential bloat items (insert Java = verbose joke here). At a distance, the résumés of Java developers can resemble an eye chart, with acronyms outnumbering actual words. One hiring manager of a Scala shop provided this gem:
“The laundry list of legacy enterprise technologies (JMS, JMX, etc.) doesn’t do anything for me.”
The word ‘legacy’ seems particularly cruel there.
Sadly, many of those making hiring decisions in these startups are quick to dismiss a highly-skilled talent simply because of their experience working for a larger company or their primary language being in the Java or .Net worlds. Whereas an interest in, say, functional languages is now often used by startups as an indicator of ability, the prolonged use of Java or .Net at a large firm can be a detriment when applying for work in any other language or polyglot environments.
So how can engineers labeled ‘enterprisey’ escape that bias and be accepted by smaller shops with different languages?
Résumé and bio de-enterprisification – That’s not a word (yet), but the concept would be to go back and make sure your résumé/bio/LinkedIn profile/etc. doesn’t read like a corporate Buzzword Bingo card. Eliminate or modify anything that may appear steeped in bureaucratic process and procedure, and be wary of any items that can be perceived as indicative of a glacial development pace. References to project length and time between releases should typically be avoided. Emphasize new development over maintenance tasks, and accomplishments over process. Listing too many tools, frameworks, and specifications will often work against you and may be considered an indicator of your dependence upon them. Shortening the résumé is almost always the way to go here, and three + page résumés generally smell of enterpriseyness.
Develop other language credibility – Any code that you can point to that does not run the risk of being labeled enterprisey is better than nothing. As stated before, some startups perceive functional programming interest as a marker for ability, so even an implementation of a typical interview exercise in a functional language (or one different from your primary) has value. Provide links to this code on your résumé and reference any personal projects that are applicable.
Stop calling yourself ‘LANGUAGE Developer’ – I do it too (all the time), but you should not. Use whatever you feel is appropriate – Software Engineer, Programmer, Developer, Geek – but stop inserting a language when describing yourself on paper or verbally. And perhaps more importantly, stop thinking of yourself as a LANGUAGE Developer. Sometimes you may need to dumb it down so the clueless recruiter will find you, but try to minimize those instances the best you can (and do you really want that recruiter to find you anyway?).
Express your outside interests – Just because you get paid by some insurance company to write Java/.Net apps all day doesn’t mean that is who you are. If you are exploring other languages through books, conferences, and self-study, make that known in whatever way may be discovered during your job search (résumé, blog, social media, etc.). Hobbies like robotics, Raspberry Pi, and Arduino are probably unrelated to your job but not necessarily unrelated to your career. Any technical interests beyond the primary function of your job demonstrate at least some level of versatility and the ability to adapt outside of your enterprisey 9 to 5.