The Curious Candidate Gets the Job

Remember the last time you were looking for a job… A job search can be a stressful experience, whether or not things are going well. It’s hard not to agonize about things you could have said in your last interview, problems you could have solved, how you could have prepared better, etc. I’ve really enjoyed my multi-week job search extravaganza (see note at the beginning of my first post), and a large aspect of that has been to keep the following in mind:

Be curious!

A job search is an opportunity to learn about people, companies, and yourself. I firmly believe that treating it as such is not just a luxury for those of us lucky enough to be confident that they’ll get a job. It actually makes you a better candidate by helping you prepare better, be more engaged throughout the interview, and improve for the next interview.


Think about the company. Poke around their website. What’s cool about what they’re doing? What’s cool about what you might get to do if you worked there? What are their unique advantages? What challenges might they have? Are there things about the technology or the business that you don’t understand?

At the interview: Ask questions you’re genuinely interested in.

You probably thought of questions you’re curious about while you were preparing for the interview. More questions will come up if you engage with what you’re hearing when you’re there. Pull on the threads that seem important, and get multiple perspectives. Here are some things you might be curious to learn.

  • Maybe you’re trying to imagine yourself working on the team. What would affect your experience? Projects, organizational structure, tech talks, culture, …?
  • Maybe you’re talking to a manager. Are there things you want to know about the overall direction for the company, and how the team you’re interviewing with fits in that picture?
  • Do you want to know how your interviewer decided to join this company, and whether they encountered any surprises?
  • Maybe you’ve already decided you’re unlikely to join the company. You still have a unique opportunity to learn how things work around here.

By the way, if you get an offer, you’ll almost certainly get a chance to talk to more people. It would be reasonable to leave the more down-in-the-weeds questions until then.

After the interview: Agonize productively

If you’re like me, after an interview, you’re likely to be agonizing about all the things you could’ve done better. You can make that productive rather than miserable.

  • Were there things you didn’t know that you should have known, or would like to know? Go out and learn them! My interviews have caused me to go through the Django tutorial, review the math behind SVMs, read up on Spark, etc.
  • Were there interactions you can handle better next time? I had an interview where I rushed to code up a solution without first making sure the interviewer and I were on the same page about the right approach. I’ll be sure to watch out for that temptation in the future.

Positive attitude

Being curious will make your job search a less stressful experience, which will make you more effective. If you go into an interview thinking of it as a learning opportunity, and the interview doesn’t go well, at least you still learned something!

Why Companies Write Terrible Job Posts

Are you ready to “demonstrate an understanding of the interplay between physics-based signal and image analysis and text summarization and interpretation analysis”? I know I am!

The goal of a job posting is to solicit applications from qualified candidates. In that light, compare the following two job postings.

The classic:


The modern:


Are you psyched to work in a group where, “Technical disciplines required include machine-assisted information fusion methods based upon physical, statistical and graphical models, as well as the software engineering skills to deploy them in open, distributed and service-oriented, cloud-based systems”? I worked in that group, and it was a great experience, but you’d never know it from the job post. A place where, “They banter about Bandits, know their way down a Gradient, and aren’t too Naïve to kick back in our Bay(es) Area offices,” sounds quite a bit more fun.

The author of the classic job posting above never stopped to consider the objective: getting qualified candidates to apply. They got the qualified part — the job posting does specify what qualifications are required (cropped out above). What they forgot about is the get candidates to apply part. A job posting is not just a description of requirements — it’s an advertisement. The young tech companies seem to have figured that out, but this bit of wisdom hasn’t permeated parts of the established corporate world. A few minutes of browsing revealed the following gems:

“You will perform professional software development tasks associated with the developing, designing and debugging of software applications or operating systems.” — Software Developer 5 at Oracle

“The main responsibilities of the developer include quickly diagnosing and resolving defects associated with moderately complex to complex intranet applications.” — Web Developer 5 at Wells Fargo

