The AI Data & Alignment Interview

The instinct interviewers reward: follow the guideline over your own opinion, and surface the gap, don't quietly invent a rule.

Concretely:

1. Re-read the guideline and any examples, the answer is often there, just not where you first looked. Check the definitions and the edge-case section.
2. Apply the closest documented principle and label consistently, whatever you decide, decide it the same way every time this case recurs, so your labels stay coherent.
3. Document your reasoning for the ambiguous item (most tools have a notes/flag field), so a reviewer can see why.
4. Flag it to the project owner so the guideline can be clarified for everyone, that improves the whole dataset.

What sinks people: overriding the guideline with personal judgment ('I think this should be X'), or guessing silently and inconsistently. The job is to be a faithful, consistent instrument of the spec, and a good escalator when the spec is unclear, not an author of your own rules.

Inter-annotator agreement (IAA) measures how consistently different people apply the same labels to the same items (often reported with a chance-corrected metric like Cohen's/Fleiss' kappa). High agreement means the guideline is clear and annotators are reliable; low agreement means the task is ambiguous, the guideline is underspecified, or some annotators are off.

Labs care because your labels become the model's ground truth. If annotators disagree, the training or eval signal is noisy, the model learns contradictions, and you can't trust the eval numbers. IAA is how they:

• Validate the guideline, low agreement usually means the instructions need fixing, not just the people.
• Quality-gate annotators, consistently low agreement with the consensus flags someone for retraining or removal.
• Estimate a ceiling, the model can't reliably beat the noise floor of its labels.

So as an annotator, being consistent with the guideline and with the consensus is exactly what's being scored, it's why your accuracy/agreement stats gate access to better-paid work.

First, rank against explicit criteria, not gut feel. The usual axes: does it follow the instruction (accurate and pitched to a 10-year-old), is it honest/correct (Rayleigh scattering, shorter blue wavelengths scatter more), is it helpful (clear, complete, not padded), and is it harmless. Weigh instruction-following and correctness first.

