Career and recruiting terms, defined without the vagueness

An applicant tracking system is the database and workflow software a company uses to collect, store, and route job applications so recruiters can search, filter, and comment on candidates instead of managing email threads and spreadsheets.

An ATS is fundamentally a database with a search bar. When an application comes in, the system parses the resume into structured fields (name, contact info, work history, education, sometimes skills) and stores the original file alongside them. A recruiter then works from a dashboard: they search for keywords, filter by school or years of experience, sort by application date, and move candidates between pipeline stages like "applied," "screen," "interview," and "offer." Everyone on the hiring team sees the same record instead of forwarding attachments around.

The mechanism that actually hurts candidates is not a hidden scoring algorithm rejecting resumes at submission. It is that recruiters run searches inside the ATS for a role's key terms (a language, a tool, a certification, a degree field), and a resume that either lacks those terms outright or that the ATS parsed badly (columns collapsed together, a skills section trapped in a text box, a section header the parser did not recognize) never turns up in that search. The resume was never rejected by a score. It was never found.

For most internship and entry-level roles at companies without enormous applicant volume, a person opens and reads submissions in something close to arrival order well before any filtering happens. The ATS matters most at high-volume employers processing thousands of applications for a handful of roles, where search and filter are the only way a recruiter can work through the pile at all.

ExampleA posting asks for "Python" and a candidate's resume lists it only inside a skills-matrix table with icons instead of text. The parser may render that table as garbled characters or drop it entirely, so a recruiter searching "Python" never surfaces that resume, regardless of how much Python the candidate actually knows.

Common misconceptionThe persistent myth is that ATS software auto-rejects some huge share of resumes purely on a keyword score before a human ever sees them. That specific claim traces back mostly to resume-writing services with an obvious incentive to make the process sound more automated and more gameable than it is. The real failure mode is a resume that parses badly or a recruiter search that never turns it up, not a robot issuing a rejection.

Go deeperATS resume rules that actually matter

See alsoReferral, Phone screen

A referral is a current employee formally submitting a candidate's name into the company's hiring system, which typically guarantees the application gets a human look but does not guarantee an interview or any outcome beyond that.

Most companies pay employees a bonus for a hire made from their referral, so the internal referral form exists and gets used. Submitting one usually routes the application to a recruiter directly, sometimes with a flag or a tag that marks it as employee-sourced, which is why referred candidates report higher response rates than cold applicants: the resume is not competing to be noticed inside a queue of hundreds.

What a referral does not do is skip the interview process, guarantee a callback, or override a resume that does not meet the bar. It buys attention, not an outcome. A recruiter who screens a referred candidate and finds the background does not fit the role will decline them exactly as they would a cold applicant; the referring employee's bonus is contingent on a hire, not on a submission, so nobody is incentivized to push through a bad fit.

The value of a referral scales almost entirely with how well the referrer can vouch for the actual work, not with how senior or well-connected they are. A staff engineer who met a candidate once at a career fair and knows nothing about their code is a weaker referral than a peer intern who worked next to them for eight weeks and can describe specifically what they shipped and how they debug. Recruiters read the referral note, when one exists, and a generic "seems like a good student" carries little weight next to a specific claim a recruiter could ask a follow-up question about.

ExampleTwo students apply to the same internship. One is referred by a director in a different division who exchanged a few LinkedIn messages with them; the other is referred by a current intern on the exact team hiring, who writes two sentences about a project they built together. The second referral is worth more despite the referrer holding a far more junior title.

Common misconceptionPeople treat a referral as a guaranteed interview or a shortcut around qualification. It is neither: it is a mechanism for making sure a real person reads the application instead of it sitting unopened in a queue. Everything after that read still depends on the actual background.

Go deeperGetting a LinkedIn profile recruiters actually respond to

See alsoATS (applicant tracking system), On-campus recruiting (OCR)

An online assessment is a timed, remotely administered test, most often coding problems on a platform like HackerRank or CodeSignal, that a company uses as an early automated filter before committing recruiter or engineer time to a live interview.