How do such awful job postings come to be? Here are some thoughts:

  • Internal vs. external: A company needs to have a concept of why it’s hiring and what the specific requirements for the role are. What we’re seeing here is just an internal spec sheet that hasn’t been translated into a sales pitch. At Oracle, job postings actually double as internal promotion/transfer opportunities.
  • Image: A Silicon Valley tech company like Yelp (modern job posting) isn’t expected to sound professional, but a government laboratory in Massachusetts (classic job posting) is. The same way a candidate can’t show up to a consulting interview in jeans, a “serious” organization will not create a punnish job ad.
  • Generic requirements: It’s hard to write a good job posting when the requirements are too general. In the case of the classic job posting above, the group is essentially looking for smart technical people, and does not want to discourage a broad set of potential applicants. At large companies like Oracle, while the job requirements might be specific, much of the text for a job posting is standard and was not written with a particular role in mind. The unfortunate consequence is that the job ads suffer from at least one of two flaws:
    • Phrases that are so general that they are meaningless, e.g., “professional software development tasks associated with the developing… of software applications.”
    • Long, convoluted lists of possibilities, e.g., “Projects involve feature extraction from multi-source data; pattern recognition and behavior analysis; information-theoretic analysis of machine-aided decision effectiveness; semi-automated sensor cueing and resource optimization; modeling and simulation of surveillance and reconnaissance networks; design, implementation and analysis of laboratory and field experiments.”
  • Lack of perspective: Having stewed in company-internal lingo for a while, it’s hard to step back and remember just how obtuse it sounds to an outsider.

Have you come across job postings that are about as dynamic as a software license agreement? Please comment!

The Interview Process: What a Company Wants

I have just finished a more extensive tech job search than anyone should really do. It featured eight on-sites, along with countless phone screens and informal chats. There were a few reasons why I ended up doing things this way: (a) I quit my job when my husband and I moved from Boston to San Francisco a few months ago, so I had the time; (b) I wasn’t sure what I was looking for — big company vs. small, data scientist vs. software engineer on a machine learning system, etc.; (c) I wasn’t sure how well it would all go. 

This way of doing a job search turned out to be an awesome learning experience. In this series of posts, I’ve tried to jot down some thoughts on what makes for a good interview process, both for the company and for the candidate. I was interviewing for a combination of data science and software engineering positions, but many observations should be more broadly applicable.

What are we trying to do here, anyway?

Before we can talk about what is a good or bad interview process, we need to understand the company’s objectives. Here are some things your company might be trying to do, or perhaps should be trying to do. Note that I’m focusing on the interview stage here; there are many separate questions about finding/filtering candidates.

Hire or no hire: Decide whether to give the candidate an offer. 

  1. Qualification check: Figure out whether the candidate is qualified for the position they applied for. This is the most basic objective of the interview process. To check someone’s qualifications, you first need to define what it means to be qualified for the position. In addition to technical skills, many companies look for a “culture fit”, which can help maintain the work and social environment at the company — or change it, if that’s what’s needed.
  2. Potential check: If the candidate isn’t qualified right now, can they become excellent at this job anyway? Companies have very different philosophies on whether this is a question they care to ask. In many cases, there are good reasons to ask it. I was told a story about someone who was hired as a machine learning expert, but soon got excited about infrastructure challenges, and before long became the head of an infrastructure team. At that point, what does it matter precisely what set of skills he originally came in with, as long as he’s smart and capable of learning new things?
  3. Opportunity check: If the candidate isn’t ideally suited to the position they applied for, are there other roles in the company where we’d love to have them? More than one place I interviewed at came back with an offer for a different role from the one I applied for (in my case, “data scientist” instead of “engineer”). They weren’t advertising for that job, but they were thinking opportunistically.

Leave a good impression.

There are two major components to this.

  1. Be cool: Make sure the candidate comes away with a positive view of the company. Part of doing this effectively is figuring out what counts as “cool” to this particular candidate.
  2. Be nice: Make sure the candidate has a positive overall experience.

Doing this well has an obvious benefit when the candidate is qualified: they’ll be more likely to take the offer. But it also has some less obvious benefits that apply to all candidates:

  • The candidate will be more likely to refer friends to your company. I heard about a candidate who was rejected but went on to recommend two friends who ended up joining the company.
  • The candidate will be more positive when discussing your company with their friends. It’s a small world.
  • Even if you don’t want to hire the candidate right now, you might want to hire them in a year.
  • There is intrinsic merit in being nice to people as they’re going through what is often a stressful experience.

Feel good doing it: Make sure the interviewers have a positive interview experience.

As someone on the other side of the fence, this one is harder for me to reason about. But here are some thoughts on why this is important:

  • Your employees might be spending a lot of time interviewing (as much as 10 hours a week during the fall recruiting season), and you don’t want them to be miserable doing it.
  • If the interviewer is grumpy, the candidate will be less likely to think well of the company (see above). One of the companies I interviewed at requires interviewers to submit detailed written feedback, which resulted in them dedicating much of their attention to typing up my whiteboard code during the interview. More than one interviewer expressed their frustration with the process. Even if they were pretty happy with their job most of the time, it certainly didn’t come across that way.
In the next post, I’ll take a look at some job postings. Do you have thoughts on other goals companies should strive for? Please comment!k