Interview Prep

#pipelinematters
#viewsmyown

First, congrats on the interview!

Landing an interview is a big step. The organization is seriously considering you as a candidate and wants to learn more about you and your experience. If we assume most entry-level positions receive 200+ applications, reaching the interview stage is already a noteworthy milestone.

Now:

Do your research.

Try to find out the org’s interview structure, questions, technical elements. This is the time to let your internet sleuthing research chops shine. Find out:

  • How many rounds are there in the process? Are they with the team, the manager, HR?
  • Are interviews structured as group or individual interviews?
  • Are there any technical exams? Exams are sometimes used as an initial screen.
  • Are there any assignments, case interviews, technical interviews? These may require significant preparation and familiarity to pass. Potential formats:
    1. Take-home: The recruiter asks you to pick a date. Once set, they send you an assignment similar to their work, and you have [X] hours to complete and return it.
    2. Technical interviews: As part of an interview process, the hiring manager either requests you walk through a technical problem live or gives you [X] hours to walk through it on your own, then send or present your analysis to the team.
    3. Case interviews: Typically used in management consulting, these interviews walk through a prospective client interaction designed to test your demeanor and problem-solving/quantitative abilities. If you’re applying for an entry-level role, you may need a couple months to prepare.

Sources of information:

  • Ask/email recruiters about the recruitment process and interview structure.
  • Talk to current and former employees to understand their experience.
  • Look on the company’s LinkedIn page.
  • Look on Glassdoor, likely the most useful online resource for interview questions. Other Q&A boards like Reddit or Quora could also be helpful.*

* As with all information online, take what you find with a grain of salt. Try to confirm through an org contact.

Practice.

In interviewing, (nearly) all practice is good practice.

Interviewing is like any other skill: you get better with practice. You’ll interview over the course of your professional life. The time you invest in improving will come in handy down the line.

Once you have a list of practice interview questions (see below), practice, practice, practice.
Write and speak your responses out loud. Ask your friends, classmates, or family if they’d be willing to conduct a mock interview.

Your responses should:
- be focused, two minutes tops. Don’t ramble.
- be tailored to the org, which shows your prep.
- address their needs for the role. Does the job description say detail-oriented? Give examples showing you’re detail-oriented.
- help you put your best foot forward: prepare to show, not tell, specific examples from your experience to highlight.

Briefcase test.

As much as possible, show off actual work product: papers, projects, or code repos.

  • If you’re a student or recent grad, come prepared with hard copies of one or two papers, printed in color, ideally with calculations or code. The more relevant, the better.
  • In particular:
    • Work vetted through a formal publication process.
    • Work published online by an org you can link to.
    • Papers you’ve received positive feedback on.
    • Online portfolios they can review.
    • Code you’ve posted online, even for a personal or volunteer project.*

* Before posting code online: If you wrote the code for a specific org, find out their policies on making it publicly available. Some places are happy to have you post; others consider it a legal matter, a security risk, or the org’s proprietary IP.

Questions they might ask you

“Tell me about yourself and why you applied for this position.”

  • Nearly 100% chance you’ll be asked this question, so practice answering it.
  • Time your answer to this question. It shouldn’t exceed 2 minutes, which shows your focus and preparation.
  • Understand: “Tell me about yourself” is a shorthand for “Why did you apply to this position, what do you know about us, and what’s prepared you to do this work?” They typically don’t want a chronological narrative; they want to know your motivation for applying to the role and their org. Be specific in your answer.

“Tell me a time when…”

  • These are great questions. They’re designed to understand how you approach your work, what role you play on a team, how you collaborate with others, how you resolve disagreements, how you demonstrate leadership, how you deal with challenges, whether you can teach yourself new skills, whether you’re “teachable” and can take needed guidance/course-correction.
  • Think of a few lessons from each of your prior experiences. You can pull from part-time jobs, internships, or group projects if you haven’t had a full-time job yet. Write out what you learned from each. How have you put your learning into practice? How did you grow from those experiences?
  • Don’t speak in hypotheticals. Give concrete examples.
  • Pay attention to what’s asked: their questions describe the needs, dynamics, and possibly the challenges of the current team.

“Explain [a technical process you’ll use] in plain English.”

  • A lot of technical or specialized work interfaces with roles that don’t share the same expertise, whether across a team, an org, or between an org and its clients. Communication is key to that work.
  • If you have a technical skill-set, interviewers will frequently ask you to explain some part of this work “in plain English,” to a curious audience that doesn’t share your exact expertise.

Questions you might ask them

Interviewing is a two-way street. Any good org should save at least five minutes for you to ask questions. They’re judging you by your questions; try not to ask anything obvious you can easily Google or find out other ways.

Be cautious about asking questions they have hard constraints or sensitivities around answering. You’re unlikely to get good information from their responses, so why ask? Find a better source for that information.

Useful information when considering a potential position:

You owe it to yourself to do your own desk research on these questions, but it could be valuable to get the org’s take on:

The role:

  • What’s this role like day-to-day? Will you be using skills that actively promote your development? Is the work collaborative or individual? How is analyst performance incentivized?
    • IMO, titles are less important than work outputs and skills developed through daily use.
  • What does “success” look like in this role? What would you be expected to achieve at one month, six months, one year? What metrics are used? Is any sample work available?
    • What is the manager’s expectations for this role, are they realistic, and do your expectations for the role align with theirs?
  • Does this role have a typical trajectory? What have previous analysts gone on to do? What training and development opportunities are available?
    • Key here are “typical trajectory” and “previous analysts.” “Development opportunities” are good to hear about but may be hypothetical.

The team:

  • What’s the manager like? What do they value in their employees? How do you think you’ll work together?
  • What’s the team like? Can you get a sense of their dynamic? How is responsibility shared? Does the team share information and resources, or do analysts work in silos?
    • Team intel is key. Easily 60% of your work depends on who you work with.
  • Where does the team sit within the org? How is the team viewed by the org? How is the team’s work utilized by other teams and by leadership? How visible is the team’s work to leadership?

The org:

  • What’s the org like? How does it position itself within its industry? What’s its business model/how does it come by its work? Who are its “clients,” broadly defined?
    • As part of interview prep, can you sketch a rough SWOT analysis to understand how the org sees itself in relation to its environment? How does its future look?
  • Within the org, what skills/outputs are valued? What achievements are considered impressive and rewarded?
    • Incentives tell you a lot about org culture through “revealed preferences,” i.e., what the org actively rewards.
  • Which types of work, positions, teams are seen as “core” or “central” to the business mission, and which are “auxiliary,” nice-to-have but not essential?
    • Orgs frequently value “auxiliary” roles differently: you may have more “sticks” than “carrots”; your effort may be invisible; your position may also be at-risk when the org cuts staff.

Good luck!