Work through both: is either factually wrong? Does one ignore the 'to a 10-year-old' constraint and dump jargon? Is one confidently wrong but fluent (a trap, fluency isn't correctness)? Is one padded with filler? Note ties and near-ties on different axes.

Then write a crisp 2-3 sentence rationale that names the deciding factor, this is the deliverable, and vague rationales fail. For example: 'Response B is better. Both are factually correct about scattering, but A uses terms like "wavelength-dependent scattering" without explaining them, missing the 10-year-old audience, while B uses a concrete analogy and stays accurate. B loses slightly on length but wins clearly on instruction-following.'

The signal: your reasoning is specific, criteria-tied, and reproducible, someone else applying the same rubric would reach the same call.

Because the ranking is one bit; the rationale is the signal that scales and that gets audited. Reviewers can't see inside your head, they judge your reliability by whether your explanation is sound and reproducible. Strong analytical writing is repeatedly cited as the single most important skill for this work: read a complex response, identify precisely what's good and wrong, and explain it in 2-3 tight sentences.

A strong rationale:

• Names the criteria it's judging on (accuracy, instruction-following, helpfulness, safety) rather than 'A feels better'.
• Cites the specific evidence, 'B invents a citation in paragraph two', 'A ignores the requested format', not vague adjectives.
• States the deciding factor and acknowledges the trade-off ('A is longer but B is correct; correctness wins here').
• Is reproducible, another rater with the rubric would follow your logic to the same call.
• Is concise and clear, no waffle.

Weak rationales are vague ('better tone'), un-evidenced, or contradict the rubric. This is exactly why backgrounds in law, journalism, philosophy, and science do well, they train precise evaluative writing.

If raters reward the wrong things, the model learns to exploit exactly those things, that's reward hacking, and it degrades the model at scale. The biases to actively resist:

• Length/verbosity bias, assuming the longer, more detailed answer is better. Models learn to pad. Reward completeness, not word count.
• Confidence/authority bias, a fluent, assertive answer feels more correct. But confident-and-wrong is worse than hedged-and-right. Verify claims; don't be swayed by tone.
• Sycophancy, preferring answers that agree with the user or flatter them over honest ones. Rewarding this trains a people-pleaser that won't push back when it should.
• Formatting/polish bias, nice markdown ≠ correct content.
• Position bias, favouring whichever you read first.

Why it matters: preference data is a training signal. Every lazy 'the confident one is better' teaches the model that confidence beats accuracy. The whole point of careful rating is to reward substance, correct, honest, genuinely helpful, so the model optimises toward that, not toward gaming the raters.

Consistency is the whole game, drifting standards make the data useless. How I'd hold the line:

• Score each dimension independently. Don't let a great answer on helpfulness inflate the factuality score, or one safety issue tank everything. Evaluate axis by axis.
• Anchor to the rubric's concrete descriptors, not a general impression, re-read what '3 vs 4 on factuality' actually means, and apply it literally.
• Separate style from substance. A well-written wrong answer is still wrong; a plain but correct answer is still correct. Fluency is not a score.
• Verify factual claims against the provided source or a quick check rather than trusting confident prose.
• Calibrate periodically, re-score a few early items later to check you haven't drifted; use gold/consensus examples as reference points.
• Write feedback that points at the exact failure ('claims X but the source says Y', 'ignored the word-limit'), not 'make it better'.

The meta-skill: be a stable measuring instrument. The same output should get the same scores from you on item 5 and item 500.

Polish and citations are not evidence of correctness, models fabricate confident prose and even invent plausible-looking sources. Evaluate the substance:

• Check the claims against the provided source (in grounded/RAG tasks, the answer must be supported by the given context, anything beyond it is a hallucination, even if true in general).
• Verify the citations exist and say what's claimed, models invent references and misattribute. Open them where possible.
• Separate 'sounds right' from 'is right', slow down on the specific factual assertions, numbers, dates, and names, which is where errors hide.
• Watch for subtle instruction violations, answered a slightly different question, ignored a constraint, added unsupported detail.
• Flag uncertainty honestly, if you can't verify a domain claim, say so rather than rubber-stamping; note it for an expert.

The trap the task is testing: letting good writing paper over a wrong answer. A confident, beautifully formatted, incorrect response should score low on factuality, and your feedback should point at the exact unsupported claim.

Random one-off 'gotchas' don't give a lab useful coverage, the value is a systematic, reproducible probe.

Approach:

1. Know the policy and scope, what is the model supposed to refuse or handle carefully? Red-teaming is measured against that, within an authorised scope.
2. Enumerate harm categories and go through them deliberately (e.g. the safety taxonomy you're given) rather than fixating on one.
3. Vary techniques per category, direct asks, role-play/hypothetical framings, obfuscation, multi-turn build-up, injected instructions, to probe how defences fail, not just that one prompt worked.
4. Judge severity against the policy, not shock value, a mild policy edge and a genuinely dangerous output are different findings.
5. Report reproducibly, the exact prompt, the failing output, the category, severity, and steps to reproduce, so engineers can fix and re-test.
6. Handle findings responsibly, within scope, no real-world harm, disclosed through the proper channel.

The signal: coverage + method + reproducible reporting + calibrated severity, and the judgment to know why an output is actually harmful, not a single lucky jailbreak.

Jailbreaks exploit the tension between a model's helpfulness training and its safety training. Common patterns (described at a high level, for defensive evaluation):

• Role-play / persona framing, 'pretend you're a character with no rules' to get the model to adopt a context where it treats the request as fictional/permitted.
• Hypothetical / indirection, wrapping a disallowed request as 'for a novel', 'for research', or a nested story so it feels non-real.
• Instruction override / injection, 'ignore your previous instructions', or planting instructions in content the model reads (documents, tool output).
• Obfuscation, encoding, translation, or splitting a request across turns so the intent is less obvious to safety filters.
• Incremental / multi-turn, building up harmless-looking steps until the last one crosses the line.
• Refusal suppression, instructing it not to refuse or not to include warnings.

They work because the model matches surface patterns and can be nudged into a context where it prioritises 'being helpful in the fiction' over the policy. As a red-teamer you test these systematically and within scope to find where defences are weak and report them so they can be hardened.

You're writing the gold standard the model learns to imitate, so it must be accurate, well-structured, on-spec, and honest. A strong demonstration:

• Directly answers the actual question and follows every instruction, format, length, tone, audience, exactly.
• Is factually correct and grounded, claims you can stand behind, and (for grounded tasks) supported by the provided material, not outside knowledge.
• Admits uncertainty where it genuinely exists instead of inventing specifics, because the model will imitate whatever you model, including false confidence.
• Matches the target style, same register and formatting the product wants.
• Is appropriately complete, thorough without padding.

The biggest trap: fluent fabrication. Because good demonstrations sound authoritative, it's tempting to write confidently past the edge of what you actually know, and every fabricated-but-smooth detail teaches the model that confident guessing is rewarded. If you're not sure, verify or hedge honestly. This is why real domain expertise is prized for this work: an expert writes accurate demonstrations and knows where the uncertainty is.

The lesson interviewers are checking: instruction-following is a first-class quality axis, not a nice-to-have. A factually correct answer that ignores the spec is still a failed answer, because the model will imitate whatever you accept.

So I'd revise the draft to match the spec exactly:

• Tone/register, rewrite to the requested voice (formal vs friendly, expert vs beginner). A right answer in the wrong register mistrains the model.
• Length, hit the target; trim padding or add the missing substance rather than padding.
• Format/structure, follow the required structure precisely (headings, bullets vs prose, JSON shape, citation style). Structure requirements are usually there for a downstream reason.
• Preserve correctness, fix the form without introducing errors; don't 'improve' facts you can't verify.

And in my note, I'd point at the specific deviations ('draft used a casual tone; spec asked for formal', 'exceeded the 100-word limit') so it's reproducible. The trap is treating style as cosmetic and only grading content, off-spec-but-correct should not pass, and your feedback should say exactly why.

The market exploded in 2025-2026; AI data annotation is among the fastest-growing entry-level tech roles, remote-friendly. The main players:

• Scale AI, mature tooling, enterprise-scale annotation programs, high throughput. Good for large, structured labelling operations.
• Surge AI, reputation for high-quality RLHF and preference data aimed at frontier labs; strong annotator quality bar.
• Mercor, matches vetted individual experts to AI training/evaluation work quickly; strong if you have real domain credentials.
• DataAnnotation.tech, Remotasks, Appen, Toloka, accessible entry points that onboard people with no prior experience and provide their own training; general annotation, chatbot rating, search evaluation.

Pay commonly ranges ~$14-22/hr depending on language and domain, with RLHF preference ranking among the highest-paid categories (and expert/domain work paying more). Specialized expertise (law, medicine, a rare language, a STEM PhD) unlocks the better queues.

The practical read: start on an accessible platform to build a track record, and if you have domain expertise, target the expert-matching platforms where it's worth the most.

Treat the assessment as the interview, it's a scored sample task, and your accuracy/consistency on it gates access (and pay). How to approach it:

• Read the guideline/rubric slowly and completely first. The assessment grades whether you followed the spec, not whether you're clever. Most failures are people who skimmed it.
• Optimise for accuracy and consistency over speed. Quality scores gate the good queues; rushing to clear volume tanks them. Better to be slower and reliably right.
• Follow the guideline even when you'd personally do it differently, and note/flag genuine ambiguities rather than free-styling.
• Write clear, specific rationales where asked, for RLHF/eval tasks this is most of the score.
• Verify factual claims rather than trusting fluent answers.
• Mirror the examples they give, they show you exactly what 'good' looks like.

Then build a documented track record: even 30-40 hours of solid, high-accuracy work opens higher-paying queues, and consistency compounds into access. The whole system rewards being a careful, reliable, guideline-faithful rater.

Yes, and a non-ML background is often an asset, not a barrier. Most RLHF/annotation roles don't want you to build ML systems; they want careful reading, clear analytical writing, research judgment, domain expertise, and consistent rubric application. Labs explicitly value backgrounds in philosophy, law, journalism, science, medicine, and education, because those train exactly the evaluative, precise-writing thinking the work needs. A degree is rarely required, proof of high accuracy and reliability beats a generic credential.

How to stand out:

• Lead with your domain. A lawyer rating legal answers, a nurse rating medical ones, a translator on a rare language, that expertise unlocks the higher-paid expert queues.
• Sharpen the core skill: analytical writing. Practise reading a response and explaining, in 2-3 crisp sentences, what's good and wrong. That single skill is the most cited differentiator.
• Be ruthlessly consistent and guideline-faithful, it's what quality scores measure.
• Build a documented track record on an accessible platform, then move up.
• Learn the vocabulary, preference ranking, rubrics, hallucination, grounding, so you understand what you're rating and why.

The field is one of the clearest on-ramps into AI work that rewards judgment over credentials.