The OA sits between application submission and the first live conversation. It exists because live interviewer time is the scarcest resource in a hiring pipeline, and a company receiving hundreds of applications for a handful of internship seats needs some filter before spending an engineer's hour on a call. Most OAs are two to four coding problems with a fixed time limit, though some include multiple-choice sections on computer science fundamentals or a short behavioral survey.

The problems on a given platform are drawn from a bank and rotate, but they cluster around a knowable set of patterns: arrays and strings, hash maps, two pointers, sliding window, trees and graphs, dynamic programming. That is exactly why a pattern-based prep approach outperforms grinding an unstructured pile of random problems: recognizing which of a dozen patterns a new problem maps to transfers to problems the candidate has never seen, while memorizing one exact solution transfers to nothing.

Scoring is typically automated against test cases (correctness and, on some platforms, runtime), sometimes combined with a proctoring signal (tab-switching detection, webcam, plagiarism check against a solution database). A candidate can pass every visible test case and still fail on hidden edge cases they never saw, which is why reading the constraints carefully and testing boundary conditions manually matters more than speed alone.

ExampleA posting's OA gives 90 minutes for three problems: an easy array manipulation, a medium tree traversal, and a medium-to-hard dynamic programming problem. A candidate who solves the first two cleanly and gets partial credit on the third by handling the base cases correctly typically clears the bar; a candidate who spends 60 minutes stuck on the first problem usually does not, regardless of how the other two would have gone.

Common misconceptionCandidates often assume the OA is graded on elegance or the interviewer's read of their approach. It is graded almost entirely by machine against test cases and, where used, a runtime or memory threshold. Style, comments, and variable naming are irrelevant to the score even though they matter enormously in a live technical screen.

Go deeperCoding interview patterns, not problem counts

See alsoTechnical screen, ATS (applicant tracking system)

A phone screen is a short early-stage conversation, usually 20 to 30 minutes and often with a recruiter rather than an engineer, that checks basic fit, logistics, and interest before either side invests in a longer interview.

The phone screen is a filter for fit and logistics, not a technical evaluation. A recruiter running one is typically confirming work authorization, availability for the internship dates, salary or stipend expectations if those matter for the role, and a basic read on whether the candidate can talk clearly about their own background. It is also the candidate's first real chance to ask questions that would be awkward to ask later, like team structure or what the actual day-to-day work looks like.

Some companies fold a light technical component into this stage instead of running a separate technical screen, especially for roles where a purely non-technical recruiter conversation would not tell them anything useful. When that happens the format usually shifts toward simpler questions than a full technical screen: explain a project, walk through a resume line, answer a conceptual question rather than write code live.

The most common way candidates underperform here is treating it as low-stakes because it is short and non-technical. A recruiter who cannot get a clear, specific answer to "walk me through this project" has no basis to advance the candidate, regardless of how strong the resume looks on paper, because the recruiter's job at this stage is specifically to generate that basis for the next interviewer.

ExampleA recruiter opens with 'walk me through your resume' and the candidate recites job titles and dates instead of what they actually did and why it mattered. The recruiter has nothing concrete to pass along to the hiring manager, and a stronger candidate underneath a weaker retelling gets screened out for a communication problem, not a substance problem.

Common misconceptionCandidates often assume the phone screen barely matters because it isn't technical. Recruiters use it as the first filter precisely because it is cheap to run at volume, and a bad phone screen ends the process before a hiring manager ever sees the resume.

A technical screen is a live interview, typically 45 to 60 minutes with an engineer, where a candidate solves a coding problem or answers technical questions while explaining their reasoning out loud.

Unlike the OA, a technical screen is evaluated by a person watching in real time, and that changes what is being measured. Correctness still matters, but so does the process: whether the candidate clarifies ambiguous requirements before coding, states an approach before typing, catches their own bugs, and responds to hints without shutting down. Two candidates who arrive at the same working solution can receive very different feedback based on how they got there.

