Happy Bear Software

How to get a job as a full-stack web developer

In 2008 I moved to the UK after two years of teaching English in Japan. I was newly married with no job and little of my own money. While teaching English and in university I had done some freelance web development work, I didn't feel confident that I could sell my programming skills on a fulltime basis. I was going to have a crack at being a web developer anyway, and this is how I did it.

The first thing I did was put together a CV, google for 'junior web developer UK' and apply blindly to whatever came up. I had to apply to two or three companies before I got to interview with one, let's call them Alpha.

My interview with Alpha was at a coffee shop in their office building on the other side of London (a daily commute of an hour and a half each way). It was largely non-technical. Since I had no full-time experience, they were concerned about my ability to put together a content-managed website. They wanted proof that I could actually deliver on a CMS soon after the interview.

I decided that I would build a content-managed site that night and send a URL over to them by start of business the next day. I went home and hacked together an extremely simple, mostly broken CRUD application with my limited knowledge of PHP/MySQL. My tools at the time were a Windows laptop, crimson editor and a shared hosting account with fasthosts, with no version control. This was an extremely painful experience.

After a night spent for the most part fixing SQL syntax errors, I sent over a URL to a working application before 10am the next day. Later that week I received an offer for a perment full-time role for a salary of £21,000 per annum (roughly $34,000 USD). At the time I knew this wasn't a great salary.

Let p be the probability that if I apply to a job I will get an offer. At this stage in my career, I didn't have enough data to make a confident estimate of p. I didn't know that it wouldn't take a hundred more applications to secure another offer. Worse still, I didn't know how many openings there were for junior developers. For those reasons, I accepted.

While working at Alpha, I spent a lot of time improving my skills. I taught myself about [HTTP][http-rfc], managing complexity and version control. I invested in touch-typing, learned how to use vim to an intermediate level and received a harsh introduction to the world of web application security.

Above all, I wrote a lot of (bad) code that I had to maintain and extend myself. While the salary may have been bad, I took away a lot from my experience at Alpha and have no regrets.

Becoming an accidental "Senior" Developer

I left Alpha after a year for another company that were offering a higher salary. I did freelance work to supplement my income at the same time and moved between companies, but my salary stayed in the £20k-£30k ($34k-$48k) range.

