Don’t Get Attached, It’s Just Luck

My interviewing advice and tips.

Max Ehnert
13 min readNov 6, 2016

I’ve recently finished my rounds of interviewing for a new job. I applied to dozens, interviewed with about a dozen companies, and accepted 1 job, I guess that makes me qualified to write a blog post about it now. This may not be for the really experienced developer who can walk in and skip the white board or online collab editor. This is for someone who is junior or just out of the junior to experienced level. My background in development, I’m a college drop out with no formal CS training (well I guess I did take intro to programming in university) and I was working for a small web agency in BFE. This was my second development job, the first, a shorter six month contract job. It was an uphill battle to say the least. I’ve only been doing web development for about 2 years, and paid for less than that time. My approach to interviewing is a little different than most it seems after discussing this with other people. I don’t expect it to work for everyone, but I felt it was the best approach for me, so I wanted to share it.

My Approach

My pre-TLDR. High volume applications. Practice the generic questions for your applicable language. Practice the generic questions about your life and why you’re applying. Try to make the (nontechnical part) conversation about them. It’s a crap shoot whether you make it or not so don’t get attached to any one company. Lots of practice and consistent action, with a large serving of luck is the key here.

I relied on Hacker News heavily for sourcing jobs. The position I accepted with Amazon ended up not being a direct result of Hacker News, however I had a much higher interview rate with companies I had direct contact with through HN than applying through company websites, indeed, or third party recruiters. My biggest advice to you is treat it as a numbers game. High volume to hedge your bets. These companies you’re applying to aren’t interviewing just you, they’re interviewing many people and are playing the same game on the opposite side of the table. If you make this about trying to interview at as many places as possible you won’t get attached as easily which makes the rejection easier to stomach and move on from. This is clearly a very emotional thing that is going to expose a lot of your vulnerabilities. It’s important to not make it personal and instead take the rejection in stride, learn from it, but keep moving forward.

When looking for opportunities on HN I filter things by position of course, and I click and open every place that sounds interesting, or is something I would apply for. Then I store the 30–40 tabs in OneTab (browser extension) so I now have an easy to parse list of links I can work through and do not have to worry about losing. I apply in order of relevancy. If the post has a direct email listed those get applied to first. It’s a direct contact and most likely to be actually hiring, not collecting resumes. I also track everything in trello (more on that later) so I can see if I’ve applied to them before and how long ago. If it was at least 6 months ago, then I feel that’s an appropriate amount of time which has passed where you can apply again. If you are applying again go ahead and bring up your previous interview especially if they had you do some kind of take home challenge previously. I recently did that and was able to skip that process this time. As a side note, I no longer do take home challenges. I will cover more on that later.

I also treat it with a sense of urgency. When the new thread appears on the first of the month I start taking down names and sending off emails that day. I’m not sure how much of a difference it makes, but I want to at least get in line for that first call ahead of everyone else. I want them to see my great cover letter right away so they will be less impressed by all the one liners people will be sending in after me. I try to get all of my applications done in the first 2–3 days of the month so I can go back to focusing on interview prep. This also has the benefit of setting up multiple interviews during a short period of time.

Cover Letter

I have a few cover letter templates I choose from then personalize it to the company. The cover letter here unlike most applications is very important. This is a direct contact with someone who is likely another developer or project manager/ hiring manager. Sound excited and try to sell yourself on things they are looking for. Spend 10 minutes reading through their site if you aren’t familiar with their product and mention a few of the things you like the most about it in the cover letter. I’ve had great success with this method. In fact this post from a recent HN discussion about Who’s Hiring threads was written by a hiring manager who says often the emails he received were very short and gave little motivation for him to respond. At the bottom of the cover letter below my name I always include links to my portfolio, github, linkedin, and attach the resume. You want to make it as easy as possible for them to get the information they need out of you.

Now you might be thinking, if I use your high volume approach, how much time am I going to spend writing cover letters for places I may never hear from again. Well you need to stop that attitude first before you go any further with your job hunt. Look at everything as practice. It’s all practice that is going to make you incrementally better which will eventually land you a job. I didn’t start with 4 cover letter templates. I started with none. As I wrote more and more cover letters, tweaking them each time I would save it if I thought it was good and could reuse it. Then I had a good base for the next one. See how in the beginning it will be a slow process, but you will get faster and better at it as time passes. Now if you knock out 30 applications, it’s going to be really easy to do 10 or 20 more since you’ve got a flow going by then.

Resume

