Everyone looking to get a junior web developer job and transition careers should be intimately familiar with the technical interview process.  Especially, since the technical interview is likely the only thing between you and a fulfilling career as a web developer. Even for career switchers with plenty of prior interview experience the technical interview is very different from any interview you’ve been on.

We’ll first explain, what exactly does a technical interview entail (hint: it’s probably a lot more intense than you’re expecting) and then we’ll go into specific tactics and things to avoid.

 You’ll learn:

• The number one mistake junior web developers make that indicates their true lack of professional experience as a web developer.
• How hiring managers will put you on the spot to find out how good you really are.

Level 1: Getting the Interview

The first step towards getting a job offer, is an opportunity to crush the interview.  Although it sounds easy enough in theory, getting your first interview for an awesome web developer job can be tricky.

Crafting the Perfect Resume

When searching for a job, having an up-to-date resume that accurately reflects how awesome you are is a must.  You should wait with finalizing your resume with specific technologies, experience and your open-source contributions until you’re very close to begin the job application process.

Your first pass will likely have a lot of room for improvement.  This is good.  Resume writing is difficult, so putting time and energy on getting it right will help.

A couple of rules to live by:

• You definitely want to have a senior web developer (someone who has been involved in hiring decisions), review your resume and give it critical feedback.  Sharing your resume as a Google Doc, and receiving  feedback right inside the document is usually the best way to do this.
• In most cases less is more.  People who look at your resume are looking not for why you’re awesome, but red flags to quickly put you into the “no thanks” pile of resumes.
• Absolutely do not highlight work you did while following tutorials.  Things like hacker-news-clones, pinterest apps, or anything you built with guided instruction isn’t interesting, because it isn’t how software is written in the real world.  You get dinged pretty quickly for this, so leave it out

Don’t spend too much time on your first version, get expert developers to give feedback and work with it.

Blasting Your Resume

The Internet has made submitting resumes easy.  Sites like craigslist, GitHub jobs, monster.com, CareerBuilder, StackOverflow careers and angel.co all exist and it’s never been easier to apply for a job.

This is actually quite unfortunate, because since it’s so easy to do you’re competing with a large number of applicants.  It’s not uncommon to quickly realize that sending your resume out is not the most efficient way to get interviews.

After you get a year or two of experience under your belt you’ll receive half a dozen unsolicited emails from recruiters a month; but when you’re starting out, it’s harder.  That’s why we generally suggest to use your network when you’re starting.

The process employers who post job listings take is pretty simple:

• First, they print out all resumes they receive from various job boards and put them in a stack.
• Second, most will be put into a “no thanks” pile after skimming the resume for about 20-30 seconds.
• Third, good resumes will be read a big more carefully, and then about 10% will usually go into a maybe pile.
• Fourth, resumes in the maybe pile will be reviewed more carefully by the team. They may check out your GitHub profile, personal web page, or any links they’ve provided, or do a google search for you name if you don’t provide anything.
• Fifth, about half of the resumes in the maybe pile, will result in actually getting an email reply to schedule next steps.

This process allows employers to filter through resumes pretty quickly and efficiently.

Leveraging Your Network

People who work as full-time web developers generally have a good idea which companies are hiring and also have friends who currently work at those companies.

A warm introduction to a hiring manager from someone they trust will get you an interview incredibly quickly.  If they’re recommending you for a position within their own company, the process will be even smoother.

If you get an introduction to the company, your resume will get placed on the top of the company’s stack of next steps resumes, even if it’s likely you would’ve failed the 20-30 second scrutinizing it would’ve gotten before.  A little hustle goes a long way here.

I know what you’re thinking:  You don’t have a network you can leverage yet.  That’s ok; we’ll talk about specific tactics to get a network you can leverage later in the post.

Level 1.5: Phone Screen (only happens sometimes)

Sometimes after going back and forth via email, employers will schedule a phone screen.  At this stage roughly half the applicants will probably move on to the next steps.  The other half will either not follow up, or send a polite message that they’ve chosen not to continue.

The phone screen will generally start out with some light conversation and have a couple of technical questions in it, designed to screen people who have blatantly lied on their resume.  You should be ready to talk to someone who is technical here.

For example, if you list Ruby on Rails as a skill, employers will know that it is a web framework, and most applications will need to connect to a database.  They also will know that most web applications deal with Model View Controller architecture (MVC) or need to interact with the HTTP protocol.  If this doesn’t make sense now, that’s ok, but it should by the time you’re at this stage.

Questions you could get:

• Explain MVC architecture.
• What is HTTP?
• Why do web applications use databases?

These types of questions are more high level, and are general (not specific problems to solve), that are generally used to just make sure you’re not completely lying on your resume.

