By Chow Lin

At Noom, transparency is super-important, both applied to our users and ourselves.  In that spirit, this article is about leveling the playing field when it comes to applications and interviews; when we have you on the phone or on-site, we want you performing at your best with maximum awareness of what’s going on.  So, having been through several hundred interviews on both sides of the table, in addition to numerous resume review sessions and hiring committee meetings, I figured I’d share some of my thoughts to help potential candidates do better on our interviews (you can probably apply most of these to Google and Facebook interviews too).

It’s important to first understand what the interviewer is thinking and what the company is thinking.  Then I’ll spend some time talking about the different parts of the hiring process, go over who we’re trying to find (and why) and ways to maximize your chances of success.  A core assumption here is that your goal is to find an awesome job that you will love, and to get there, you are trying to get multiple job offers from many companies.  Similarly, we’re trying to find awesome engineers and CS folks who are smart enough to get job offers from multiple companies and then choose us because they think it’s the best match.
The Employer’s Perspective
The absolute most important thing for a startup is to find the right people.  We have a hiring target, but it’s intentionally soft:  if we find someone absolutely brilliant, we will try really hard to convince them to join us; if we don’t find anybody, then we don’t hire anybody.  This is really important: companies that have rigid hiring quotas will eventually start making more and more bad hiring decisions.

From our perspective, hiring is like finding a needle in a haystack: for every amazing engineer out there who’s a good fit for our company, there are a lot of other amazing engineers who are not a good fit right now, and even more folks who just wouldn’t fit in here at all.  There is a very low signal to noise ratio, and we need to figure out how to find the best people and provide them with an amazing interview experience while minimizing the false-positive rate, the false-negative rate, and the amount of time we spend recruiting and not directly building stuff.  To make this even more interesting, we have very limited data to go on: resumes, phone interviews, and on-site interviews, each with their own pros and cons.
The Resume
A resume cannot tell me whether you’re a good engineer, but it gives me a hint that you are, and in that case I want to talk to you and learn more.  The most important things on the resume are the things that are the hardest to do (that’s why they stand out):

• Who did you work for?  If you worked at Google, Facebook, or any of the other places that our team members have worked in the past, we get an idea of the performance level you’ve put out in the past–and it takes us all of five minutes to call up our friends to find out how awesome you were.
• Did you code something?  A github or bitbucket link is very helpful, as well as mention of an Android or iOS app you’ve built.
• If you just graduated, how awesome is your transcript?  Getting straight A’s takes some serious hard work and dedication, and choosing hard courses means you’re not interested in taking the easy way out.  We’ll usually try to find someone here who went to your school to give us the right context.

As an employer, we’re trying to figure out how good you really are.  Instead of worrying about the format of the resume, or writing a super-polished cover letter, simply focus on highlighting the parts of your experience and education that show your technical ability and your achievements. And if you’re not looking for a new job now, but you wonder how you can grow your career and get better opportunities, think about side projects and learning new skills. For instance, contributing code to Chromium will always be more impressive than a cover letter by a couple of orders of magnitude.

The Phone Interview
A phone interview gives us and you more information at the cost of time.  This part of the process is a two-way conversation; so while we’re trying to figure out if you’re smart and are a solid coder, you should be trying to answer very similar questions, “Do I want to work with this person?  Is the person I’m speaking to pretty smart?  Are they doing something awesome that I care about?  And will I actually have an opportunity to make an important contribution?”

Despite what you might have heard, every good interviewer wants their candidate to do well: the most exciting interviews are the ones where the conversation leaves the context of an interview and turns into a broader discussion where both the interviewer and interviewee are learning something interesting.  The goal of interviewing is to find someone who would be a great addition to the team; ideally, this person blows away all of my questions and does it with grace and style.

A couple of things to keep in mind while you’re interviewing:

• Relax.  The interviewer is on your side.  Really.
• Getting stuck is okay; just think your way out of it.  Ask questions, throw ideas out there, or ask for a hint.  I want to see that you can think through problems.  The worst thing to do is to get stuck in the silent death spiral where you start beating yourself up for not getting it.
• Be ready to do some coding.  This will probably be over Google Docs or CollabEdit.  Practice a couple of questions (perhaps off Project Euler) to make sure you have the hang of coding on the fly.  Also, be ready to use a language you’re really comfortable with.
• Structure your thoughts.  The least successful candidates are the ones that start coding before I’ve finished telling them the (intentionally vague) question, or the ones that think it’s so simple they don’t see the hidden complexity.
• Timing is important.  For a coding question, expect to use up some time clarifying the problem and coming up with different approaches; then you need to analyze tradeoffs and decide on a solution that you will code; then you need to code and debug.  Great candidates will do all of this in the first 25-30 minutes; the best are even faster.
• Be aware of what mode you’re in: you usually begin in a sort of brainstormy mode, then you’re in analysis and decision-making mode, then coding mode, then if you make it that far, you’re back in brainstorming mode–be ready for the interviewer to throw a big twist in the problem that makes it ridiculously complex or difficult (like scale your solution to a couple of petabytes with 1 MB of RAM).  In brainstorming mode, I’m trying to get a sense of the breadth of your knowledge and experience; I’d like to see a bunch of reasonable choices presented, and the logic for why one is better than the others. Once you have an idea solidified, we’re in coding mode, and it’s all about rapid execution.
• Don’t be a jerk; you’re being evaluated on culture fit too, and nobody wants to work with a jerk.  Conversely, if your interviewer is a jerk, rethink whether or not you want to work with them.

Some folks do interview prep sessions.  This is generally a very good idea; you want to be focused on solving problems, not on the mechanics of the interview when you get in there.  Leading interview prep sessions, in addition to earning serious karma with your friends, will strengthen your skills even more.