Around a year and a half after leaving Alpha, I was interviewing for permanent positions and had two offers in hand. Both were at £38k ($61k) which felt like a ludicrously high salary for me at the time. I was quite sure I would accept one of them but a recruiter had set up an interview for me at a company (let's call them Bravo) which I attended all the same.

Through some happy accident, the recruiter had submitted me for a position as a "senior" developer. At this stage I had roughly two years of experience developing web professionally, and would never have had the confidence to apply as a senior developer on my own.

What followed was the most gruelling technical interview I've ever participated in.

To start with I was grilled on every skill listed on my CV. In each instance I was questioned until I had to say "I don't know, but I'd search the documentation/rfc/google for x to find out". I was given mock scenarios for high-scalability web applications, asked to "explain polymorphism without reference to animals or shapes1" and had to talk through a code review with developers from the team, spotting badly chosen algorithms, subtle errors and bad coding style with as much politeness as I could muster.

(1: I used vehicles, which is a metaphor that bears a lot more fruit for explaining polymorphism. It allowed me to handily transition into topics like composition over inheritance which in turn lead to other technical debates that programmers like having.)

I went home with no idea as to how well I did. I normally do well at interview, but had never done one that had been so hard. At the very least I usually come away knowing how well a fit I am with the organization. In this case I wouldn't have been surprised if I got the offer on the day or was rejected out of hand.

I was invited back for a second interview in a few days where I was to give a presentation on a technical topic of my choosing (out of a list of possible options). I went with hash tables as I remembered a thing or two about them from university and could piece together the rest from wikipedia.

I made it clear that the presentation would very much be a condensed version of the wikipedia article before starting, and then spoke for around ten minutes on the topic. After the presentation I was again grilled, this time on favourable properties of hashing functions, common problems, possible solutions etc. I had done my research and was prepared for the initial barrage, but it wasn't long before my knowledge on the subject ran dry.

I again went home, this time quite sure that I wouldn't get the offer from Bravo. I didn't have enough experience to be a "senior" developer and I felt my knowledge bottomed out in the interview far too often.

Around a week later, the recruiter got back to me to let me know that Bravo wanted to bring me on as a senior developer for £44,000 per annum ($70k), more than double the salary I started on as a web developer only two years ago.

On finding out, my wifes only reaction was to say "そこまで欲張りしなくてもいいと思う" (literally "I don't think we should be so greedy" in English). It was such a huge jump for me that I felt like there was some catch, some downside that I had missed because I didn't quite deserve this level of compensation just yet.

I accepted the offer. Working at Bravo was by far the hardest and most educational technical job I've yet to experience. Among other things, we had:

My job had been to have my assumptions questioned, hard, by people who were a lot smarter than me. After that, not only was I capable of having strong technical opinions, I was able to articulate them clearly. Though I may not have been a senior developer when I started the job, I at least felt a lot more confident in my abilities by the end of my time there.

Finding your first few web developer jobs

Over the course of my career I've applied to more openings, attended more interviews and turned down more offers than I can honestly remember. In the short years since I started in this industry I do think I've enjoyed some measure of success, and so feel qualified to speak a little on the topic of finding and securing work as a programmer.

Some of this advice is at odds with what technical interviewers say they want and may not be palatable to the average web developer, but it has worked for me and I'm willing to bet that a similar strategy will work for most technical job-seekers.

This is the advice I would give myself if I could go back to 2008:

0. Have a Strategy

My initial strategy (bad):

  1. Google for relevant openings
  2. Apply to the first three or four openings with a CV and cover-letter tailored to the job spec
  3. Wait and hope
  4. If this leads to an interview and an offer, accept, else go to 1

While this strategy was ultimately successful, the results were sub-optimal.

My recommended strategy for people earlier on in their careers (somewhat better):

  1. Start building assets that make you more hirable
  2. Collect information on a large number of job openings to get a feel for the market
  3. Prioritize the leads based on a set of criteria, personal to you
  4. Apply to the most attractive leads based on your criteria with a CV, and covering letter.
  5. Prepare for and give a good interview when invited
  6. Only make a decision when you have at least three offers in hand.

The objective with this strategy is to make an informed choice when you accept an offer. If the jobs available to you really do all pay less than £30k, then you should be able to confirm this independently before you accept the offer, not take it on faith from someone who benefits from you accepting a lower salary.

My current strategy is a streamlined version of the above that requires almost no effort (best, but you need to have the network for it, and you probably wouldn't be reading this if you did):

  1. Send out an email to some combination of:
    • contractors I'm friends with
    • the local Ruby user group
    • past clients
    • inbound clients whom I had to turn away due to no availability
  2. Interview with the resulting three or four companies that will be interested in hiring me.
  3. Accept the best offer based on my current situation, interests or other criteria.

1. Build Advantages

Before you start the application process, you need to have a number of advantages. In no particular order, some combination of the following will be required for you to predictably get offers from a companies that hire web developers:

Especially if you have no experience, that last point is probably the most important on the list. Just build something, make it public and take credit for it. This could be a todo list application, your personal blog, a twitter client or an online photo gallery.

Building things will reliably add to your skill points in each of the other attributes above.

None of these advantages are things that you can build overnight. They take consistent effort over the course of at least a month. Without them, it will be difficult to secure an interview.

2. Collect Leads

Using Highrise, a text file or some paper filing system, create a list of leads. For each lead list:

Good sources for leads, in order of preference:

For leads from your network, send a nicely worded email to everyone in your circle informing them of your current situation, the kind of work you're looking for and a link to your personal homepage where hirers can find out more about you.

You can send the same email to everyone, a custom message to each of your contacts or (my preference) a hybrid with some custom and some canned content. The yield tends to be low but network leads are usually of very high quality.

To find out what companies are hiring technical staff, it's worth looking for places that already list companies that build software. Silicon Milk Roundabout, Techcrunch, YC Alumni, client lists of software consultancies or anywhere else software companies are listed will do the trick. For each list, visit the companies website, look for their 'jobs' section and add any potential leads to your list.

Job boards are self-explanatory, visit them, look for potential jobs and add them to your list. Here's a few that have consistently listed high quality leads:

Try to resist the urge to apply straight away. At the moment the goal is to collect a large swathe of leads to get a feel for the technical employment market right now.

Some of the leads you've listed will be via recruiters. For the time being, treat recruiters like any other lead, log the job spec and continue. Before working with recruiters on a real-life opening, I would strongly recommend reading Secrets of Power Negotiating by Roger Dawson. It lists in detail exactly the sort of tactics that recruiters will use when dealing with you. Best to go into any business with recruiters with your eyes wide open.

3. Qualify Leads: Make a list of criteria for prioritizing opportunities

When looking at a job prospect, different things are important to different people. I can't claim to know what's important to you but this is my list of questions that I ask myself about a given lead to qualify it:

Add or remove questions as you see fit. Remote work may be an important factor for you if you don't live near a major city. You might prefer to work with many clients in a consultancy, or work on an in-house development team responsible for both new features and maintenance. You might have a preference for front-end over back-end work.

Based on your collection of leads you should have a good idea of the sort of jobs available to you in the current market, so you can adjust your criteria accordingly. If there's not a single opening for remote work, then you might relax this as a hard requirement for any positions you end up applying to.

Your list doesn't need to be a iron-clad; we're just trying to figure out what's important to you in any potential job opening. When looking for a job it can be quite tempting to accept whatever offer comes your way. Knowing what's important to you before you even make an application should help you keep focused on your own priorities rather than those of the companies trying to hire you.

Once you have a good idea of what's important to you, take your shortlist of leads and remove any that have no chance of meeting your criteria. You don't want to rule out too many leads, just the ones that are obviously not a good fit for you. It can be difficult to assess suitability without having an in-person meeting, so be liberal in what you let through for now.

4. Make Applications

Now that you've cut the number of leads down, it's time to start making applications. For each of your leads that have made it through your qualification stage, you're going to apply with a CV and a short email.

To begin, you'll need to put a CV together that highlights all the advantages you've built up. To reiterate, those include technical depth, technical skill, social proof and working software.

For social proof you might list some of the companies you've worked for and/or testimonials you've received from past colleagues. This could be for jobs that are non-technical if you have no relevant full-time experience.

For technical depth/skill you could highlight some of the technologies you've worked with and can reason about at different levels of abstraction. You'll should be able to talk confidently about anything you list here, and and demonstrate relevant skill in an interview.

For working software you should link to either a working installation of an application that you created or a code sample that you were responsible for. Make this easy to find and preview.

2-5 examples of each of the above will go a long way towards making your case to hirers selecting candidates for interview.

While the core content and stories of your CV should remain the same, it's worth customizing it to specific job descriptions. If you're applying for a job that will entail statistics and machine learning, you might choose a different set of sample projects than you would if you were applying for job building e-commerce websites.

You'll also need to write a brief covering email along with your CV, highlighting your suitability for the role.

If you're missing a major requirement listed in the job spec, ignoring it is the worst thing you can do. Your best shot at making up for any shortcomings is to address them directly and highlight your will and ability to learn fast and not be a burden on your future team. The covering letter is a good a place as any to do this.

I've written an example below of the sort of covering letter I might send over as a fresh-faced newbie, ready to start my adventures in the world of building software for money:

Hi Alice,

I'm Bob, a web developer currently available for full-time employment.

According to your company website, you're currently hiring web developers. Based on the information outlined there, I believe I would make a good addition to your team.

You might notice that I don't have any commercial experience, so I would be applying to this role as a junior developer. While I've never worked as a full-time web developer before, I'm proficient with many of the technologies listed in your requirements, have deployed working software and believe I would contribute value to your development team from day one.

Please find attached my CV with links to code samples and projects that demonstrate my abilities. Additionally, you can see my profile on github here: http://github.com/example-example-example

It would be great to meet for a chat at some point if you have any interest in taking this further.

Kind Regards,

-Bob, http://bobthewebdeveloper.example.com/

Don't just copy this blindly and hope. Mention reasons why you're a good fit. If they mention they could use someone with experience working with facebook applications be sure to highlight the facebook app that you happened to build a few weeks ago. If they're heavily in to analytics and usability testing, tell them you're interested in these areas and want to learn more (if you're not and you don't, then you should be and you should).

For each application, log the date that you applied in your lead filing system and be sure to follow up via email a set number of days later. My follow up schedule (assuming no response) is three days, one further week and an additional two further weeks before giving up on a lead. There are a million reasons why a potential hirer may forget to get back to you, so make it easy for them to remember. Follow up.

Take care with each application and make only three or four at a time. Applying to every one of your leads at the same time can be confusing for you and won't help you to make as good an impression as possible on each hirer. Wait a week before applying to more, and feel free to update your leads list based on new opportunities or information.

If they come back with a rejection, use it as an opportunity to learn. Being as courteous as humanly possible, ask them what their concerns were about your profile. For future applications, modify your covering letter copy to address any issues that they raise.

5. Interview Well

If your applications go well, with a bit of luck you should be invited to interview at least once. If you've made it this far then congratulations are in order, you're most of the way to securing an offer. If they weren't interested in hiring you, they wouldn't invite you in for interview.

There are as many types of interview as there are companies that hire programmers. There are highly technical slogging matches, going through data structures and ERDs on whiteboards. There are entirely non-technical interviews that speak in very broad terms about your history and abilities. They can be one-on-one, two-on-one or with a panel. You might have just the one interview or may get to meet different members of your future team in sequence. You might have pre-interview programming challenges or multiple phone screens before you're even called in to interview. With all this variation, it can be difficult to plan a general strategy for success at interview for a programming job.

Things are not much better from the interviewers point of view. There are many, many more applications for any given position than there are suitable candidates. If you're lucky and the applicants aren't outright lying on their CV, then the next surprise comes when you bring them in to interview and they can barely iterate over an array in any programming language. But also there's the worry that your interview process (which is very likely to be inadequate at finding good candidates) may turn away good developers and let in bad ones.

Most interviewers are worse at interviewing than you are at attending interviews. They make off-putting social blunders that put candidates on edge and ask trivia questions that don't do a good job of indicating how well a hire will perform on the job. Your mission, should you choose to accept it, is to make yourself monstrously hireable in spite of all of the above.

Interviews for programming work typically contain the following elements in some order:

What I'm going to outline below is my general strategy for using each of these phases to demonstrate the value you would have to give an organization, and to help you find out how well the company does against your own personal criteria.

Questions for you

The non-technical part of the interview is where you have opportunity after opportunity to demonstrate the value you would bring to a given organisation. Your job is to seek out these opportunities and exploit them, for both your benefit and the interviewers. No one hiring developers wakes up in the morning and says to themselves "I don't want to meet a technically competent candidate who can communicate as well as he can write code today."

Do a quick exercise: in your notebook write a list of the questions you think interviewers might ask you. What would you ask if you were hiring you and were given your CV? I'll do the exercise for myself right here as an example, but your questions will be different:

For each of the questions you come up with, have an answer prepared. You can write out your answers in detail if you prefer (and I recommend this if you're worried about nerves in the interview). I tend to scribble two or three points under each question in my notebook. If I forget any of these answers during the interview, I pause, open the notebook, and continue from where I left off.

The goal is not to recite prepared answers to all possible questions, but simply to get in the mindset of talking confidently about your experience and skills.

Have stories to tell about your experiences so far, the technology you've used and the software you've built. Try to weave together a narriative about your work experience that the interviewer can follow easily.

There may be questions you haven't prepared for, but after thinking through answers for a good sample, you should be able to tackle most non-technical questions with confidence.

Where possible, you want to highlight skills and experience that are directly relevant to the work you would be doing at the interviewers company.

Questions for them

This is a chance to express what's important to you and demonstrate more value.

I'm assuming that you care about these things:

Before a given interview, create a heading 'Company X' for the company you're about to speak to. Write the names and titles of the people you'll be meeting, the address and phone number. Examine the job spec and scribble out important details like responsibilities, required skills and technology choices. Go to their website and find out what it is they do, how they make money and what their core values are. Play with their website (for bonus points, see if you can break it). Find out as much about them as you can.

Much like you did for questions for you in your notebook, now list questions that you have for them. Some examples (what I really want to know in italics):

This is just a sample of example questions that you might ask. Pick and choose from the above and add questions about things you care about out (hint: have a look through the list of priorities you made for yourself).

Since you also took a bunch of notes about the organization, put together some questions specific to them. You're not interrogating them about the company here, just trying to get them to talk about their problems, day-to-day activities and things they would like to change or have done better. The more you can get them to talk about themselves, the better.

Technical Challenges

There are many types of technical challenges that interviewers like to put in front of you to guage your abilities. They range from arbitrary knowledge of library APIs to questions on OO design patterns and data strucutres to testing your abilities at making fermi calculations.

By the time you get to interview, you either will or won't be prepared for the tests they put you through. There's nothing you can do to cheat in a technical interview, the only thing you can do is control your response to the situation as it is.

Here's what I would do at varying levels of confidence in the face of a technical question or task put in front of me:

Bad: I lack completely the knowledge or skill to tackle this problem.

In this situation its best to come clean straight away and let the interviewer know that your skillset doesn't extend to solving this particular problem.

The worst thing you can do here is try to bullshit your way through the problem. Those with technical knowledge in the area you're bullshiting through will be able to detect it almost instantly and this will be marked against you.

If you find yourself in this situation, be sure to read up on whatever you were caught out on.

Better: I can probably solve this problem, but may need help/documentation along the way

Again, be honest. Tell the interviewer what you're not clear on, and repeat the problem back to them. Work through it with them rather than attempt to solve the problem on your own.

In a good interview, most of the questions should be at this difficulty. Watching you apply your technical skills along with your creative and intellectual faculties to a non-trivial problem is the exact reason interviewers conduct technical challenges, so go slowly and make the most of it.

Best: Give me 20 seconds... done!

Smaller coding problems like fizzbuzz, 'implement select without select' or 'implement a function that counts all the instances of each class in an array' are the sorts of problems you should quite literally be able to do with your eyes closed.

These sorts of programming challenges are a great opportunity to show off your skills with a little flamboyance. You could write a quick unit test for any function you're asked to write or show off a subtle language feature that they may not have heard of.

More random advice for doing well at these technical challenges:

After the interview: As you did with your application, be sure to follow up if the company doesn't get back in touch. Ask for feedback if they decide not to extend an offer right now.

6. Compare Offers

You should have at least three offers at companies you would like to spend the next few years with in hand before making a decision. I think you should have multiple offers because:

Whatever you do, don't accept the first offer made to you straight away. Tell them you need at least a few weeks to think about it and ignore any high-pressure sales tactics ("we need a decision by tomorrow!") they throw in your direction. If they want to hire you, they'll wait.

With the offers in hand, all that's left is to compare them based on the criteria you listed at the beginning of this process.

You are of course free to revise your criteria at this stage: if you've come up with offers (like I did) with wildly varying salaries, you might decide that you do care more about the money after all.

Conversely if your expenses are met at a fraction of the salaries you're being offered, you might prefer to go with the riskier startup building NLP analytics platforms over your sure thing e-commerce site.

(Side note: In my experience at least, outside of finance, full-time technical jobs tend to go up in quality with salary, especially at startups).

Wrap Up

That about sums up my advice for web developers getting started in this industry looking to find full-time employment.

I'm still figuring a lot of this out for myself, but for the long-term, nothing beats having a network of other developers/potential clients at your back when you're looking for work. You should take steps, starting today, to build that network and treat everyone in it like solid gold.

Further Reading

- Najaf Ali

Find this article useful? Sign up to our mailing list to get updates like this in your inbox every week. No spam, and you can unsubscribe at any time.
Give me the goodies