The last time Hackerfall tried to access this page, it returned a not found error. A cached version of the page is below, or clickhereto continue anyway

Lessons from Both Sides of an Interview Desk

This post is a textual representation of a talk I gave at the Ruby Ireland meetup in Dublin on the 23rd of June 2015. Show notes can be found on Github. The slides are available on SpeakerDeck.

If youd like to practice your interviewing techniques, were more than happy to talk to you (and possibly give you a job) at LegitScript.

In October of last year, 2 months before my thirtieth birthday and following years of incessant nagging from my mother, I decided it was time for me to get my first full-time job.

In the subsequent six or seven months Ive gone from being a wide-eyed job candidate, fresh into my first formal interview funnel, to becoming a fully-fledged member of a programming team. Ive even interviewed a few candidates on my own.

This rather compact experience has provided me with recent knowledge of what its like to be on both sides of the interview table. And I feel like I can relate to the positions of all involved parties.

Theres plenty of dumb things I did when I was applying for jobs that I didnt realise were dumb until I started reviewing applications myself. It was only when I saw other people making the same mistakes that I did that my errors became clear to me. Ive learned some important lessons on this journey which Im going to share with you today, and hopefully youll pick up a few tips you can use yourself.

The type of developer I was 9 months ago

I wont dive into the story of how I ended up making it to 29 without ever having a grown-up job. You can ask me about that later. However, I do feel like this talk will be more useful if I provide some context about the type of developer I was last October when I started sending applications.

In a nutshell, Im a self-taught Ruby and JavaScript programmer with a mechanical engineering degree. I had about 3 years of professional freelancing and contract experience and a handful of side projects. I have a reasonably active Github account with a couple of open source projects. I even sometimes write code related blog posts and put them on the internet where nobody ever reads them.

I probably came across as your average better than junior but not quite senior developer. The one thing I really had going for me is the fact that I could easily display a love for programming and an ability to ship stuff. Even still, I highly doubt I could have convinced Google to hire me.

Job hunting takes a long time

The most surprising thing to me about job hunting as a whole is simply that it takes far longer than I expected.

Even finding companies which seem to fit your goals and skill-set can be an arduous process. Once you make contact, the average time to first reply is probably 3 to 4 days. A week later they might have reviewed your technical challenge. If you get past that stage theyll schedule an interview with another weeks notice. Then you have back and forth negotiation and even if you accept an offer you might not start for at least another 2 weeks.

I first reached out to HubSpot, for example, on the 17th of October and eventually was rejected on the 7th of November, 22 days later. And thats a second-round rejection. It would have taken far far longer to get an offer.

This lesson applies regardless of the type of company youre looking to work in. Smaller companies and startups dont have HR people to handle applications and are usually so busy that it can take quite a bit of time to process your application. Bigger companies do have HR people but the internal communication between HR and the people who have to vet the candidates is so slow it can take every bit as long.

Its not ridiculous to budget 2 months for the entire process. Make sure you either keep your current job or you have enough savings to get by during this time.

Time is money

The main factors to weigh when deciding whether to preemptively quit your current job or not can be pretty easily derived from the old adage of Time is Money.

You should be more likely to quit your existing job if it doesnt leave you with a lot of free time and you want to put a significant amount of work into making sure that you find a new job that suits your goals. You should be less likely to quit if you have a high personal burn rate and youre broke.

Choosing direction

Its important that you think long and hard about which companies to apply to. Its usually painful to do but its totally worth taking some time to lay out your five year plan. Its a bit like how characters in great TV shows have multi-series character arcs which provide background to their episode-by-episode antics. Each job is an episode which can exist by itself but it should tie into something greater and more fulfilling.

Dont just think about what job you want to have right now consider what doors will be opened to you once youve spent a year in that role. Are you likely to pick up some side-experience in the course of your work which will broaden your skill set and allow you to shift into a tangential but highly demanded role? Does the Ruby-on-Rails web company youre looking at have a mobile app you could probably work on to learn some Objective-C or Swift? Good managers are eager to let their employees learn on the job like this so its worth keeping in mind.

Also consider what doors will become closed to you after a certain amount of time in your new role. Once youve spent a 10 years working on Rails based web apps its going to be harder to transition to a job writing low-level systems code. Some interviewers will pass on candidates who have spent decades at megacorps because they prejudge them as being too inflexible and rigid for fast-paced startup life.