On-Site Interviews
On-site interviews give you the best information possible prior to the hiring decision.  These will typically involve multiple interviews and lots of coding.  Wear something you’ll be comfortable in.  Once again, talent and ability are the most important things; there’s not much of a correlation between what you’re wearing and how awesome you are, so wear something that doesn’t get in the way or make you feel nervous.  If you’re wearing a suit that you don’t wear on a daily basis, you’re already putting yourself at a disadvantage.

One great aspect of on-site interviews is that you can get an unfiltered look at the reality of the workplace.  You have a great opportunity to see what the space is like, how everyone is treated, how people interact with each other, and if engineers are rock stars or just a cost center.  Make good use of the time in between interviews–it can give you a really good feel for the way things really are: is it too quiet in here?  is some poor engineer getting yelled at by a manager in front of all of their peers?  Red flag.  In addition to questions like, “What is a typical day like?” you should also ask hard questions like, “Tell me about your worst day ever.”  It’s even better if you have a chance (say over lunch) to talk to people that aren’t on your interview slate; they’re less likely to have a rehearsed answer.

Post-Interview
Different companies have different processes for making the actual hiring decision.  We look at all of the independent pieces of feedback coming from all of the interviewers, try to throw out the outliers, and make a hire/no-hire decision.  Then, everyone in the company gets a veto (don’t be a jerk to someone you didn’t think was important–everyone here is important and we only want people that share that mindset).  Assuming you made it, we try to come up with a compensation package that is insanely awesome and takes into account the risk factor and growth rates associated with a startup (translation:  it’ll probably be equity-heavy, but if we make it, you’ll be many times wealthier than if you went to an established company).  We try really hard to make sure that we’re your best option, and we encourage our candidates to get job offers from other companies so they know they’re getting a good deal.

That said, you need to be aware of your risk preferences when you’re trying to decide between a startup and an established company.  Every company spends quite a bit of effort keeping track of what everyone else is paying, and the typical startup offer will typically have more equity and less cash than an offer from a big company.  So how do you compare them?  Part of it, unfortunately, needs to be decided on limited data: you need to have your own estimate of how fast each company will grow and what the risk factors are; then, you can do an expected value calculation.  Generally, because of the risk involved in startups, the equity should be big enough to give you a multiple of what you’d expect from an established player.

Exploding Offers
A small note about exploding offers (because you can find better details on Joel’s blog):  we will never, ever, make you an exploding offer.  Some of the terms might change over time (obviously if you defer an offer for a year, our stock price is going to be pretty different), but we’ll never say something like, “You need to decide before your interview with X, or the offer disappears” (unlike some others).  If you find yourself faced with an exploding offer, first consider whether you really want to work for this employer.  Then, if you’re thinking you need a fallback, you can always accept the offer and continue interviewing; most contracts are for at-will employment, so you can walk away from it at any time (including before your first day of work).  Your career is super important, so don’t let a sketchy employer force you into a sub-optimal choice.

Who We’re Trying To Hire (And Why)
A lot of people have many misconceptions about startups.  Amongst these is the idea that because startups are a great place to learn a lot of stuff really quickly, they have a lower hiring bar than large companies.  The reality is that we’re okay with less experience, as long as there’s a high amount of raw talent (ie. ridiculously smart).  Because of how quickly things change at a startup, we need amazing engineers who can learn new technologies rapidly, take initiative, exhibit good judgment, get things done, and write good code that doesn’t slow down other engineers.  This sounds like familiar recruiting spiel, but at a startup, when you’re ~1/10th of the company, you can be the difference between a successful company and a smoking crater–so these are all very important to us.

Because we’re expecting to grow rapidly, and early engineers will eventually be leaders of important efforts, we look for a pretty specific set of skills:

• Good Technical Judgment:  Essentially, there are a lot of folks who can write really hacky code really quickly that will slow down the rest of the team, and there are people who spend so much time improving it that they never actually deliver anything.  We need someone who can make the right judgment call on where that balance is.  This is the hardest to gauge in an interview: speed is a bit of an indicator, but it’s really hard to answer, “A month down the road, will you be making the most effective use of your time?”
• Initiative: We need people that are curious about things, always trying out new ideas, not afraid of failure, and willing to settle arguments by finding data or building prototypes.
• Gets Things Done: There are a lot of brilliant people who get stuck in the world of theory and never produce anything; that’s great for them, but it’s a fatal attribute at a startup.
• Good Code: We need folks who can find optimally fast and memory-efficient solutions and express those solutions in clean, elegant code that’s easily readable.

Everyone is looking for these attributes, and most companies will settle for a subset of these skills; but because of our size, everyone wears a lot of hats, so we really need all of them.  In our experience, only a small subset of people that are successful in established companies would be successful in a startup environment; the converse is often-times true as well: people that work well in startups usually have a hard time with the bureaucracy and slower pace of established companies.
Summary/Why You Should Come to Noom
In the end, after acing the technical parts of the interview, you’ll need to decide on which group of people you want to work with.  This is a very personal thing and hopefully you’ve used your interview time to gather enough information about the various companies.  Using that information to decide which is the best fit is still tough.  If you’re still in school while you’re reading this, doing short internships at a company is the absolute best way to gather information about them.  If not, at least have a mental checklist of the things you’d like to see in the first month to validate that it was the right choice.

Shameless plug:  if you’re looking for a company that believes that its people are its most important assets, cares a lot about its culture, and is focused on validated learning, democratic processes, and individual growth, come to Noom.

And regardless of which company you go with, make sure you’re doing something that makes you happy.  Good luck out there!