Future Perfect

How to get hired as a software developer

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:

Be picky.

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):

  1. Python
  2. Ruby
  3. Java
  4. Javascript
  5. Haskell

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.
  • Javascript teaches how to deal with effectively no typing, and a totally mutable 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:

Be honest.

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.”


Everyone knows the story of Gideon, how with 300 men holding torches and pitchers God overthrew a city.

What many don’t remember about Gideon is that the wayward people of Israel renamed him “Jerub-Baal”, or ”let Baal contend against him.” The victories that God won through Gideon were therefore not just victories for Israel’s sake, but were victories against Baal, demonstrating to God’s straying nation that no false god can triumph over the Lord of Hosts.

The day the nation of Israel almost became the nation of Moses

In Exodus 32, not long chronologically after the giving of the Ten Commandments, we find Moses on the top of Mount Sinai conferring with God on behalf of Israel, and Israel down in the camp melting down all their gold to construct an idol. If ever you wanted a succinct summary of the early history of Israel, this particular moment gives you a pretty good idea of how things went.

In verse 7, God calls this to Moses’s attention, and lays out a proposed solution to Moses:

And the Lord said to Moses, “Go down, for your people, whom you brought up out of the land of Egypt, have corrupted themselves. They have turned aside quickly out of the way that I commanded them. They have made for themselves a golden calf and have worshiped it and sacrificed to it and said, ‘These are your gods, O Israel, who brought you up out of the land of Egypt!’” And the Lord said to Moses, “I have seen this people, and behold, it is a stiff-necked people. Now therefore let me alone, that my wrath may burn hot against them and I may consume them, in order that I may make a great nation of you.” (Exodus 32:7-10, ESV)

This “scorched-earth policy” seems drastic, but we should remember that God, as Creator, King, and Judge, is fully within his rights to eradicate a totally-wicked generation of Israel. We should also note that by starting over with Moses’s descendants, God’s covenants to Abraham, Isaac, and Jacob would be preserved: a great nation would arise from their offspring.

The other side-effect of this plan would be to establish Moses as another “father of nations”, elevating him to equal footing with Israel’s patriarchs. For all history afterwards, the new replacement nation would speak of Moses with the same awed tones as of Abraham or Jacob. Let’s read on to see how Moses accepts this sweet gig:

But Moses implored the Lord his God and said, “O Lord, why does your wrath burn hot against your people, whom you have brought out of the land of Egypt with great power and with a mighty hand? Why should the Egyptians say, ‘With evil intent did he bring them out, to kill them in the mountains and to consume them from the face of the earth’? Turn from your burning anger and relent from this disaster against your people. Remember Abraham, Isaac, and Israel, your servants, to whom you swore by your own self, and said to them, ‘I will multiply your offspring as the stars of heaven, and all this land that I have promised I will give to your offspring, and they shall inherit it forever.’” (Exodus 32:11-13, ESV)

Moses is not concerned with becoming revered in Israel; he’s concerned with God being revered in the whole known world. He weighs the scorn that God would receive if viewed as an arbitrary divine murderer as more significant than the glory that he would himself receive if viewed as the root of a holy nation. He implores God based on God’s own covenants with the already-established Hebrew patriarchs to show mercy on an undeserving people, knowing that the surrounding idolatrous nations would not understand the grave, death-meriting offense of idolatry.

And the Lord relented from the disaster that he had spoken of bringing on his people. (Exodus 32:14, ESV)

This is significant and should be read carefully. We see that God “relented”; does this mean that he changed his mind, subduing his will to that of Moses? If so, that would make him subject to change, and less than sovereign.

Since with God “there is no variation or shadow due to change” (James 1:17, ESV), it cannot be that he has changed his mind. And since “he does according to his will among the host of heaven and among the inhabitants of the earth; and none can stay his hand or say to him, ‘What have you done?’” (Daniel 4:35, ESV), it cannot be that Moses has subdued the will of God.

Therefore, the only conclusion is that it was not God’s will to destroy Israel that day. So this episode must have been meant to test Moses and to instruct readers.

Wait, did God just tempt Moses?

It is important when we say that God is testing Moses that we not make the mistake of suggesting that God is here tempting Moses; James 1:12-13 make it clear that God does send trials, but does not tempt us to evil — by definition, God is devoid of evil.

This passage does, however, teach us two attributes of God:

He shows mercy to sinners whom he chooses.

The nation of Israel did not deserve mercy. They blatantly said “Make us gods who shall go before us”, and said of them “these are your gods…who brought you up out of the land of Egypt!” This is direct, conscious rebellion.

And yet, God shows mercy to them. He does not destroy them, even though they’ve directly defied two explicit commandments he gave them not long before. By no merit of their own, they are spared.

He hears prayer.

It is clear that God didn’t need Moses to speak up on Israel’s behalf. But when Moses did speak up, God heard him. The eternal infinite God listened to the voice of a man. That’s earth-shaking, and greater still is that we’re afforded the same privilege shown to Moses here. Matthew 6 teaches us not only how to pray, but that we can pray. We have permission to enter the throne room of God himself.

That beats human recognition. Smart pick, Moses.

Quick demo of some Java 8 features.

Java 8 is almost GA, and since I’m fortunate enough to work at a startup that values keeping libs and platform current I thought I’d take an opportunity to put rubber to road with some of the new features.

Code sample is below; suffice it to say that compared to all the cumbersome work of using Java 7 with collections, Java 8 streams, lambdas, and aggregate ops are a breath of fresh air. Particularly nice: chainable Comparator.comparing.

"Whether it was two days, or a month, or a longer time, that the cloud continued over the tabernacle, abiding there, the people of Israel remained in camp and did not set out, but when it lifted they set out. At the command of the Lord they camped, and at the command of the Lord they set out. They kept the charge of the Lord , at the command of the Lord by Moses."

Numbers 9:22-23 (ESV)

"You shall be consecrated to me. Therefore…"

In the middle of the establishment of Israel’s new national laws in Exodus 22, we find this interesting verse:

You shall be consecrated to me. Therefore you shall not eat any flesh that is torn by beasts in the field; you shall throw it to the dogs. Exodus 22:31, ESV

This is a case where we should take special note of the connecting “therefore”; the concepts presented here are causally related.

Because Israel was to be consecrated — set apart for the service of God — they were to have certain dietary restrictions (which are outlined in greater detail throughout the Pentateuch).

Much of the seemingly-arbitrary laws (and the corresponding, harsh penalties for transgressions thereof) of Israel were intended to distinguish Israel — tiny, otherwise-resourceless Israel — as a nation whose whole existence and growth was entirely reliant on God’s provision.

For this to succeed — and for messianic prophecies to hold unavoidably true — Israel must remain distinct, unassimilated from foreign nations and unentangled in political treaties (which at the time were often sealed by intermarriage, strictly forbidden in Israel).

So Israel was kept unique to be a testimony to God’s providence, grace, and might.