At my employer, I’ve helped out with some developer job interviews (for positions of varying experience), and as is more often than not the case in the hiring/job-hunting process, many of those interviews have found that either the candidate or the company is not the best fit for the other.
It can be a bummer when you interview for a job and get turned down. But trust me, it’s a bummer to spend time talking to somebody and then have to turn them down, too.
So it’s in everyone’s interest, I think, to put together a developer’s guide to getting a good job.
I should say that I speak entirely for myself here — opinions expressed do not necessarily reflect those of my employer, etc. And while most of this advice is intended for junior developers looking for their first development job, there may be some kernels valuable for developers of varying experience.
So, without further ado:
Pickiness may sound like a bad thing when you’re trying to get hired, but the best way to get a good job is to get a good job. Remember that interview processes are two-way evaluations: you’re interviewing the company as much as they’re interviewing you.
It may help to put together a list of your priorities in a job. An interview experience — even the best interview experience — rarely gives a full impression of what it’s like to really work somewhere, so it helps to know what to look for and ask about. This may also help guide you should you be forced to make the worst kind of choice: a choice between two really good options.
Note that this advice is highly market-sensitive. At time of writing, an average software developer can typically get a job within about 2 weeks — there’s more demand right now than supply.
Get to know people (and leave a good impression)
Having someone “on the inside” who can vouch for you is invaluable. If a company hired Joe Schmoe, it’s probably because they found him to be the kind of person they want to hire. If Joe Schmoe then recommends someone else, that carries more weight than a totally unknown quantity, because the company already knows that Joe’s values align (to some degree) with theirs.
It’s super-important to note that this can work against you if you’ve made a bad impression on that “inside man” in the past. Hence the old adage “don’t burn your bridges behind you” — a bad impression in the past can prevent you from moving forward in the future. When you meet someone you’d want to work with, be the kind of person you’d want to work with.
Admittedly, if you’re anything like me, “networking” sounds like horrible disingenuous schmoozing. But it doesn’t have to be. All you have to do is make friends along your work and/or school career. Really! Actual friendships are better than self-interested social connections anyways.
Make yourself visible.
Step one, before most companies hire a developer, is to do some kind of screening. Typically this is a phone interview, but it’s not uncommon for a quick google/facebook/linkedin/github search to be part of the quick-screen.
So it’s a good idea to show well in these places. If you’ve got some personal projects (and you should — more on this in the next point), throw ‘em on github. Anything with a live demo? Link to it! Use twitter or a blog to mull over and discuss the ways you build software, and don’t be afraid to throw out there any quick notes on tools and techniques you’re learning.
Make sure your online identity is connected, too. It’s a pain to track down John Q. Public across the internet and hope that it’s the same guy on github as on linkedin as on facebook as on $otherPopularSite. Worst-case-scenario, your potential employer confuses you for someone at a drastically different skill level from you.
Build stuff. A lot of stuff.
If you’re an online merchant or an auto mechanic or really almost any kind of consumer-facing professional, you live and die on customer reviews. Software development is not a review-oriented profession, so the best indicator of the quality of your work is your work itself.
This is especially helpful if you tend towards significant interview anxiety (everyone has some degree of interview anxiety). A good employer will take that into consideration, but it helps if they have some way to assess how you actually write software when not under pressure.
Don’t worry if the stuff you build isn’t groundbreaking; it doesn’t have to be. It should, however, demonstrate that:
- You care about “best practices” (yes, I know it’s a personal project. It only helps you to write good unit tests anyways).
- You enjoy programming. (As an aside: if you don’t enjoy programming, you won’t enjoy programming for work.)
- You are constantly learning. Stretch yourself — don’t just write a hundred bash scripts or “hello world” apps in the same language/language-family.
EDIT: I should note (based on feedback from incredulitor and Duraz0rz) that this doesn’t mean your life is programming, or that you’re worthless if you don’t code outside of work. More than 9+ hours a day is a long time to spend programming, and doesn’t leave room for proper life balance — especially if you’re in a phase of life where other obligations consume much of your non-work time.
If you’re a fresh college grad looking to land your first programming job — go wild! Now’s the best time to build things, since you may not have much previous career work to show to employers, and you likely have more free time now than you for most of your life.
If you’re someone with more experience and more demands on your time, pace these projects appropriately. An hour or two a week beats no time at all, and it beats 12 hours a day.
Your personal projects are primarily for your own benefit — if someone else uses them, that can be exciting — but they should be conducted in a way that is most healthy to their biggest stakeholder: you.
Don’t be afraid to try seemingly-esoteric tools.
While you may not learn a lot from writing LOLCODE, picking up COBOL may teach you a few things about how to build things with limited tools.
I tell people who ask (both of them so far) that the top languages I recommend new developers learn are (in order):
Each language has different lessons to teach developers:
- Python is a good intro to development with its friendly English-like syntax. It also introduces some good data structures, like tuples, lists, and dictionaries.
- Ruby pulls in some better object-oriented concepts while giving a first taste of lambdas and closures.
- Java teaches the value of strong typing, and how to work with a compiled language.
- Haskell teaches how to think about problems from a functional perspective, the importance of reasoning about code, the concept of Algebraic Data Types, and other useful concepts (like the Maybe monad).
My point here is not to prescribe a set learning order, but to emphasize the importance of building as big a toolset for solving problems as you can. Try some of everything. Constantly push just outside of your comfort zone — it’s usually rewarding.
The great part about publishing personal projects is that it gives you a low-risk, high-visibility playground for trying new things. When I see a github account with projects in several different paradigms and languages, I see a developer who can think more abstractly about software.
Don’t tie yourself to being a “java developer” or a “ruby developer” forever. Specific tech comes and go with circumstances; the ability to solve problems and think abstractly is always valuable.
Learn problem-solving skills, not just one solution.
I’ve heard it said that programming is 90% reading code, 5% writing tests, and 5% writing code. This is almost accurate; programming is really more like 50% solving abstract problems, 40% reading code, 5% writing tests, and 5% writing code.
This is where sites like Project Euler, HackerRank, and Code Wars try to help (with varying degrees of success): giving problems hard enough or abstract enough that they force programmers away from the keyboard and over to a whiteboard or paper to sketch out the problem and try some solutions before writing code.
As a professional software developer, most of your problems will not come from professors looking to test your ability to write toy programs using the tools they taught you during a semester. The problems you’ll be facing will usually come from people who don’t know what a web browser is, but who want a way take a picture of a printed-out work schedule and have it correctly imported into their online calendar (or some other similarly-hard problem).
Prep for your interview
Interviews are a lot like tests were in school: they’re high-stress evaluations of your skills in a time-constrained session. So just like tests, you should prepare in advance for them. Do some research on classic interview questions (“why did you leave your last job?” “what is your biggest weakness?”) and be ready to answer them honestly (but eloquently and tactfully).
Unlike tests, however, interviews also evaluate a more personality-driven variable: “culture fit.” Half of this is about matching your personality to the company’s “personality”; if you’re a laid-back, free-spirited person, you probably aren’t the kind of employee a suits-and-ties company is looking for. (You probably wouldn’t enjoy working there, either.)
The other half is about evaluating your character and personality as a person. Most people would turn down an smart candidate who’s prickly, overbearing, and rude — any new hire is a person whom existing employees will deal with 5 days a week.
So, with that in mind:
If you don’t know something, admit it. Don’t “fake it ‘til you make it”, because you won’t really “make it.” If you manage to trick the potential employer into believing you know more than you do, you’ll win yourself a job for which you’re not qualified — making your life more stressful and your new coworkers’ lives harder.
Be willing to hear and learn from negative feedback.
Critique can be a harsh teacher, but only because it’s an honest one. If company X didn’t hire you because you’re “too green,” try to find out what sort of skills they needed that you didn’t have — then learn those skills. That way you go into the next interview all the more prepared.
Don’t be too negative about former employers.
If a company asks you why you left a previous job, they’re really asking (from their perspective) how little it will take for you to bail on them. If they feel like you’re someone who leaves as soon as you don’t get your way, they almost certainly aren’t gonna hire you. Everyone makes mistakes; no company should give one person their way all the time.
Beyond simple common sense, you never know who knows whom. I once interviewed for a position at “company X” (names changed to prevent the innocent) only to learn in the interview that the owner of company X was a personal friend of a bad previous boss from comparatively long ago in my career. The bad experience I had working for that former boss was old enough to be barely relevant to the job at hand, but to company X’s owner that bad boss was seen as a valuable reference. As a result, the interview started off on a decidedly negative tone, and I had a hill to climb to prove the negative “pre-impression” wrong.
(This story ties both into leaving good impressions and into being picky: the company chose eventually not to make me an offer based on that “ghost of bad boss past”, and I chose immediately to look for other options based on the stark similarity of personality between the two employers.)
Don’t be a jerk.
It sounds hard, but even the nicest person can benefit from taking a second to consider the other people in the room. As a former coworker once told me: “they’re not out to get you; they’re just people.”