Advice for Software Engineers looking for a job at a Startup

At Haystack and previously Merlin, we’ve been hiring for a number of software engineer roles and in that time I’ve noticed a number of things that some people do that gets them further down the process, even if their engineering chops weren’t as good as others that fell by the wayside. So I wanted to share some advice, for engineers that are looking to get roles in startups, so that you can hopefully get the next job that you’re after.

So… your startup doesn’t have offices yet?

Make your resume for the job you want

I’m always quickly screening people for roles on LinkedIn, AngelList or other platforms. In those few seconds if, for instance, I’m looking for a frontend engineer, I need to see one of 3 terms there (Frontend Engineer, Javascript Engineer or Web Developer), otherwise, I’ll skip.

Decide what role you want next and make sure you phrase your current and previous jobs to reflect that.

For that matter:

• Don’t include jobs that are not relevant i.e. don’t include an IT Admin role (or non-engineering role) if you’re a developer (to me it means that you don’t know the role you want or haven’t devoted your time towards the craft I’m hiring you for)
• Make sure your resume is up to date (I have 3 seconds, and if I don’t know what you’re doing now then I’m probably going to pass)
• Ensure it is consistent across all platforms (given the above, I’ve seen people craft their resume to a job but include a LinkedIn that tells a completely different story).

Do your homework

If you have a first 30-minute call:

• Go to the companies website to understand the product
• LinkedIn stalk the person interviewing you and the CEO
• Come up with 3 questions about the product/company/vision, and at least one piece of feedback you have to make the product better

If you have a 60-minute call or in person:

• If they sent you documents/videos before the interview, make sure you’ve watched/read these a couple of times
• Sign up for a free account (we get notifications about this)
• Try to find blogs (like this) for the people interviewing you to understand what matters to them
• Read through the job description again, any terms or skills you’re unsure about — look them up and see if you can understand some of the key concepts in case you are asked about them.
• Have 5–10 questions lined up about everything to do with the company, product and team. If you aren’t asking questions we think you’re not that into it.

However, in the first interviews (1–3) do not:

• Bring up salary or benefits (people want to hire someone that loves the mission, not the pay packet — even if that is what you are after). However if they put their salary on the job posting/website, that is probably the maximum they are willing to go for the role too.
• Bring down your current/previous employers (this makes it look like you were the problem), if you must then try to remain cool-headed, rationalize where you feel they were going wrong and why this new company you’re applying for seems a better fit.
• Say you are the perfect person for the role. If you are the perfect person that’s fine, but phrase it that this sounds like the perfect role for you — not the other way around. Chances are the person has interviewed a large number of candidates and knows more about the role they are hiring than you do (the job description is only part of what they are after).
• Get the interviewers name wrong — Believe it or not, this has happened a few times. Also don’t shorten them, for instance, call me Charles not, Charlie (it’s not even a shorter name!).

Be on time (early)

If you’re using public transport or driving to the interview, aim to get there 20 minutes early, and then go somewhere nearby.

Why?

If there are problems — you’ll still be on time, and if you arrive really early you immediately annoy the person interviewing you (you’ve taken time away from them and added stress to their day).

Arrive at the door 1-5 minutes early.

Be positive and listen

When you’re in your calls & interviews, try to be upbeat & give a good energy (try to match theirs at least).

When the interviewer is talking make sure you are listening, and try not to interrupt them, chances are they have a spiel they are trying to get through that they have done many times and you saying ‘Oh yeah, that’s like when I did’ is annoying. However, remember what they said and when they are finished try to state experience that matches the problems.

If you have an early morning call, don’t get up 10 minutes before, we can always tell. Give yourself time to wake up!

Follow up

Easiest thing in the world but after an interview, just send a message thanking the interviewers, letting them know that you’re still very much interested and love the product/service.

So many people don’t do this, it’s very refreshing when they do.

You should also do this even if you are going through a recruiter, and you give the recruiter your feedback, a message through them is not as impactful.

What are code/take home assessments actually asking?

If part of the interview process is doing an assessment (you can see an example of ours here), you should think through what they are really asking. For us this is:

• Do you fully understand the question (which for us is, do you get the full problem, including the context of why we are solving it, not just what is listed there)? A good way to think of this is… why would they be asking this question for this role?
• Can you solve the problem (some solution is better than no solution, even if you know there are issues with it)
• How does your code look? (This is something most forget, but I’ll accept well-written code over a better answer — for instance, for Javascript code try to make it OO, use for loops rather than for each, use CAPS for constants, don’t use global variables and don’t use a library, especially jQuery). At least run your code through a linter.
• Do you annotate your code? (So many people get something done quick, but taking 5 minutes to explain your code, makes my job easier and also shows you’re a better developer)
• And linked to annotation is, do you understand the limitations of your solutions? (If you don’t have that much time to solve it, write the solution but explain what you would do with more time)
• Send it in the form they ask for. For instance, we ask people to send us a GitHub Repo, so if you send us HTML/JS files… That’s not what we asked for.

Extra Credit

A few things that can get you even further:

• If you get feedback during your interviews or code assessments — Then write up a better solution or tell us that you read up on the thing you failed in.
• Send thoughts or ideas on the future of the product, show that you’re in it for the long term — though, if the person interviewing wrote the code or designed the solution, be careful not to hurt their feelings by saying something wasn’t very good!
• Find a bug, and fix the bug — Nothing says this person is smart and willing to work hard like solving an issue for a company before you’ve even been hired.

Finally

This is obviously a very subjective decision when it comes to hiring, so this is not a one size fits all set up (i.e. I take no responsibility if the above doesn’t get you a role, though if you do the above I’d be surprised if you didn’t bag a role quickly).

Are you looking for a software role at a startup in New York?

We will very soon! Checkout Haystack (it’ll save you 20 minutes a day) and if you love the tool send me a message and I’d love to interview you!

Good luck out there and if I’ve missed anything please add a comment below and I’ll update this periodically.

Charles Douglas-Osborn

CEO, Haystack