The size of the company you want to work at can also have a huge effect on the things youll get to learn there. Smaller companies are more likely to have general roles which produce programmers who can learn fast and wear many hats. Larger companies will have more specific roles and job titles but will provide an opportunity to learn comprehensive communication skills because you have to interface with more people, often in multiple countries and time zones. Bigger companies will also have more opportunities to transition into management than smaller companies.

Choosing location

Its also worth spending some time thinking about whether or not youre prepared to leave the country for a great job offer. In Dublin we definitely punch above our weight when it comes to tech but were still a limited market compared to other European locations and were minuscule compared to the US.

Most of us are in an envious position because we can easily live and work anywhere within the EU. If moving is an option for you its well worth paying attention to the job markets in other countries like France and Germany.

US VISAs

Despite the fact that theres a lot of hot companies in Europe, the US is still the main player in the emerging tech category and theres no sign of that changing anytime soon. In a nutshell, its really difficult to go and work in the US. The Visa options are limited and many have serious drawbacks.

For example, entering the Green Card Lottery, even if you dont win, can disqualify you from obtaining other types of Visa in the future because it shows an intent to live in the USA. Even the classic H-1B, where a company offers you a job and sponsors your move to the US, is difficult to obtain because the US government puts a strict cap on the number of VISAs they give out each year.

The Engineers Guide to US Visas the best overview of the situation I was able to find.

Theres also a couple of job boards which cater directly to people who need Visas with their jobs; TechMeAbroad and JobsInTech are good spots to try. Both of those will be in the notes too.

Working remote

In response to the difficulties that most companies have finding suitable employees, theres a fledgeling trend towards hiring remote workers in the tech industry. Im sure youve seen some of the work that early adopters like 37signals or Buffer have produced on this topic.

Remote working is something I did for years as a freelancer and it has its own distinct set of positives and negatives. One of the main reasons I decided to end my last contract was because it was remote and I felt like I wasnt meeting enough new people in my work. I have to say though, I really do miss working from my kitchen table in my underwear. My boss is in the audience tonight so hopefully my situation might improve by me saying this!

37signals have a job board which is dedicated to helping you find employers who are open to remote working.

In the show notes Ive included a link to an epic Github repo where contributors maintain a list of remote working job boards, companies who are primarily remote, resources on the subject and basically everything you could ever wish to know about remote working.

Finding listings

Theres a couple of general categories of places you should look for job listings in Ireland. If youre a Ruby programmer you already spend half your day on either Stack Overflow or Github. Both of them have good job boards where youll find both Irish and International listings.

The venerable Ruby Ireland job board and Google Group is a good place for Ruby or Rails specific jobs. Im sure theres something similar for Python developers or whatever other language you care to mention. Its worth keeping in mind that every country has some variation of these language specific job boards. For example, France has Rails France and Germany has RailsJobs.de.

The Hacker New Whos Hiring Threads appear to be mostly American companies so I ended up pretty much ignoring them. I got one decent referral for a remote job from making a profile on AngelList but once again, its mostly US startups on there.

I tended to stay away from traditional job boards such as IrishJobs when I was searching for places to apply. I found that they were mostly just filled with recruiter spam.

I also tried Hired.com which is an interesting inverted model where you sign up and let companies apply to interview you rather than doing the applying yourself. As far as I could tell there were very few European companies using it.

If youre interested in startup opportunities it could be worth your while to monitor startup blogs like TechCrunch Europe and WhiteboardMag. Theres two things that pretty much all tech startups do as soon as they raise their first decent chunk of money. The first is to get it written about in the startup news, the second is to hire developers. By monitoring tech blogs you can actively apply to companies who have just raised money and get ahead of other people who might apply after the job listings go up.

I wouldnt shy away from applying to companies simply because theyre not currently advertising any positions by the way. If you see a company you really like just send them a CV with a decent cover letter and explain why they should hire you. You probably have a decent shot. Passion for the problem domain counts for a lot.

The Application Process

Once youve sent a few applications and gotten a couple of responses, youll find that most hiring funnels follow a fairly standard pattern. You send in a CV and cover letter, then you do a short technical screening exercise. Then you might have a chat with someone on the phone and maybe do another technical exercise. If you make it past that you have an in-person interview. Then you have negotiations and a formal offer.

Cover Letter Writing