Most technical screens follow a predictable shape: a brief warm-up or resume question, one or two coding problems of medium difficulty, and time at the end for the candidate's own questions. The interviewer is usually filling out a structured scorecard afterward with specific axes (problem-solving, coding ability, communication), not a single pass/fail impression, so a strong showing on one axis does not fully compensate for a weak one.

The single highest-leverage habit is narrating the approach before writing code and checking it against the interviewer's reaction. An interviewer who watches someone start typing immediately, with no stated plan, has to infer the reasoning after the fact from the code alone, which is strictly worse information than getting to correct a flawed plan two minutes in instead of discovering it in the debugging phase.

ExampleA candidate is asked to find a duplicate in an array. Instead of coding immediately, they state the naive nested-loop approach, name its time complexity, then propose a hash-set approach and its tradeoff, and only then start writing. The interviewer now has a full read on their reasoning before a single line of code exists.

Common misconceptionCandidates assume a fully correct, working solution is the bar. Interviewers are usually scoring the reasoning process at least as heavily as the final output, which is why a partially correct solution reached through clear, well-communicated reasoning often outscores a correct one produced silently.

Go deeperCoding interview patterns, not problem counts

See alsoOnline assessment (OA), Behavioral interview

A behavioral interview asks a candidate to describe specific past experiences, typically framed as 'tell me about a time when...', on the premise that how someone actually handled a real situation predicts how they will handle a similar one again.

The format exists because hypothetical questions ("how would you handle a conflict with a teammate") reliably produce idealized, rehearsed-sounding answers that predict nothing, while a request for a specific real incident forces a candidate to draw on an actual memory with actual constraints and actual outcomes, good or bad. Common categories are conflict, failure, leadership, ambiguity, and working under a deadline.

Interviewers are listening for specificity above almost everything else. A vague answer ("I've definitely had to deal with difficult teammates before, and I always try to communicate") gives them nothing to evaluate, while a specific one names the actual project, the actual disagreement, the actual action taken, and the actual result, which lets the interviewer probe further and confirm the story holds up under a follow-up question.

The failure the STAR method exists to fix is exactly this vagueness, and it is covered in full under that term. The other common failure in behavioral interviews specifically is picking an example that reflects poorly on judgment without realizing it: a conflict story where the candidate was clearly in the wrong and shows no awareness of it reads worse than picking a smaller, less dramatic example handled well.

ExampleAsked for a time they disagreed with a decision, a weak answer describes a disagreement in the abstract with no resolution. A strong answer names the specific decision, the specific action taken to raise the disagreement, and the specific outcome, whether that outcome was the candidate winning the argument or gracefully executing a decision they still disagreed with.

Common misconceptionCandidates often think the goal is to present a flawless story where they were right the whole time. Interviewers are frequently more interested in failure and conflict stories specifically because a candidate who can honestly describe a mistake and what they changed afterward demonstrates more self-awareness than one who has apparently never done anything wrong.

See alsoSTAR method, Technical screen

The STAR method is a four-part structure for answering behavioral interview questions: Situation (the context), Task (what needed to happen), Action (what the candidate specifically did), and Result (the measurable outcome).

STAR is a structure for organizing an answer under time pressure, not a script to recite word for word. The point of the four parts is to force an answer that actually reaches a concrete result instead of trailing off into vague reflection, which is the single most common way behavioral answers fail.

The most common failure, by a wide margin, is spending most of the answer on Situation, building out extensive background and context, and never reaching a clear Result. An interviewer who has heard ninety seconds of setup and thirty seconds of the actual action taken has almost nothing to evaluate, because the setup was never the part being assessed.

A weak, unstructured answer to "tell me about a time you missed a deadline" might run: "Yeah, so we had this group project and it was pretty stressful, everyone was busy, and honestly things just got hectic and we ended up turning it in a bit late, but the professor was understanding about it." Rewritten in STAR form: Situation, a four-person team project with a hard submission deadline and one member who stopped responding two days before it was due. Task, redistribute that member's remaining work without missing the deadline. Action, the candidate audited what was left, split it between the other two members based on who had capacity, and personally took the piece requiring the most context to finish. Result, the project was submitted four hours before the deadline and received a grade in the top bracket for the class. The second version gives an interviewer something to actually score.