I also have multiple resumes. I had 2 different resumes I used with callback success on each so I cannot decide which was the better approach however I did get some feedback on this topic from an internal recruiter at Amazon. The two resumes I used were, one which was short, a single page and only included my web development experience and side projects, the other was two pages and included my full work history (I’m in my late 20s and have worked some interesting jobs before doing web development). I was told to use the longer resume as it tells a better story, YMMV of course.

Tracking

Keep track of everything you do. I use trello to mark places I have applied to, interviewed with, and rejected from. Then notes on each one for interview details, questions they ask, who I spoke with, etc. I also keep my resumes and cover letters here. Additionally have a good set of STAR questions ready and memorized. You’ll need more than just programming answers as well. Things like behavioral questions. Tell me a time when you disagreed with a manager… those types of questions that we all hate, but you MUST know them and be familiar with them. I’ve had small and large companies ask them. Usually not until the on site but you never know if an HR phone screen might throw one of those in there.

Now I know what you’re probably thinking at this point. Why do you need to apply to so many places? Shouldn’t you only apply to places to really want to work at? No. You need practice. You are not good at interviewing. You will absolutely mess up simple questions and topics while you go through these interviews. It’s all about luck. Some companies won’t care that your syntax was off a little, or you wrote out the general solution but couldn’t remember the exact method to call for a specific part. Some places will reject you even if you get everything right but don’t do it the way the interviewer knows. It’s a crap shoot and that’s why you must hedge your bets on high volume.

If you have some super wish list of companies you want to work for, wait a couple weeks to apply to them and start with other places that you wouldn’t mind working for, but aren’t on your top 10. This will give you time to iron out your cover letter, phone intros/ conversations (yes that is really really important, be personable, think ‘fake it till you make it’ if you need), and general technical question trivia. Now you have a contingency plan if you get rejected by all your top companies. Most companies ask really similar questions especially the first phone screen question. In the end make this all about data and as analytical as you can. You want to minimize the emotional attachment you will naturally feel when applying and interviewing. I know this sounds odd or maybe wrong, but I promise you, it will save a lot of heart ache when you open your email and see that rejection email because you’re going to get a lot of them.

First Call

This one is usually with the HR or internal recruiter who wants to know why you’re interviewing/ leaving your company. They also want to know about what you do now and what you did before going back as far as you keep talking usually (This is your time, you control it, you control what they know, use this to your advantage), then they will bang off a few generic technical questions from a list. In my case that’s front end web development questions. Things like knowing the box model, closures, map/filter/reduce, object vs array, prototypes, bind/call/apply, event delegation. These made up almost every single first phone screen interview I’ve ever had. Not only do you need to know all these, but for this call, you need to know the dictionary definitions basically. These people usually aren’t technical and are just looking for keywords. They will however probably come up again in later more technical interview so you really need to know them.

It’s often hard to talk about yourself and to come off as gloating about what you’ve done, but you really need to sell yourself here. This is where you set the hook, with the non technical recruiter. If you’re nervous or short with answers you aren’t giving them much to work with. This is why you need practice. After a few interviews you’ll be so sick of answering the same questions over and over again you’ll be spitting them out loud and proud.

A few of the questions that come up often, Why are you leaving X? What have you worked on/done at X? What are you looking for now? What kind of technologies have you worked with? Prepare for follow up questions to anything you talk about.

Now that you nailed that one it’s time for the technical interview.

Remember it’s a crap shoot here. As long as you know your stuff that’s all you can do. I’ve done great at the technical and gotten passed up and done just ok to slightly doing bad and still gotten a follow up interview, I’ve also bombed a lot of them, no such luck on follow up interviews with those.

Before you jump into the technical questions or programming, they’re going to start by asking you many of the same questions you answered the last time you spoke with them. Questions about your work history, what you’re looking for, why you’re leaving, etc. Like I mentioned earlier you will get very comfortable answering these questions because they come up time after time. You will learn to tweak them and change it up based on who you’re talking to and what you’re interviewing for. I answer things a little differently talking to huge companies compared to small startups because the challenges these companies face are different. Play into what you think they want to hear, but you know still be honest.

The technical questions you get asked can cover such a huge breadth of knowledge it’s hard to prepare. I can really only speak to front end interviews, and for those, know as many js methods as you can. Weird obscure ones come up all the time. Go in the Mozilla docs and read through the lists on Objects and Arrays and practice any methods you don’t know or understand until you do know them. Of course you also need to be intimately familiar with all the common types of loops and their use cases. If you’re using a for..in loop on an array that will throw a red flag for your interviewer. For a phone screen I’ve never been asked a typical data structure/ algo question. Binary search trees and linked lists are really cool and I implore you to learn them if you don’t, but you won’t see that in a phone interview. At least from my experience, however like I said earlier, it’s a crap shoot. You have no idea what’s around the corner. I’ve also had some places ask only prototype related questions and others that were heavy on DOM interaction and CSS styling questions. At the very least, know this repo top to bottom. Some places rip their interviews right from this list. https://github.com/h5bp/Front-end-Developer-Interview-Questions

