Orbit Careers Exam 2

This exam tracks your hint spend by name so it can be graded. No password - just tell us who you are.

You start with 50 hint tokens. Each hint you reveal costs tokens; spending all 50 costs you half your score. Your balance is saved under this name, so reloading the page won't reset it.

Find your next role - apply in under a minuet.

-

Pipeline Admin

-

Manage roles

Recruiter tools: close a role once someone is hired for it, or reopen one. This is the back office - your applications above are yours alone, but roles are shared across the whole team.

Hints

Each hint has a cheap nudge (points at the area) and a pricier precise reveal (names the exact bug). Buying nudge first, then upgrading, only charges the difference. You start with 50 tokens; every token spent is a point off your final score.

Exam 2 brief

Same job, harder company: Orbit Careers, a job-application portal. It ships tomorrow too. The defects here are more subtle than Exam 1's - some only show up on a specific device width, some only after a specific sequence of actions inside a dialog, some only if you compare what's displayed against what actually gets sent to the server.

Jobs is the candidate-facing side of the app - browsing roles and applying. Pipeline is the back office - your own application tracker and a small "Manage roles" admin panel for closing/reopening roles. Your Pipeline is private to you; nobody else's applications ever show up in it, and yours never show up in theirs.

Intended behavior

This is how the app is meant to work. It's not a list of what to click - it's a description of the design, including some genuinely subtle parts. If something here doesn't match what you actually see, that's worth writing up.

  • The Jobs toolbar lets you search by title, filter by department, level, and minimum salary, sort the results, and toggle Saved only to show just the roles you've starred. The "Showing X of Y" count reflects whichever filters are active.
  • Starring a role (the star on its row) saves it for later, and it should stay saved regardless of what you do to filters or sorting afterward.
  • Clicking a role's title opens its details drawer, with the full description and an Apply button.
  • Apply is a 3-step wizard: your details, then experience/skills/resume, then a review before submitting. Each step validates its own fields, and Back/Next should preserve whatever you'd already entered.
  • As you add skills in step 2, the wizard shows how many of the role's listed requirements they match.
  • Only PDF resumes are accepted, both in the wizard and by the API.
  • If you've already applied to a role with the same email, the review step is meant to warn you before you submit a duplicate.
  • Every submitted application becomes a card on the Pipeline board, grouped by status. Opening a card shows its full details and lets you change status, edit years/salary/notes, save changes, withdraw it, or preview the exact resume file that was uploaded for that specific application.
  • Pipeline cards can be multi-selected with their checkboxes and withdrawn together from the bulk action bar, which shows a live count of what's currently selected.
  • Pipeline > Manage roles is the admin side: closing a role should stop it from accepting new applications everywhere in the app, immediately, without needing a reload; reopening it should undo that. It has its own search box, separate from the Jobs page's.
  • The app should hold up at desktop, tablet, and mobile widths - including open dialogs, not just the main pages.
  • What the API reports and what the page displays should always agree with each other.

Relevant info

  • The resume upload specifically is PDF only - genuinely useful to know before you start guessing at edge cases.
  • Applications and Pipeline data are private per candidate (see above) - you won't see anyone else's, and that's by design, not a bug.
  • Jobs (the role postings themselves) are shared by everyone - closing or reopening a role affects the whole app, not just you.

How hint tokens affect your score

You start at a maximum of 100 points. Every hint token you spend comes straight off that total, 1 token = 1 point - a cheap nudge might cost 2-3 tokens, a full reveal more, and you can see the exact price of each one before you buy it on the Hints page. You have 50 tokens total, so in the worst case (spending every single one) you'd be sitting at 50 points before anything else is even graded - and 50 is the line between passing and failing this exam. That's the risk side of the balance: the more you lean on hints, the less room there is left for anything else to go wrong.

That's not a reason to avoid them. Hints exist so that getting stuck on one genuinely subtle bug doesn't have to sink your whole exam, and knowing when a nudge is worth the cost is a real skill on its own - use your judgement, spend where it actually helps, and don't feel bad about it. And the points aren't necessarily gone for good: as the "What to do" list below explains, a real bug you find that wasn't intentionally planted, or a solid feature request, earns credit back - often more than enough to cover a hint or two. A thoughtful mix of "used a few hints" and "went and found something extra" is a completely normal, encouraged way to land a strong score. The one thing that reliably doesn't work is revealing everything and doing the bare minimum otherwise - that's the one path that's actually likely to cost you.