The person conducting the phone screen will generally ask for your coding background and listen to your introduction as well..

Level 2: The Interview

Going into the interview, it’s important to understand the company’s perspective on hiring you.

If you’ve made it this far, everyone who is interviewing you, wants to hire you.  Interviewing is a time consuming, taxing experience for companies and team members as well.  If a company is hiring, they are likely hiring because they have more work they need to do than the current team is capable of.  The hiring process is helping the team get back the one asset they don’t have enough of right now: time.

But there’s a lot on the line for companies when they hire a candidate.  Most good development shops (the places you actually will want to work for), follow Joel Spolsky’s Advice for hiring, a quote of his advice to hiring managers is below:

It’s because it is much, much better to reject a good candidate than to accept a bad candidate. A bad candidate will cost a lot of money and effort and waste other people’s time fixing all their bugs. Firing someone you hired by mistake can take months and be nightmarishly difficult, especially if they decide to be litigious about it. In some situations it may be completely impossible to fire anyone. Bad employees demoralize the good employees. And they might be bad programmers but really nice people or maybe they really need this job, so you can’t bear to fire them, or you can’t fire them without pissing everybody off, or whatever. It’s just a bad scene.

On the other hand, if you reject a good candidate, I mean, I guess in some existential sense an injustice has been done, but, hey, if they’re so smart, don’t worry, they’ll get lots of good job offers. Don’t be afraid that you’re going to reject too many people and you won’t be able to find anyone to hire. During the interview, it’s not your problem. Of course, it’s important to seek out good candidates. But once you’re actually interviewing someone, pretend that you’ve got 900 more people lined up outside the door. Don’t lower your standards no matter how hard it seems to find those great candidates.

So companies have a lot on the line to make the right decision during interviews.  This means some interviews will be long and grueling.  When I was interviewing candidates for teams I’ve been on at WHERE.com and PayPal we would generally split the interview into 3 pairs of developers.  Each pair would:

• Have a brief (10 minute) conversation about the candidate’s background, goals, etc.
• Spend 50-80 minutes whiteboarding and problem solving on a specific question.

If the first team saw a lot of red flags, the interview would be cut short and the other teams wouldn’t get involved, and the applicant would be told the interview was complete, and we’d follow up via email that we have chosen not to hire them.  This process is called short-circuiting the interview, and is designed to prevent wasting everyone’s time.

Sometimes we would take an hour break to take the candidate out to lunch.  Sometimes we wouldn’t, depending on the time of day, the team’s availability, and the availability of the candidate.

After 3 pairs of people white-boarded 3 different problems with the candidate, the manager of the team would sit down with the candidate and answer any questions they had.  In the process they would also sell the candidate hard why the company is the best ever, how the team is the best, and try to ensure that if we were to extend an offer they would be pumped to accept it.

Our hiring process was more rigorous than many other places.  In my career as a developer, I’ve been on equally long interviews and shorter ones with only a single whiteboarding exercise.

Keep in mind: if someone sells you at the end why the company is awesome, it doesn’t mean you have the job locked down, it just means at this point in time the hiring manager thinks you’re a candidate that may receive an offer.

What does this whiteboarding thing entail?

Alright, since you’ll be spending 80-90% of the time you’re being evaluated for a technical interview “whiteboarding”, it should be clear that the thing that matters most is your ability to whiteboard.

In the process of whiteboarding the interviewer will prompt you with a coding challenge and have you come up with a solution right  on the spot.  There are a few caveats that make whiteboarding particular gut wrenchingly hard.

• When coding, you’ll master the craft by typing into a computer.  After you type in the code, you’ll execute it and see if it runs.  When whiteboarding, instead of typing into a computer, you’ll draw code on a whiteboard with a dry-erase marker.
• When coding, you’ll usually code by yourself without anyone watching or judging you.  While you’re “coding” on the whiteboard, you’ll have an audience of strangers you’ll need to explain your thought process to.

The problems you’ll be asked to solve on whiteboarding exercises will generally be complex questions that require you have a solid foundation in algorithms, data structures, and things generally taught in a 4-year university degree.

An example of a coding question you may be asked is to:

Build a data representation of a tweet.  How would you represent retweets and favorites?

This problem sounds easy in theory, but naturally starts moving towards advanced graph theory searching algorithms.  For example:

For a particular tweet I want you to write a depth-first-search algorithm to determine if someone with the twitter handle “barackobama” retweeted the tweet that is supplied.

In general, a thorough, difficult, interview indicates that the company is selective about all their applicants and has engineers you’ll be able to learn a lot from.  An easy interview indicates you may not be able to get on-the-job mentorship and pair program on hard algorithmic challenges that will help you grow as a developer.