ExampleSee the deadline rewrite above: the weak version never states a task, an action, or a result distinct from vague stress; the STAR version reaches a specific, checkable outcome within roughly a minute.

Common misconceptionThe common mistake is treating STAR as an outline to announce out loud ("so the situation was...") rather than an internal structure that should be invisible in a fluent answer. The other common mistake, already covered, is over-investing in Situation and running out of time before Result.

Go deeperBuilding a portfolio that actually gets interviews

See alsoBehavioral interview

A case interview presents a candidate with an open-ended business problem, most common in consulting and some finance recruiting, and asks them to structure an approach and reason through it out loud rather than produce a single correct number.

A typical case describes a business situation (a client's profits are declining, a company is deciding whether to enter a new market, a client wants to launch a product) with deliberately incomplete information. The candidate is expected to ask clarifying questions, build a structure for breaking the problem into parts, and work through the logic live, usually with the interviewer supplying data points as they are asked for.

What is being evaluated is the structure and the reasoning process, not whether the candidate lands on the exact number the interviewer has in mind. Two candidates can reach different final estimates and the one with the more logical, well-organized framework, who caught their own faulty assumption and corrected it, will typically score higher than the one who guessed closer to a target number through a disorganized process.

Common structural tools include profitability frameworks (revenue minus cost, broken into further drivers), market-sizing approaches that build an estimate from a small number of reasonable assumptions, and basic frameworks for comparing options against a client's stated goal. None of these are graded on being recited verbatim; a memorized framework applied mechanically to a problem it does not fit is a worse showing than an improvised structure that actually matches the situation in front of the candidate.

ExampleAsked to estimate how many piano tuners operate in a given city, a candidate does not need to know the real number. They are expected to build an estimate from the city's population, an assumed rate of piano ownership, how often a piano needs tuning, and how many tunings one tuner can do in a year, stating each assumption explicitly so the interviewer can follow and challenge the logic.

Common misconceptionCandidates often think the goal is memorizing frameworks and reciting them. Interviewers are trained to notice a memorized framework bolted onto a problem it doesn't fit, and that reads worse than a candidate who builds a simpler, more honest structure from scratch.

A superday is a final-round hiring event, most common in finance and consulting, where a candidate completes several back-to-back interviews with different interviewers in a single day, usually onsite.

The format compresses what would otherwise be a multi-week series of individual interview rounds into one day, which is efficient for the employer (multiple interviewers can compare notes on the same candidate immediately afterward) and intense for the candidate, who might do four to six interviews back to back with different people covering different things: technical or quantitative questions, behavioral questions, a case interview, and sometimes a fit conversation with a more senior person.

Because the interviewers usually meet afterward to compare impressions, consistency across the day matters more than any single interview being spectacular. A candidate who is sharp in the first two interviews and visibly fatigued and vague by the fifth gives the group a mixed signal that is harder to act on than a candidate who was solidly good across all of them.

Superdays are common in finance and consulting recruiting specifically because those pipelines tend to run on a compressed, cohort-based timeline with a large number of candidates moving through a small recruiting window, which makes clustering final rounds into one day operationally efficient. Tech hiring more often spreads the same number of interviews across separate scheduled days instead.

ExampleA candidate for a summer analyst program spends a Tuesday doing a technical interview at 9am, a behavioral interview at 11am, a case interview at 1pm, and a final conversation with a team lead at 3pm, all at the same office, before the firm makes offer decisions later that week based on the combined feedback.

Common misconceptionCandidates sometimes treat the first interview of a superday as low-stakes practice for the ones that follow. Every interview that day typically feeds into the same combined decision, so an early stumble is not recoverable just because more interviews are still ahead.

On-campus recruiting is a hiring pipeline that runs through a university's own career center and job board rather than a company's public site, often with its own calendar, application windows, and, at some schools, a bidding or lottery system for interview slots.

Employers who recruit heavily from a specific set of schools often maintain a dedicated pipeline through each school's career services office instead of, or in addition to, the general public application. That pipeline usually has its own posting calendar, its own resume book or portal separate from the company's main careers site, and interview slots that are scheduled through the university rather than directly with the employer.

Some schools ration interview slots for high-demand employers through a bidding system, where students are given a fixed number of points each recruiting cycle to allocate across the roles they want most, or through a lottery when demand exceeds available slots. Those mechanics are set by the university's career center, not by the employer, and they bind students the same way a course registration system does: miss the bidding window and the slot is gone regardless of qualification.

OCR calendars often run earlier and on a different clock than a company's general application deadline, particularly in finance and consulting, where OCR at target schools can open and close months before an equivalent public posting would even appear. A student relying only on a company's public careers page can miss an entire recruiting cycle that already happened through the career center.

ExampleA student's career center runs an OCR portal where a finance firm posts an internship two months before the same role becomes visible, if it ever does, on the firm's own public site. Interview slots are allocated through a point-bidding round the week before, and a student who does not participate in the bidding round does not get an interview slot even if they submitted an application.

Common misconceptionStudents who don't attend a school with a strong OCR pipeline often assume they've missed the only route in. OCR is one channel among several; a public application, a referral, or direct outreach can reach the same role, and at many employers the public pipeline is the primary one, with OCR simply layered on top at a specific set of schools.

Go deeperGetting a LinkedIn profile recruiters actually respond to

See alsoReferral, Rolling admission

Rolling admission means applications are reviewed and decided on as they arrive rather than being held until a single deadline, so seats can fill and a posting can close before its listed deadline actually arrives.

Under a fixed-deadline process, every application is collected first and compared against every other application after the window closes, so submitting on day one and submitting on the last day carry the same weight. Rolling admission breaks that assumption: a hiring team starts reviewing and making offers continuously as applications come in, which means the pool an early applicant is compared against is smaller and the seats remaining are more numerous than what a late applicant faces, even though both are technically applying to the same posting.

A large share of internship postings that display a specific deadline date are, in practice, rolling: the date on the listing is a formality or a legal maximum, not a real reflection of when the role actually closes. A posting can show a deadline six weeks out and have already filled its available seats within the first two, at which point the listing may stay up, get taken down early, or quietly stop being reviewed while remaining technically open.

The practical consequence is that applying early has a real, structural advantage under rolling review, distinct from any advantage in application quality. A merely solid application submitted in week one of a rolling window competes against a small early pool with most seats open; the same application submitted in week five competes against a much larger pool with most seats already gone, regardless of how strong it is.

ExampleA posting lists an application deadline eight weeks out. Because the process is rolling, offers go out continuously starting in week two, and by week five most of the available seats are filled even though the listing has weeks left on the calendar and may still be accepting applications nominally.

Common misconceptionApplicants often treat the posted deadline as the actual point at which their chances get evaluated, and so wait to submit a more polished version closer to that date. Under a rolling process, that wait can mean applying into a pool with far fewer open seats than existed the week the posting went live.

Go deeperSWE internships as an international student: a plan

See alsoExploding offer

A return offer is an offer extended to a current or former intern to come back as a full-time employee or a repeat intern, typically issued near the end of the internship based on performance during that specific term.

Companies that run structured internship programs frequently use the internship itself as the primary evaluation for a full-time hire, rather than running a separate full-time interview loop for interns who already worked there. The return-offer decision is usually made by the intern's direct manager or team, based on the actual work produced over the internship, feedback from teammates, and sometimes a short final presentation, rather than a fresh set of technical interviews.

Because the evaluation window is the entire internship rather than a single interview day, the deciding factors tend to be different from what gets an internship offer in the first place: reliability, how the intern handled feedback and ambiguity, whether they became someone the team wanted to keep working with, and the quality of what they actually shipped, weighted more heavily than raw technical polish in a one-time interview setting.

A return-offer rate published by a company (the share of interns who receive one) is a genuinely useful signal about program quality and team investment in interns, though it should be read alongside how selective the initial internship offer already was: a program that hires very few interns to begin with can post a high return-offer rate without that saying much about the odds facing a new applicant.

ExampleAn intern spends ten weeks on a team, ships two shipped features, and gets consistently positive informal feedback from teammates throughout. Near the end of the term, their manager extends a return offer based on that accumulated track record rather than a separate interview process.

Common misconceptionInterns sometimes assume a return offer is close to guaranteed unless something goes badly wrong. Programs vary enormously in return-offer rate, and some run a genuinely selective bar at the end even for interns who performed adequately, so treating the internship itself as the actual interview, start to finish, is the more accurate framing.

An exploding offer is a job or internship offer with a deadline set short enough, often 48 hours to a week, that it pressures a candidate into deciding before they can complete other interview processes already underway.

The short deadline is a deliberate tactic, not an operational necessity. Employers use it to lock in a candidate before a competing offer arrives, since a candidate juggling multiple processes is more likely to accept the first firm offer on the table if the clock forces a decision before the others resolve. The tactic works precisely because it removes the candidate's ability to compare offers on equal footing.

Asking for an extension is a completely normal, low-risk request, and it is usually granted, at least partially. Recruiters who deploy a tight deadline are generally prepared for candidates to push back on it, and a brief, polite request explaining that another process is in its final stages rarely costs a candidate anything; companies that would rescind an offer over a reasonable extension request are unusual, and that reaction is itself useful information about the employer.

The deadline is a negotiating position set by the company, not a fixed external constraint, which is the framing worth internalizing. A candidate is not bound by it in any legal or ethical sense before signing anything; the only real cost to asking for more time is a small amount of social friction, which is a reasonable trade against making a multi-month commitment decision under an artificially compressed clock.

ExampleA candidate receives an offer with a 72-hour deadline while a second-round interview at another company is scheduled for the following week. Emailing the recruiter to ask for two additional weeks, explaining there is a competing process nearing completion, commonly results in at least a partial extension.

Common misconceptionCandidates often treat the stated deadline as a hard rule they have no standing to question. It is a tactic chosen by the employer to manage their own risk of losing the candidate, and pushing back on it is a normal, expected part of the process rather than a breach of etiquette.

Go deeperSWE internships as an international student: a plan

See alsoRolling admission, Reneging

Reneging is formally accepting a job or internship offer and later withdrawing from it to take a different one, typically after a better offer arrives.

Reneging differs from simply declining an offer in the normal window before acceptance; the defining feature is that a commitment was already made, sometimes in writing, sometimes by signing paperwork, before the candidate backs out of it. That timing is what makes the consequences different from an ordinary decline, since the employer has typically stopped considering other candidates for the role and may have already told other applicants no.

The real consequences are worth stating plainly and without exaggeration. Some university career centers treat reneging as a policy violation and can restrict a student's access to on-campus recruiting in future cycles. Some employers keep informal or formal records and will not consider that candidate again. In small, tightly networked industries, particularly finance, individual reneges are sometimes known and discussed among recruiters at other firms, which can attach a reputational cost beyond the one company involved. None of that means a single renege ends a career; it means the cost is real and worth weighing rather than either dismissed or catastrophized.

The lower-cost alternative, where it is available, is negotiating before formally accepting rather than after: using an exploding offer's deadline as leverage to get an extension, or being transparent with a first-choice employer about a competing timeline before signing anything with a second choice. Once a formal acceptance is in, reversing it is a materially bigger step than declining would have been a week earlier.

ExampleA candidate signs an offer letter from one company, then a week later receives and accepts a preferred offer from another, notifying the first employer they will not be starting. The first employer has by then likely stopped recruiting for that seat and told other candidates no, which is the concrete harm reneging causes on the other side.

Common misconceptionCandidates sometimes treat a verbal acceptance or a signed offer as easily reversible, similar to declining an offer they hadn't yet accepted. The two are not equivalent: the employer's behavior (closing the search, notifying other candidates) changes the moment a formal acceptance is in, which is exactly why the consequences of reversing it afterward are heavier.

See alsoExploding offer, Return offer