What to do

  • Write a test plan before you start testing.
  • Test functionality across both Jobs and Pipeline.
  • Test responsiveness at desktop, tablet, and mobile widths.
  • Test the API - see the tasks in the API section below, including a few that ask you to write your own test scripts.
  • Log defects and feature requests to Jira.
  • You're encouraged to go beyond the exam's built-in defects: a genuine bug you find that wasn't intentionally planted earns extra credit, and so does a well-argued feature request. Keep the ratio sensible, though - roughly one feature request for every five bugs logged (so if you've logged ten, two feature requests is plenty). A long list of feature requests padded on for extra points, without the bug-hunting to match, will be graded down rather than up - the credit is for genuine initiative, not volume.
  • Write a final test summary report with a go/no-go recommendation.
  • Use the same templates from Exam 1's Brief tab.

Saving a value between requests (copy-paste, no scripting needed)

A few tasks below ask you to reuse the id from one response inside a later request's URL. You don't need to understand how - just follow these steps and copy the box below exactly as it is:

  1. Send the request that creates the thing (a POST) once, so you can see it worked.
  2. In that same request, look at the row of tabs under the URL bar (Params, Authorization, Headers, Body...) and click Scripts (older Postman: Tests).
  3. You'll see two boxes, Pre-request and Post-response. Click into the Post-response box (the bottom one) and paste this:
pm.collectionVariables.set("myId", pm.response.json().id);
  1. Click Send again. Postman now remembers that id under the name myId - you'll see nothing change on screen, that's normal.
  2. In any later request, type {{myId}} anywhere you'd normally type that number - e.g. the URL becomes /api/exam2/applications/{{myId}}. Postman fills in the real number for you automatically.

Need to remember more than one id at the same time (the Part E chain does)? Use a different name each time - change the word myId in the script (both places it appears) to chainA, then chainB, then chainC for the three things you create in that task - then use {{chainA}} etc. to match whichever one you need.

Saving a token (Part C uses this)

Same idea as saving an id, just a different field name. After POSTing to /api/exam2/recruiter/login, paste this in that request's Post-response box:

pm.collectionVariables.set("recruiterToken", pm.response.json().token);

Then use it anywhere a request needs it. The simplest way: open the Headers tab of that request and add a header Authorization with value Bearer {{recruiterToken}} (typed literally, with the double curly braces - Postman fills in the real token). That's all Part C strictly needs.

Optional level-up: sending a saved value automatically (a pre-request script)

Typing the header by hand (above) works fine and is all you need. If you want to practice writing a Pre-request script instead - the other box next to Post-response, which runs before the request goes out - here's one that adds the same header for you:

pm.request.headers.add({ key: "Authorization", value: "Bearer " + pm.collectionVariables.get("recruiterToken") });

Paste that in the Pre-request box (the top one) of a request instead of typing the header manually - functionally identical, just a different way to get there.

Writing your own checks (pm.test)

So far you've been reading responses with your eyes. A pm.test makes Postman check a response for you and show a clear pass/fail - this is most of what real API test automation looks like day to day. Paste these in a request's Post-response box (same tab as the id-saving script - Post-response is where both id-saving and test-writing happen; Pre-request is only for things that need to run before the request goes out, like the optional script above).

A basic status-code check:

pm.test("status code is 201", function () { pm.response.to.have.status(201); });

Checking a field in the response body:

pm.test("response has a numeric id", function () { const body = pm.response.json(); pm.expect(body.id).to.be.a("number"); });

Run the request and open the Test Results area under the response (or the Postman Console, View > Show Postman Console, if you don't see a Test Results tab in your version) to see green (pass) or red (fail). A failing test you wrote yourself, on purpose, to check documented behavior, is a legitimate defect finding - it's the same thing as noticing something's wrong by eye, just automated.

Your applications are private - identify yourself on every request

Every candidate has their own private pipeline - nobody else's application data is visible or editable from your requests, and yours are invisible to them too. Jobs (the role postings) are shared by everyone, so they don't need this.

Any request that touches /applications or /summary needs to know who you are. The easiest way in Postman: add ?candidate=YourName to the end of the URL (use the exact same name you typed on the start screen). Example: /api/exam2/applications?candidate=YourName. Forget it and you'll get a 400 telling you exactly that.

Tip: set a collection variable once (candidateName = your name) and reuse ?candidate={{candidateName}} everywhere below - same idea as the myId trick above.

Raw JSON body examples

For requests that take a JSON body (not the file-upload one), set Postman's Body tab to raw and the dropdown next to it to JSON, then paste. A few you'll need:

{ "name": "YourName" }

POST /candidate, POST /recruiter/login - same shape for both.

{ "status": "closed" }

PATCH /jobs/:id - "open" is the other valid value.

{ "status": "interview", "yearsExperience": 6, "desiredSalary": 72000, "notes": "Strong portfolio" }

PATCH /applications/:id - partial, include only the fields you're changing (this example changes all of them at once, but any subset works).

API reference - base /api/exam2

API tasks

Exam 2 API request log /api/exam2/* - your Postman / curl calls

No requests yet.