Proctored Capstone Assessment B

Navigating the Proctored Capstone Assessment B Without Losing Your Mind

I just finished my third round of Proctored Capstone Assessment B this cycle, and I can tell you exactly what the proctoring software flags as suspicious and what it doesn't, because most of the "gotchas" come from things you'd never expect. The assessment itself is a timed, remotely invigilated coding challenge that combines algorithmic problem solving with a live code review segment. You're given roughly four hours to complete three coding problems of increasing difficulty, then submit your solutions through a browser-based portal while a human proctor watches your screen through a screen-share session. Most people assume this is purely a coding test. It's not. The evaluation rubric weights how you handle incomplete requirements heavily - you'll get partial credit for well-structured code even if edge cases aren't fully covered, but you lose significantly more points for messy, uncommented solutions that happen to pass all tests than for clean code that only covers 70% of the cases. I've seen candidates fail after passing every automated test because their solution had no input validation and they couldn't explain their tradeoffs during the live review portion. The proctor will ask you to walk through one of your functions line by line, and if you can't articulate why you chose a certain data structure over another, that's a red flag in the evaluation notes. The environment is locked down. You cannot open new tabs, switch applications, or have your phone visible in the webcam frame. The software tracks mouse movement patterns and will flag extended periods of inactivity or rapid tab switching. This means you should prepare your scratch space beforehand - a physical notepad works fine, and the proctor can see it on camera if you mention you're using one.

My Recommended Approach Before the Clock Starts

Here's the thing nobody tells you: the five minutes before the timer begins are the most important part of the entire assessment. Use that time to take a screenshot of your desk setup, position your keyboard and mouse where they won't obstruct the webcam, and open a blank text file in your code editor with your preferred template already loaded. I always pre-load imports and standard function signatures for Python - it saves maybe eight minutes total, but those eight minutes reduce panic significantly when you're staring at Problem Two with twenty minutes left. When the timer starts, do not immediately begin coding. Read all three problems first. Write down a one-sentence approach for each on your notepad. Then start with whichever problem feels most straightforward to you personally - not whichever seems easiest on paper. I once started with the medium-difficulty problem because the prompt looked simpler, got stuck on a boundary condition for forty-five minutes, and barely finished the supposedly harder problem that I actually understood conceptually from the start. The scoring is weighted toward the easier problem anyway since the hard one carries more points per unit of effort required. Proctored Capstone Assessment B uses a platform called Examity or a similar service depending on the institution, and the camera and microphone check at the beginning is where most people lose valuable time. Make sure your lighting is even - a single bright light behind you will cause the proctor to ask you to adjust, and those requests are logged. Position a lamp in front of your face, not behind your monitor, and keep your room reasonably lit so there's no high contrast between your screen and your surroundings.

The Screen-Share Walkthrough: Where Most People Diverge

After you submit your code, you enter a fifteen-to-twenty-minute live session with a proctor who reviews your solutions. This is not optional. You cannot skip it, and you cannot end the session early. During this walkthrough, the proctor will ask clarifying questions about your implementation. They want to hear you think out loud, not receive perfect answers. If you realize your solution has a flaw while they're questioning you, admit it immediately and explain how you'd fix it. Hiding a known bug until the end results in a much lower score than acknowledging it proactively. I learned this the hard way during my second attempt. I had an off-by-one error in my binary search implementation that I knew about but thought was minor. The proctor noticed it within thirty seconds and asked me to trace through it. I stayed silent for about forty-five seconds trying to remember a justification, which made me look guilty rather than careful. I finally said "you caught it, that's an off-by-one on the upper bound" and explained the fix. I still passed, but the note about my initial hesitation is in my evaluation record. On my third attempt, I called out my own bugs before being asked and scored noticeably higher.

Common Pitfalls That Have Nothing to Do With Coding

Your development environment matters more than you think. If you're using an online IDE provided by the assessment platform, test your internet connection stability before the exam day. A dropout that lasts more than thirty seconds triggers an automatic incident report, and you'll need to email support after the fact to request a review. I've seen candidates lose points on technicalities alone because their connection flickered during the submission phase and the proctor flagged it as a potential break in monitoring continuity. Another thing: close every application on your computer except your code editor. Browser tabs don't count as "applications" in most detection systems, but a running IDE, a terminal window, or even a background process like Slack or Discord can register as unauthorized software. I once had to reschedule because I forgot to exit a terminal I'd left open for testing, and the proctor's dashboard showed a second active window that triggered a warning flag. The rescheduling added three weeks to my timeline.

Timing Strategy That Actually Works

Divide your four hours like this: twenty minutes to read and plan all three problems, ninety minutes for Problem One, sixty minutes for Problem Two, forty-five minutes for Problem Three, and the remaining thirty minutes for review and the walkthrough preparation. This leaves you with buffer time, which is essential because Problem Three almost always takes longer than it should. The buffer also gives you space to refactor your earlier solutions if you spot inefficiencies later. Write your code in sections with clear comments separating each function. This serves two purposes: it makes the walkthrough easier because the proctor can follow your logic without digging through a wall of code, and it helps you identify where bugs might be when you're doing your final review. I once missed a missing return statement in a helper function that cost me an entire test case, and finding it took three minutes because the code was structured in blocks. When my next assessment had the same issue, I caught it in under thirty seconds for the same reason.

Post-Submission Follow-Up

After the proctor ends the session, you'll receive a confirmation email within twenty-four hours. If something goes wrong during the assessment - connection issues, software crashes, medical emergencies - document everything immediately. Take screenshots, save timestamps, and note the incident ID the proctoring system provides. I had a candidate who experienced a blue screen three minutes before his scheduled start time and lost his entire assessment window because he didn't grab the incident reference number before the system timed out. He had to retake the entire program module. That candidate could have avoided it with thirty seconds of action. The results typically come back within five to seven business days. The feedback is usually brief - a score range and a few bullet points on strengths and weaknesses. If you don't pass, the detailed rubric breakdown is available upon request through your program coordinator, and reading that breakdown honestly is more useful than anyone's opinion on how to improve. Most people fail on the same two items across multiple attempts because they don't address the root cause the first time around.