I cant understand why people dont send brief cover letters with their job applications. Its a great opportunity to showcase your communication skills and personality something that your CV doesnt allow for. It doesnt have to be long or difficult to write either. Just a few simple sentences about who you are and why youre applying to the job is enough.

The company I work for right now polices online pharmacies. You can spend 10 minutes browsing our website and easily find out information like what we do, who our clients are and who leads the company. All your cover letter needs to do is show me that you did this and that the company is interesting to you .

Heres an example.

Hi! I saw your job ad on Ruby Ireland and I would really suit the role. Im excited by the fact that you have huge companies like Google and Microsoft as clients. It sounds like valuable work you guys do. Looking forward to your response, David.

You can see it mentions Ruby Ireland so we know this person is looking in a place where we expect to find good developers. It shows that they spent some time reading up about the company and it explains why the person is applying.

This next example is the actual cover I sent when I applied to LegitScript.

Hi! Im a Dublin based web developer with tons of professional experience with Ruby and Rails, MySQL and TDD (basically your entire tech stack actually). Ive also been known to crack a joke every now and then. Have a great day, David.

It just states that I have proficiency with the tech stack and that I have a little personality. Im picking up on a joke in the job ad here by they way. I didnt just pull this crack a joke line out of thin air.

Putting something like that together takes two minutes and vastly increases your chances of being considered. It wouldnt surprise me at all if theres companies out there who just straight up filter out applications which dont include a cover letter.

You should notice how both the previous examples have no big words and no nonsense terms. Being a creative, energetic, and analytical programmer with an unquenchable curiosity about the world we live in is great and all but its a waste of a sentence in a cover letter.

One other thing you can use your cover letter for is to address any oddities in your application.

For example, if you live at the other end of the country from the job then you should explain that youre willing and able to relocate.

If youre from a country that requires a work Visa, explain in detail so that I dont have to spend an hour researching employment law in order to figure out whether or not we can afford to jump through the hoops needed to hire you.

Another good thing to mention is a significant difference between your programming experience and the nature of the job youre applying to. For example you could be a C guy trying to get a job doing Rails based web development. Thats not a deal breaker by any means but you should mention why you dont think it will be difficult to transition.

CV Writing

Im by no means an expert on CV writing but I could probably write a short book on it because its such a huge topic. The biggest and most common mistake I see is a failure to communicate your previous experience clearly and concisely.

Clearly means that you make it easy for me to understand what you did and who you did it for. You make it easy to understand what you did by telling me simple, specific tasks you completed. Look at this example for a second:

Migrated all payments related code in our main Rails 4 application to Stripe. This included migrating more than a million rows of historic transaction data. The new integration resulted in a 10% increase in checkout completions.

This example tells me really clearly what the actual task was migrating payments code. When I see a simple description like that, I can form some idea about the work that may have been involved. It also tells me that someone trusted you enough to let you mess with the payments process and that your SQL might be decent. It also shows that youre cognisant of business objectives because the results are listed.

Owned development of a customer facing blog posting feature for the duration of my time with the company. I decreased page loading times by 50% and increased engagement by 20% during this time.

In the second example, the use of the word owned is important. It tells me that you were in charge of something. Then theres a description of a task you completed and some results you achieved. This is good because we like hiring people who can achieve results.

Social proof

The other thing your CV should communicate is who you worked for. You can achieve this by giving me context on the company. I can tell a lot about your work environment based on how many developers you worked with and how many users you had or whatever other key metric you choose to use. It helps if you include that information directly on your CV. Working in a 50 developer team is a completely different experience than being the first hire at a 3 person startup, even if the tasks you completed where the same in both places.

Feel free to win me over with social proof like Clients include Google or 1 million dollars of monthly revenue. Im human and Ill fall for that. If you worked for a startup which raised significant money you might mention that fact to impress me.

The example here is off a CV sent in by a guy who used to work at an agency. In his CV he listed some of the agencies largest clients. Im not going to bother calling any of them, and they guy probably didnt even work on all of the individual projects. Nevertheless, somewhere in the back of my mind, Im impressed by this.

You CV also needs to be concise. That means you keep it short. CV writing is very much an exercise in quality over quantity. If you have 10 years of experience then I absolutely do not want to know that you had a part time job picking strawberries when you were 17.

This example is from a CV sent to us earlier this year. As you can see, it details experience from 13 years ago which lasted for 3 weeks. That tells me nothing about your current capabilities and only serves to reduce the signal to noise ratio of your document.

