The following instructions assume that you have chosen a lab (or a project with "important questions") to work on. After reading the program's topical and descriptive information, you should begin here with the TPQs (Thought Provoking Questions).
As mentioned in your lab introduction tour, the TPQs are there to provoke your thoughts about the assignment. They are meant to guide you toward a good solution and help you notice details that can help clarify the topics involved in the problem's solution. This view leads us to realize two things:
Once you've picked an assignment, you should, of course, read about the problem and look through the sample run and any associated notes. Once you have an idea of what problem you are trying to solve, you should then read through the TPQs for the assignment to see what sorts of things you should be looking for while writing your program.
Sometimes you can answer questions right away. Perhaps the answer was given in the problem description or in the class notes related to the topic. Having that answer will make the coding process that much easier.
Other questions won't pop up until part-way through the program. But, having read the questions before you began coding, you'll know to go back at this point and find the answer to the question before going on.
Since the idea of TPQs is to provoke your thoughts, they cannot be answered with a simple numeric, T/F, or letter choice answer. You must explain how you arrived at that answer at the very least. (Even better, you could explain why other choices were not chosen.)
This also means that your answers should be complete sentences and should not introduce terms like 'they' or 'it' without first establishing an antecedent. There are two ways to accomplish this task: copy/paste the question into your TPQ answers or rephrase the question within your answer.
Depending on the question, you will probably want to discuss your implementation of the answer within the program you've written. This can actually be tricky if you go through several versions of your program before your final submission. Sometimes the question answer matches the original program version but not the final version! Make sure that when you revise your program that any questions affiliated with that part of the program get revised to match.
One last point: if I can't read your answer, it's wrong. (Actually this is more general than TPQs. It applies to anything you give me to correct/grade: tests, labs, quizzes, biographies, etc.)
TPQs are most easily and environmentally friendlily typed up in the editor on your Unix account. When done this way, a common way to save the answers to TPQs for the 'hello.cpp' program would be as 'hello.tpq'. Once your TPQ answers have been typed up, you can just cat them during your script (I'll even correct them if you hand them in for corrections!).
Other people will answer the TPQs in a block comment at the end of their main program file. They feel like they can more easily manage code-question revisions to avoid things getting out of sync. It also has appeal because it doesn't require a separate cat during your script since the answers are already in your main program file and will be 'cat' at the same time it is. However, this method isn't as true to good program documentation techniques as using the separate file. (The initial feeling of code-question synchronicity will even begin to degrade when we start making programs that consist of multiple code files.) Therefore this method isn't recommended, but it is a common approach.