BootcampInterview prep

Interview Drills — Recruiting Knowledge / Domain Fluency

6 drills with frameworks and rubrics.

Interview Drills — Recruiting Knowledge / Domain Fluency

Open-ended interview questions that test whether you can talk credibly about recruiting itself — the lifecycle and funnel, ATS and sourcing tools, the core metrics and how to read them, in-house vs. agency, and enough tech-role literacy to hold your own with engineers. Each has a Framework (the structure a strong answer follows), a Model answer (a concise example), and a Rubric (what an interviewer listens for). Practice thinking aloud, name each concept by its real term, and back claims with a number or a concrete example. The app can role-play these as mock interviews (see mock-interview.md).

The universal domain-fluency structure: Define the term in one line → place it in the funnel/lifecycle → say what good vs. bad looks like (a number or a signal) → say what you'd do about it. Use it on almost any "what is X / how would you read X" question.

D1

  • difficulty: easy
  • concept: recruitment-lifecycle Walk me through the recruitment lifecycle from an open role to a signed offer.
  • Framework: Name the stages in order → frame it as a funnel with drop-off → say what the recruiter owns at each step → end with the recruiter's role as the coordinator. Stages: intake → sourcing → screening → interviews → selection → offer/negotiation → closing/handoff.
  • Model answer: "It starts with intake — I meet the hiring manager to nail the true must-haves. Then sourcing (proactively finding candidates, mostly on LinkedIn plus referrals), screening (my recruiter call for fit and interest), interviews (the hiring team, often a few rounds), selection (synthesizing feedback into a decision), offer and negotiation, and closing plus handoff to People Ops for onboarding. It's a funnel — many enter at sourcing, few reach offer — so I keep a wide top and keep it moving fast so good people don't go cold. Throughout, I'm the conductor: scheduling, chasing feedback, and being the candidate's main point of contact."
  • Rubric: Strong answers name the stages in the right order, explicitly call it a funnel with drop-off, and describe the recruiter as the active coordinator (not a passive resume-collector). Bonus for naming speed and pipeline health. Weak answers skip or reorder stages, or describe recruiting as just posting a job and waiting for applicants.

D2

  • difficulty: medium
  • concept: funnel-metrics Our time-to-hire on a backend role has crept up to 70 days. How would you diagnose and fix it?
  • Framework: Clarify the metric (where the clock starts and stops) → decompose the funnel and find where the days accumulate (the leak) → form a hypothesis per likely culprit (top-of-funnel, screen-to-onsite, feedback lag, offer stage) → propose a targeted fix → name the metric that confirms it improved.
  • Model answer: "First I'd confirm what time-to-hire counts here — usually req-open to offer-accept. Then I'd look at stage-by-stage conversion and time-in-stage rather than the 70 as one number. If candidates pile up before the first interview, it's a sourcing or response-rate problem — I'd tighten outreach and my Boolean searches. If they pile up between interview and decision, it's usually feedback lag from the hiring team — I'd set a 48-hour feedback SLA and batch interviews onto one day. If it's the offer stage, comp or closing is the issue. I'd fix the biggest leak first and watch time-in-stage and stage conversion to confirm it dropped."
  • Rubric: Strong answers refuse to treat time-to-hire as one blob — they decompose it by stage to locate the leak, then match the fix to the specific stage and name a confirming metric. Bonus for the feedback-SLA insight (the most common real-world culprit). Weak answers jump to a generic "source more candidates" with no diagnosis, or blame candidates rather than the process.

D3

  • difficulty: medium
  • concept: quality-vs-speed-metrics A recruiter brags about a very low time-to-hire. Why might that be a red flag, and what other metrics would you check?
  • Framework: Grant that speed is genuinely valuable → name the tension: speed optimized in isolation can hurt the outcome → introduce quality-of-hire (plus offer-acceptance) as the counterbalance → explain how you'd read them together → land on "data-informed, not data-obsessed."
  • Model answer: "Speed matters — top candidates have options and go cold in a slow process. But time-to-hire alone is a vanity metric if it came from lowering the bar or pushing the first warm body through. The metric that keeps it honest is quality-of-hire — do these hires actually perform and stay (say, 6- and 12-month performance and retention)? I'd also check offer-acceptance rate: a fast process that nobody accepts isn't fast, it's churning. The right read is the pair together — fast and good hires who stick. Metrics serve the goal, which is great matches, not a leaderboard number."
  • Rubric: Strong answers identify the speed-vs-quality tension, name quality-of-hire as the corrective (and ideally offer-acceptance), and articulate reading metrics together rather than in isolation. Weak answers either defend speed uncritically or just say "quality matters" without naming the actual metric or how they'd measure it (retention/performance over time).