You might be thinking, fair enough, it doesnt hurt to list it anyway but thats not true. Every piece of useless information on your CV makes it more likely that Im going to miss the important stuff that could be the difference between you getting offered an interview or not.

CV Design

Formatting and styling are two other things that we as programmers tend to overlook but which can make a massive difference to your CV response rate. Of course, the content of the document is ultimately what is most important but the person inspecting your CV is human and theyre susceptible to influence by aesthetics. Why not use that in your favour?

Theres plenty of websites out there which can help you create and maintain a nicely styled CV with very little effort.

Once youve got a basic layout and style youre happy with, I highly recommend fine-tuning the copy for each job you apply to. Mirroring the copy of the job ad is a neat trick. For example, if the job ad specifies MySQL experience and you used MySQL in one of your previous companies but havent mentioned it in your CV, nows the time to make a subtle edit.

Coding Workshops

As tech jobs get more and more lucrative compered to other industries, were going to see more and more people enter the programming world via workshops and courses. Theres a wealth of these out there are the moment targeting people who wish to switch careers into programming.

If youve taken one of these courses, I highly recommend that you lean heavily on the projects and code that you produced as a result of completing the workshop rather than the fact that you did the workshop itself.

If you can use the skills learned in the course to create something and get it live then it could definitely be the key to open many interviewers doors. For most webby, Rubyish jobs, a junior developer with a history of shipping real applications is ahead of a Computer Science graduate with no application coding experience.

The next step in the funnel is usually a coding challenge. This is a screening measure that companies use to save time because they dont want to move on to formal interview until theyre at least reasonably sure you have some clue how to program. Its usually a short logic question to test that you can read, understand and write code and that you can clearly communicate.

Interviewers are looking for specific contextual clues about what kinda programmer you are and how you think about software development. These are potentially as important as the actual code you write while completing the challenge.

For example, consider the file format you use when you respond. Heres a couple of examples of response formats Ive dealt with and what it makes me think of you.

This first example is a docx file. It means youre likely using Windows, which is a negative in the Ruby world. It might mean youre more used to writing reports than code. If definitely means you didnt go out of your way to make it easy for me to read your code because theres no syntax highlighting and the font is horrible.

Next is a screenshot of a text editor. This works ok. Its easy for me to parse and I get to see what text editor you use which is sometimes nice. Anyone who tells you theres no bonus points for being Vim or Emacs proficient is lying.

However, if I want to run your code I need to retype it myself because I cant copy/paste it off a screenshot. I dont want to have to do that.

Finally we have a link to a Github Gist. This tells me that youre familiar with Github, open source and markdown. It shows me that youre concerned about the readability of your communication and that stuff like syntax highlighting is important to you.

Your choice of format is never going to be something that will make or break your candidacy but it is an opportunity to show the interviewer how well you fit into the world of the company that youre applying to. You might as well use every opportunity you have available.

Another good tip is to write brief Minitest specs for your coding challenge response. This immediately lets me know that you test your code, which is always a plus, and it doesnt add much to the length of time you spend on the challenge.

Regardless of whatever else you do, the most important thing with these challenges is that you communicate clearly and abundantly. When I applied to LegitScript I completely misunderstood the coding challenge question they asked me so much so that I thought it was a trick question. I saved myself by communicating so eagerly that they couldnt help but give me a hint and another chance. Communication absolutely saved that interview.

Work Samples

Theres a new trend in our industry right now towards bigger coding challenges in the screening stages. These usually involve the company taking some part of their codebase that they use frequently and asking you to reimplement it. For example, one company I applied to asked me to reimplement a system which could predict a persons work email address based on their name and the name of the company they work for.

These work samples are a larger undertaking for both the prospective employer and the candidate but it does provide a much better chance to showcase your skills in a real world situation. Candidates are constantly complaining that theyre being asked to jump through interview hoops which dont represent real world situations and this trend is a direct response to that. In general I feel its a positive thing and were likely to see more and more of in the next few years.

I dont really have any specific advice for these challenges other than to be very cognisant of your git history. The first thing Im likely to do as an interviewer is git log and read through your commit messages to check that you communicate important details succinctly.

In Person Interviews

Ok, so lets assume youve been through the whole funnel and gotten yourself a visit to the building. Great. In person interviews can be nerve wracking for even the most experienced and talented programmers.

