How to get a job as a 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:

• A team of experienced product managers who knew what they were doing
• An agile process that actually worked (no, really!)
• Fast-changing business requirements that often made sense
• All the politics you would come to expect from a dev team of more than 20, in a company of 100+.
• Mountains of technical debt, being refactored one piece at a time.
• A polyglot codebase (PHP/ActionScript for the web front-end, Java for back-end services)
• Lot’s of heated debate with a team of exceptionally bright developers.

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

1. Interview with the resulting three or four companies that will be interested in hiring me.
2. 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:

• Social Proof. If you’ve been hired by three other companies in the past, have a string of testimonials and the battlescars to show for them, you become a lot easier to hire. I realize that if you had that sort of track record, you probably wouldn’t be reading this article, but it’s worth pointing out how important this is for your hirability.
• Building a network of professionals that can vouch for you not only makes you more valuable in the eyes of potential hirers, it also gives you a lot of confidence going into an interview. Bonus points if your network actually includes one of the interviewers.
• Actionable advice: Get hired as a web developer and spend a few years doing a good job of it. Failing that, attend local user groups and tech-scene events, meet people in real life and try to impart something of value when you do.
• Technical Depth. I believe that anyone who works programming computers should “know what they don’t know” about the entire stack, from electrons to endofunctors. Additionally, if you believe that you won’t use data structures and algorithms in your job, then you probably never will.
• Actionable advice: Read about the job of programming and take steps to get better at it. Learn about OS fundamentals, object oriented design patterns, functional programming, network protocols, finite state automata, data structures + algorithms and whatever the hell else you can get your hands on.
• Technical Skill. It doesn’t matter if you use Dreamweaver to build websites with APL as a scripting language as long as you know those tools well. Also, learning to use a VCS (e.g. git) is a prerequisite for any programming job in the 21stcentury.
• Actionable advice: Use deliberate practice to get better at building software. There’s a difference between knowing the perfect recipe for a roast chicken and having the skill to debone one in sixty seconds. If there’s any technical skill you can think of that you’re worried about not having, chase it down, practice it and own it.
• Some examples might be getting better at modifying code in your favourite text editor, learning how to set up and configure a web server by hand, doing non-trivial joins in SQL or improving your abilities at the terminal with coreutils.
• A Web Presence If I go to your personal homepage, is there an easy way for me to find about your expertise? Do you have a profile on LinkedIn that I can read through to find out about your experience and skillset? Can I at least get a hold of your CV? You don’t need to be a prolific blogger, but there should be an obvious starting point that potential hirers can use to get to know you asynchronously.
• Actionable advice: Build a website that shows off you skills, experience and portfolio, making sure it links to other places on the internet where you can be found. This could be a single page with an intro, contact information and sections headed ‘skills’, ‘experience’, ‘portfolio’ and ‘links’. Don’t spend forever on this, just get that single page up, make it look half decent and move on.
• Working Software, publicly available. You don’t need an illustrious github profile with a long history of open-source contributions. Hirers just want to confirm that you can code at all. Make this easy for them by building things and putting the things you built where they can see them. It just so happens that github is a useful tool for this, so you might want to consider hosting your public projects there.
• Actionable advice: Spend a little time brainstorming potential portfolio pieces, pick the most interesting project out of your list and build it. The smaller and easier to complete, the better. Once you’ve finished, make it available at a public URL and host the code on github. Repeat twice for best results.

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:

• Name of the company if known
• Contact information for sending an application
• A URL to the job listing if applicable

Good sources for leads, in order of preference:

• Your personal network. An opening that’s vouched for by someone in your professional circle is preferable to more or less any other sort of lead. It’s more likely to be a good fit for your experience/skillset and you’re more likely to get the job.
• Direct applications (usually to a job specification on a company website). These take a little more effort to make lists of but tend to have a higher interview rate as you’re not competing with other applications to a posting on a job board for example.
• Job Boards are a good place to find leads, but you’re pitted against a large number of other applicants. Rather than general-purpose jobsites covering all fields, I’ve found that sticking to technical job boards yields more and better quality leads.
• Recruiters are tricky to deal with. They’re easier to understand once you have a good mental model of their incentives, however are prone to try high pressure sales tactics on you. If you can handle that and accept that their antics are all ‘part of the game’ then they can be a good source of potential opportunities.

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:

• Authentic Jobs
• Github Jobs
• StackOverflow Jobs
• Hacker Jobs UK
• CWJobs

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:

• Are you likely to secure an offer? While this can be difficult to guess, it’s obvious that if the position requires three years of professional programming experience, you’re not very likely to receive an offer straight out of university.
• Will your skills and knowledge progress (in the direction you want them to)? If you want to level up as a developer, you won’t be challenged if you’re building content managed websites forever. Based on what the company does and the sort of technical tasks it will entail, will you have passion for the work?
• Will the job pay you enough? Again different people have different needs but any job you apply to needs to pay you enough so that money isn’t an issue for you.
• Is the job secure enough? Do you want to be the first hire in an early stage startup? A new member of an established technical team? A suited Java developer at BigCo? There’s no right or wrong answer, but it’s worth assessing the risk profile of any company you apply to before persuing employment.
• Am I going to be productive with this company? Will they have some sort of iterative development process or is it the same chaos that most companies that happen to need programmers find themselves in?

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:

• Non-technical questions for you
• Questions you have for them
• Technical challenges for you to complete

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:

• Tell me about your work history.
• What experience do you have with Ruby on Rails?
• It says here you can speak fluent Japanese, you’re kidding, right?
• What was your experience at #{past company} like?
• What’s a technically challenging thing you’ve worked on recently?
• What are your strengths and weaknesses?
• Where do you see yourself in five years time?
• Are you more of a front end or back end developer?
• What sort of role do you play on a development team?

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:

• The company you’re thinking about working for and what their goals are
• The working conditions, technology, process and culture
• The software that you will be building, and why you will be building it
• Everything that was important to you about the role, as highlighted in your qualification stage.

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

• Tell me about some software you’ve delivered to users in the past month.
  (Do you regularly deliver working software?)
• How do you measure the impact of your software on end users?
  (How do you know what you’re building is what your users actually need?)
• Are you profitable?
  (How secure is this job?)
• Why are you hiring developers now?
• How is developer time spread between maintenance and building new features?
  (Am I going to be spending the majority of my time fighting fires?)
• Tell me about your technology stack and architecture.
• How do you organize developer work? Do you use an iterative development process?
• What’s the development teams stance on documentation? Unit testing? Code reviews?
• What major projects is the development team working on at the moment? What’s the strategic motivation behind them?
• I see you’re using {some tech} for {some task}, what made you choose it? How has your experience been with it so far?
• How much downtime have you experienced in the past six months? Can you walk me through how you would respond to your website going down right now?
  (Will I be expected to fix the website on weekends/late at night?)
• Do you do user experience or A/B testing?
• Do you have automated acceptance tests and dedicated QA?
• Does the development team get time to improve the quality of the software?
  (Will we have time to drain the swamp?)

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:

• Bring your own laptop. The last thing you want to be worried about in the middle of an interview is getting used to someone elses development environment.
• Be honest about your skills. Lying about your abilities or experience is a great deal harder than telling the truth, regardless of the content. Lies require supporting lies, and unless you’re a professional con-artist, its altogether simpler and more effective to work with the truth.
• If you get confused or nervous, take a break. No one is going to mark you down for saying “Do you guys mind if I take five minutes to work through this and get back to you?” in middle of the interview. You can use that time to get centred, calm your nerves and work through any problem slowly.
• Confirm your assumptions. Interviewers don’t correct you if you make subtle mistakes in these tests, so confirm any assumptions you make at every stage of your thinking.

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:

• Multiple offers give you more confidence. Having two offers in hand before going into a new interview helps to change your mindset from:
• “Please give me this job, I’ll work ever so hard for you!”
• to:
• “Let’s find out what we have to offer each other.”
• The first is born of desperation, the second of the desire to exchange value as equals. Which do you think a potential hirer (worth working for) will prefer?
• Multiple offers allow (some degree) of playing offers against each other. This doesn’t necessarily have to be about your salary… it could be negotiating any of the points you’ve made on your priority list.
• This might sound like I’m advising you to be manipulative, but with multiple offers in hand, this is the opposite of being manipulative. If you really want to work for Company X but don’t want to be on call for production support on weekends, now is the honest time to say so, not after you’ve accepted.
• You often won’t need to do this sort of negotiating actively. Interviewers will ask if you have other offers or are interviewing elsewhere. If you’ve followed my advice, you should answer positively to both of those questions and give them details on the other offers, along with your reasoning about why you might pick one offer over others.
• You could argue that you don’t actually need real offers to negotiate in this way, but see my above points about telling the truth. A potential hirer can’t call your bluff if there’s no bluff to call.
• The act of getting multiple offers teaches you more. After attending three interviews, depending on the sort of companies you applied to, you will have had an hour-long in-person meeting with senior technical staff in three different organizations.
• If you took the opportunity to ask pertinent questions during the interview, you’ll have that much more technical context about how different types of development teams work, which can only be a good thing for you.

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.