D4

  • difficulty: medium
  • concept: tech-role-literacy A hiring manager asks for a "senior full-stack engineer." Before you start sourcing, what do you want to understand — and how do you show you know the role?
  • Framework: Translate the title into concrete tech (what full-stack actually means) → pin down seniority and what it implies for targeting and comp → separate true must-haves from nice-to-haves with the hiring manager → show you'd search by skills, not just the title.
  • Model answer: "Full-stack means both frontend (the user-facing side — say React) and backend (servers and logic — say Node or Python), so I'd confirm the actual stack rather than assume it. 'Senior' signals someone experienced and independent, which sets both who I target and the salary band, so I'd confirm the level and budget. Then the key conversation: of the listed requirements, which are true must-haves versus wish-list nice-to-haves? Job specs are usually wish-lists and few candidates tick every box, so locking the real must-haves widens the pool to the right people. I'd then source by skills and experience with a Boolean search, not just the title, since titles vary by company."
  • Rubric: Strong answers decode the role into real technologies, treat seniority as driving targeting and comp, and explicitly push to separate must-haves from nice-to-haves rather than keyword-matching the spec. Bonus for "search by skills, not titles." Weak answers parrot the job title back, treat every listed requirement as mandatory, or show no real understanding of what the role does.

D5

  • difficulty: medium
  • concept: tools-and-sourcing What tools would you expect to use day to day, and how does an ATS differ from LinkedIn Recruiter?
  • Framework: Name the tool categories (not just brands) → explain the ATS's job in the pipeline → explain LinkedIn's job in sourcing → make the contrast explicit (system of record vs. sourcing engine) → note that tools support the craft, they don't replace it.
  • Model answer: "The ATS is the system of record — Greenhouse, Lever, Ashby, Workday — it stores every candidate, moves them through the pipeline stages, and holds notes and feedback so nobody falls through the cracks; it's my equivalent of the analyst's spreadsheet. LinkedIn Recruiter is the opposite end: a sourcing engine for finding people who aren't in my pipeline yet, with advanced search and outreach. Roughly: LinkedIn helps me find and contact candidates; the ATS tracks them once they're in the process. Around those I'd use scheduling tools like Calendly, Slack for internal coordination, and spreadsheets for reporting. I can pick up any company's specific stack quickly — the tools support sourcing, relationships, and judgment, they don't replace them."
  • Rubric: Strong answers know the categories and a few real ATS names, and draw the clean contrast — ATS = track candidates already in the pipeline (system of record), LinkedIn = find new ones (sourcing). Bonus for naming scheduling/Slack/spreadsheets and the "tools support the craft" framing. Weak answers blur the two, name no real tools, or imply tools alone do the recruiting.

D6

  • difficulty: hard
  • concept: in-house-vs-agency You've worked agency; we're an in-house team. How will your approach change, and what does source-of-hire tell you here?
  • Framework: Contrast the two models honestly (incentives, breadth, pace) → name what transfers and what you'd consciously adjust in-house → connect it to metrics: how source-of-hire reads differently and why it matters → end on the in-house priority of long-term fit and quality-of-hire.
  • Model answer: "Agency is commission-driven, high-volume, fast, and sales-heavy across many clients — it taught me to source and close quickly. In-house, I'm serving one company, so I'd shift from speed-of-placement toward long-term fit and culture, going deeper with hiring managers and caring what happens to a hire a year in, not just at signature. On metrics, source-of-hire matters more here because I'm building durable channels: if referrals produce the best, longest-tenured hires, I'd invest in a referral program rather than just buying more LinkedIn outreach. I'd watch it alongside quality-of-hire, since in-house success is great hires who perform and stay — not just placements made. What transfers cleanly is the sourcing-and-closing engine; what changes is the time horizon and the definition of a win."
  • Rubric: Strong answers contrast the incentive structures (commission/volume vs. one-company/long-term), state a concrete behavioral shift toward fit and durability, and tie source-of-hire and quality-of-hire to the in-house goal of lasting hires. Bonus for "invest in the channels that yield the best hires." Weak answers treat the two as identical, can't articulate the incentive difference, or describe the metric without connecting it to a decision.