The first thing to realise is that the ability to perform well in interview challenges is not some innate skill you have to be born with. Theres hundreds of programming questions available online for free which you can use to practice. In my experience the level of questions I encountered in real interviews was roughly the easy grade on most of the challenge sites so you dont even have to practice the harder questions.

When you practice these things over and over you get comfortable with deciphering the requirements of a question and approaching it in a logical and structured manner. The better you are at this the more you can relax in the and the more likely you are to perform well. Knowing how to assert palindromes and so on. will give you confidence even if it doesnt actually come up. If you can eliminate the fear of math and constructing algorithms then youre free to concentrate on coding and communicating.

Ask Questions

Last month, a blog post titled Embarrassing code I wrote under stress at a job interview by a guy called Lawrence did the rounds on Hacker News and Reddit. Lawrence wrote about how hed messed up a job interview by stumbling through a simple problem that under ordinary circumstances he would have been able to solve in his sleep.

After mishearing the interviewer, Lawrence was faced with the task of trying to write an impossible program which involved doing something until infinity. One line in the blog post stuck out.

Of course Lawrence went on to spend 20 minutes trying to answer a question that the interviewer hadnt even asked him.

Expressing confusion in an interview doesnt make you appear dumb. In reality its quite the opposite. One of the key skills of successful programming (and successful problem solving in general) is making sure you have a clear understanding of the requirements of the problem.

Taking a couple of minutes to talk through the requirements of the question helps the person on the other side of the desk understand that youre a thoughtful and considerate developer.

Specific Common Questions

I dont want to go too much into specific questions because nobody benefits from it, but I have to mention that a huge proportion of interviews I did involved some variant of counting items into a hash. You iterate over an array of objects and populate a hash with the number of occurrences of each object. Know how to do this elegantly and be able to talk about how fast it is and why its a fast operation.

Companies also love to ask follow up questions about big-O notation. Make sure you understand it and are able to talk about the complexities of various common operations.

Being a self-thought developer Id gladly managed to avoid this topic for years but I took some time to sit down and study it just before I started interviewing. This paid off big time.

Negotiating

Once youve run the interview gauntlet a couple of times you will hopefully end up with a bunch of rejections and one or more job offers. At this point, assuming you actually want one of the jobs youre being offered, you enter negotiations.

Other people like Patrick McKenzie have discussed negotiating better and more deeply than I could ever hope to do it so Ill recommend you read his blog post on the subject which is linked in the show notes.

Theres two important points that I took from all the research I did on salary negotiation:

The most important thing to realise is that you absolutely cant mess it up. If a prospective employer offers you 50,000 per year and you ask for 55,000 and they say no you can STILL TAKE THE 50,000. That offer doesnt explode or go away.

No competent employer is going to think ill of you for asking for more money. The fact is, business people negotiate money all the time. Thats their job. You dont curry any favour by shying away from it. All this means that you pretty much have nothing to lose by asking them to raise their initial offer at least once.

The other thing to realise is that negotiation is easy from a position of strength. For us, that means simultaneously having more than one offer on the table. When you have that you can play the offers off each other in order to raise your price.

Rejection

A word on rejection. While the market for software developers is very good right now, any thorough job hunt is still going to involve dealing with a fair amount of rejection. When youre applying to companies, it can be tempting to think that each rejection is indicative of something you did wrong or an inadequacy in your presentation.

It wasnt until I got involved in hiring that I realised the sheer number of reasons a company might reject a candidate which have nothing to do with the candidate themselves. For example, the company might have just hired some other new people and decided that they need some time to let the dust settle. Or, perhaps just as you were sending your application, word came down from the CEO that the hiring budget needs to be reined in for a month or two.

This is especially true if youre lacking in experience. Its difficult to hire multiple junior developers simultaneously because each one will temporarily reduce the productivity of the more senior guys on the team. Just because they cant take you on right now doesnt mean that the situation wont have changed in 6 months time when the existing new hires are independent.

If youd like to practice your job application techniques were more than happy to review your cover letter and CV at LegitScript. We spend our time building software which helps to shut down illegal online pharmacies on behalf of clients like Microsoft and Google. We are actively hiring and if you visit the link on the slide above youll see a comprehensive description of what were looking for.

I started at LegitScript about 7 months ago and I have to say, its been a fantastic experience so far. I highly recommend it as a place to work.

Thanks for listening.

Continue reading on davidtuite.com