So for a given interview it can last anywhere from 2-6 hours consisting mostly of problem solving on the whiteboard, talking about code, and testing your skills deeply.

Think about the interview process similar to how you would consider the SATs in high-school.  You may be tempted to cram the night before, studying various coding websites.  At that point it’s too late.  Last minute studying is likely more harm than good; be well rested and know that the code you’ve written your entire life right up to the moment you walk into the door is how you actually prepared.

Interview preparation isn’t something that can be condensed into a week or two long “job preparation cram course”

If you approach interviews this way, when you get interviewed you’ll be asked questions where you don’t even understand the question that’s being presented, let alone have any of the answers.

Instead you should focus on gaining a solid understanding  and deep knowledge about  algorithm and data structures foundations, from  the moment you start your coding journey.

Why companies use whiteboarding to screen candidates?

Whiteboarding is an important process that teams use to evaluate the problem solving abilities of an individual.  It’s how they can tell if an individual will be able to solve the most complex parts of the product they’re building.

Some people critique the interview process and say that whiteboarding is so far removed from actual coding and involves too much arcane computer science to be of any use.

Whiteboarding is a bit of a controversial topic, but it doesn’t change the fact that this is how 9/10 companies will choose who they hire for a web developer position.  So love it, or hate it, for the time being, preparing for the whiteboarding experience is important.

Asking the Right Questions

At the conclusion of the interview it’s important to have questions about the company.  You should ask questions you genuinely care the answer to.  I usually like to ask questions about:

• The team’s workflow.  Think about your experience coding with a team, and ask about protocols you followed to see if they match up.
  • “Does the team use Test Driven Development (TDD) to ensure the code is working?”
  • “How does the team perform code reviews?  Do you use GitHub pull requests?”
  • “How will I as a developer be assigned specific tasks?”
  • “Am I involved in the sprint planning, or just handed off tickets like a cog in the machine”.
• The company’s operations.
  • “How will my day-to-day work impact the company’s vision of X”
  • “How long of runway does your company have” [particularly for venture funded startups]
• Technology decisions
  • “Why are you using ruby on rails instead of java spring?”

Level 3: The Review

After interviewing candidates the hiring manager will bring everyone involved in the process together to have a short 30 minute talk about how the candidate performed and determine whether or not the teams wants to extend an offer.  The conversation generally happens the same day, sometimes the day after.

After the conversation, the decision is basically made and you’ll be either offered an opportunity to join the company, you’ll be passed on, or if you did good but more candidates are going to interview for the same position, put on hold to see if another candidate knocks it out of the park.

At this moment your fate is basically sealed from a yes / no perspective.  Salary negotiations, position title and other stuff is still up in the air until you sign the offer letter.

Things You Should Definitely NOT Do.

You should not assume you need to wear a suit and tie.  Most developers wear a t-shirt and jeans in the office everyday.  As a developer, after working in casual attire it’s something that is easily forgotten about.  Seeing an interview candidate come in wearing a suit and tie in the office might be indicating your lack of experience.

This isn’t the same at all companies.  Large companies, will be different than startups, which will be different from financial companies.  If you’re in doubt of what the attire generally is, ask before you go, but don’t just assume you need to dress up.

You should not refuse to do the whiteboarding problem.  This seems like an obvious one, but on more than one occasion people have refused to solve the problem I was asking them on the interview.  Sometimes because it was too hard.  Sometimes because “it’s too easy and I’m above it”.  Both cases you get a big no from the team.

You should not give up when doing the whiteboarding problem.  If you’re 50 minutes in, struggling, and not sure where you’re going, keep going.  Effort pays off, and even if you don’t get the right answer, trying with every bit of energy shows you’re a hard worker who doesn’t give up.

Tactics to Reverse Engineer Your Coding Bootcamp Experience to Nail The Technical Interview

Now that we’ve walked through what a technical interview actually entails, we can reverse engineer the specific tactics that you can take right away to ensure you’ll ace the interview when it comes, and land the job of your dreams.

Tactic #1: Start Networking Today

The sooner you start going to the right events the better.  Try to attend at least one event per week if possible throughout your entire 10-12 week coding bootcamp experience.  You’ll likely want to wait until you’re on your job search to start attending events; but going to events is another thing that you can’t “cram” for at the end.

For example, BostonRB is a great local Boston group, but they only have a single large event each month.  If you’re learning Ruby on Rails and want to switch careers, you definitely want to attend every meetup of your local ruby group.

Pay special attention to the type of event you go to.  Your goal should be to go to events that will attract top developers, who know exactly is hiring and can help you out.  An event titled:

Interested in Coding? – Tips On How to Get Started

Might be super inviting for you, but this type of event would be super boring for a developer who has been coding for 5+ years.  Instead, you’ll want to look for advanced topics like:

The Soft Underbelly: The Uncommon Attack Vectors You’re Not Looking For

These types of events will draw experts who are the type of people you want to meet.  At first you’ll feel out of your comfort-zone, but you’ll likely learn quite a bit from osmosis, but more importantly start forming relationships with developers who can ultimately help you.

Tactic #2: Volunteer to Help Out

There are many free coding events out there that are looking for people to help TA.  Events like RailsBridge, WomenWhoCode, and RubyBrigade are excellent opportunities to become the teacher rather than the student.  Not only will you receive endless good karma by helping aspiring coders out, but lots of good opportunities present themselves to people who put themselves in this position.

If you’ve been in a coding bootcamp for several weeks, it will also be a nice opportunity to quickly show you how much you’ve actually learned in the time span and how much you’ll be able to help out; it’s easy to forget how much you’ve actually picked up in a small period of time.

Tactic #3: Go all-in on learning algorithms

If your coding bootcamp doesn’t provide instruction about how to solve algorithms or deal with complex data structures, know that you’ll be a bit behind when you start interviewing, since that’s the number one thing interviews assess.

This is ok, if you take a pro-active approach and aggressively self-study with all your free time.  Here are some things you should be comfortable with when you start interviewing:

• Graph Search
• Big-O Notation
• Linked Lists
• Multi-Dimensional Arrays

If your coding bootcamp doesn’t cover these topics, find a code mentor to help you learn them.  They matter.

Remember, this stuff takes a while to learn, many colleges teach it for 4 full years, so you can’t cram it into a single week experience.  It needs to be an integral part of your coding experience.

Tactic #4: ABC Baby, Always Be Coding

It’s not uncommon to be asked “what was the last thing you’ve worked on”.  Answering the question with, “what I’m coding these days is a project to do X, Y and Z”, indicates that you’re not just coding to check a box.  You’re actively engaged and love doing it.  Whether someone is paying you to write software, or you do it for fun, code is part of your identity.

Since the best coders know being a web developer is a life-long learning process, it’s important to keep evolving and keep challenging yourself.  Solving hard problems and building cool projects is the only way to become a better developer.

Tactic #5: Go to Hack-a-thons

Hack-a-thons will not only expand your network and help you meet developers, but will give you an opportunity to continue coding and work as part of a team on a project.  Go to hackathons during and after your coding bootcamp experience.

When you go to hack-a-thons, it might be tempting to evaluate different teams based on the idea and how much you like it.  Don’t do this.  Instead, what’s more important is the team.  Find a team with 3 or more developers, where you can work together with them, even if the idea is terrible.  What’s more important is expanding your network with the right people.

After the hack-a-thon is over make sure to add them on LinkedIn and Facebook.  People I’ve worked with in hack-a-thons have had a weird way of being super helpful after the weekend is over.

Tactic #6: Until you sign the offer letter, keep hustling to get more interviews.

Always hope the for the best, but expect the worst.  Don’t wait for a rejection to pursue the next opportunity.  Work asynchronously and try to line up as many interviews at the same time as possible.  Be frank and honest that you’re doing this if you’re ever asked, but don’t feel bad about it.

If you have less than 10 interviews each week, you could definitely handle more.  Spend free time pursuing getting more interviews. 

Tactic #7: Plan out a “story” about your past experience.

You’ll be asked for a bio in many different ways throughout the interview process.  Every person you talk to will generally be interested in your background.  Questions like these will definitely be asked of you by many different people.

• Tell me about your background.
• Where have you worked in the past?
• How’d you get into web development?

Plan out a “story” about how you’re changing careers into web development.  Try to make the story flow as naturally as possible, where becoming a web developer ended up being the obvious choice, because you enjoy building products, solving problems and everything that coding entails.

Depending on your background this may be easier (if you studied chemical engineering in school and had to do programming in C++ to get your degree), or might be a bit more tricky.  Spend the time before your interactions with employers to think it through.  When introducing yourself at meetup events, use the bio you’re working on here a few times to get comfortable with how people react to it.

Web developers also love entrepreneurs, so if you’ve ever owned, ran, or started a business highlight that fact, even if it was completely unrelated to web development.

But the most important thing is to keep a positive attitude throughout the process.

If you have a positive attitude, focus on learning skills that really matter and treat every interview as a life experience you intend to learn from, rather than being nervous about the outcome, you will win in the long term.

What’s holding you back the most from a junior web developer job?  Tweet us at @FirehoseProject and let us know.