Introduce yourself.

Tell the class which language you chose and anything that’s special about it.

Remind the class of the task that is the focus of your presentation.

Run the test harnesses and/or unit tests as appropriate to illustrate the problem(s) we found.

Being chosen often means that your solution failed one of my tests or a test that your peers submitted. While it is good to show the JSON inputs and outputs and explain the misbehavior there, the second step should almost always be one that explains how you internalized this failure into a small unit test, because those are easier to understand than JSON tests.

If your code passes all tests, you will skip this step.

Present the code in a top-down fashion. Explain your language as you go.

If your code passes all tests, work your way from the bit picture down to the interesting new ideas. Your peers deserve to see your code organization.

If you have a simple fix, explain it. If you don't, focus on explaining the problem, the area of code that is broken (see below), and then solicit help.

Be prepared to respond to questions by the class as admitted by the instructor.

Explain code that is visible to the audience. Don't scroll while you speak.

turn the failing integration tests into failing unit tests;

if a function/method fails its unit test, turn the failing test into unit tests for all the functions/methods that it calls.

eventually this "divide and conquer" method locates the bug in a narrow slice of your code. Focus on this slice for bug fixes.