After the first technical interview it’s all in the air for what comes next. Some places do another phone/ online tech interview, others go to the on site here. Either way, expect new questions that are going to be tangentially related to the previous interview. The next person likely works with the previous interviewer and they ask similar questions because they discuss how to interview for candidates beforehand. If it was really heavy on js keep practicing those same types of questions and don’t sweat CSS as much. Remember it’s all a game, and you need to figure out their strategy.

When it comes to coding tests there are patterns to most questions that will become obvious with practice. If you need to find a single value, try to start with a binary search, if you need to find/ do something with multiple values store them in an object. That’s 90% of the questions. The complexity comes down to how you loop through the string/object/array. Be comfortable with all these. I’ve never been asked about big O in a phone interview so don’t sweat trying to make the fastest solution. Most candidates likely aren’t even getting a correct solution so just try to get something working, then go back if there’s time and make it better. From what I’ve found, and I might just be slow, is that your one hour interview goes really fast and there isn’t time to make things pretty and optimized anyways. Or I might just be a really bad programmer so don’t count that out either.

After the technical questions it’s your chance to ask questions.

When it comes time to ask questions at the end of the interview you had better have some questions to ask. I always start with the generic questions about team size, QA, agile, but if you’re good you can get them talking about something they enjoy. Try to connect with something they mentioned when they introduced themselves at the beginning of the interview. If you can get them talking instead they’ll leave the interview with a better impression of you without realizing how much talking they did. It’s kind of like when you sit and there and ramble off to someone and afterwards think about what a great conversation you had with them. It’s these small subtle things that might give you a little edge over other people. Saying you don’t have any questions though on the first couple interviews looks bad and gives a bad impression. By the third or so interview with a company I usually don’t have any more to ask so I like to dig for something about the interviewer. If nothing else just revert back to the list of prepared questions you have and ask a few even if you already asked a different interviewer.

Take home quizzes

I mentioned earlier that I no longer do these. I didn’t always feel this way. In fact I used to prefer them to the technical questions. However that was ultimately because my actual skills were lacking and I preferred the take home to mask that. Well it didn’t work very well either. You will at some point during the interview process have to live code. You will need to practice this regardless. I also found that even though they say it should only take 4 hours to complete I’d often spend 2–3x more than that working on it and more often than not get nothing in return but a generic rejection email. This simply does not scale for applicants. If you want to take the high volume approach you do not have time, even 4 hours to spend on one company. Unless this place is on your dream list, top 10, whatever list then don’t waste you time. Simple reply to them asking if you can take a phone screen instead and if you want explain that take homes do not scale for interviewers. They are purposefully shifting the workload to interviewers to save their own company time from interviewing applicants.

At the end of the day as long as you really do know what you’re doing, you’re going to get an offer from someone. In that process you’re going to get rejected by a lot of companies and you have to remember that’s ok. You have no idea what they’re really looking for so try not to get emotionally attached to any company or application. Take notes and learn from your mistakes. Didn’t know the answer to the technical question? Write it down right away and study it later. Keep practicing your general/ behavioral answers until it sounds smooth and you can say it without pausing and saying ‘uhhhh’ over and over again. Try to have fun with the interview. Get yourself hyped up so you have a lot of energy on the call. I’ve had much better luck (all ancedata of course) when I was wide awake, talking energetically, and was able to joke about myself or just smile while talking. Give the interviewer a reason to be excited about talking to you. Remember you aren’t a snowflake and they have no reason to like you unless you show them one.

Now since you aren’t a 10x programmer, rockstar, whatever buzzword name, you’re going to go through this process a lot, incrementally getting better. After lots of rejections you will start getting offers, without even realizing it you will be getting much smoother and quicker at these interviews and it will be apparent to the interviewer. I felt like my knowledge increased dramatically while interviewing because not only of how much I was studying and but also because I had so much live practice with these companies. It exposed many of my short comings and I was able to address them before the next interview. Like I mentioned in the beginning of this, you are going to start out terrible at interviewing. That’s why it has to be a high volume task. When I go into ‘interviewing mode’ I stop working on side projects, I stop visiting bs sites like reddit, news sites, and even HN. If it isn’t going to help you get that job just cut it from your life. Focus intensely on learning and writing job applications until you get there. This process isn’t fun, why drag it out any longer than you need to.

--

--