Updated: Jan 10
In context of Programming and Analysis, I read so many times "pace yourself", "timing is really crucial on this one", "I ran out of time" ... I had no idea what that really meant other than deciding whether to take case studies first or not, and during the test drive myself crazy checking the clock all the time. It took me quite a while, and quite a few mistakes to figure out an actual strategy for pacing myself for PA, and any other ARE exam actually. Here I am sharing with you practices that help me be less worried about the running clock, and more focused on actual questions. I hope that they can be as useful to you as they are to me. There are tricks you can do before the test, and tricks you can do during the test. The key is not to underestimate importance of planning and following through. Having the same goal of making you less stressed during the exam. Ben Norkin from Hyperfine also writes on this topic in his latest post. His approach is a bit different, but worth considering to see if it works with you.
Indeed, good pacing for PA is obviously crucial, nothing new about that. What might be new is that it is critical to spend time seriously thinking about your pacing BEFORE the test. Not in a panicky way, though. Don't panic, don't let anyone scare you. You are doing you, and you will do what you think is best for you. Below I will show you a little exercise that can help you create a road map for your 3hr 15min time of test taking. The whole point of that is to strategically distribute your sharpest focus, while preventing yourself from being stressed out by the running clock. What do you think is easier: At Question 12 being concerned about 83 questions left to do in 3 hours, or At Question 12 being concerned about 8 more questions left that you had told yourself to finish before running 2hr 50th min? If the latter resonated more with you as an easier option, then we think alike. Breaking the daunting 95, or 75-ish (if we exclude case studies) questions into smaller chunks of 20/30/40 questions will do you a huge favor. When you break down the questions into chunks like that, you need to commit to finishing a chunk by certain time. If you feel like your time slot for a chunk is coming to an end, but you still have a couple of questions left, rush through them, flag them, and move onto your next chunk like nothing happened. Whether you get to go through all questions in time or not will be more or less the result of you sticking or not sticking to your before the exam plan and methods to employ during the test.
When I open a question, first I quickly glance at it, I don't dive into depths immediately. The point of glancing the question first is to hunt the key words. First glance will tell you if it is a soil question, efficiency question, or adaptive reuse question. Once you know it's a soil question, and it mentioned cohesion, then get back to the beginning of the question and read it again so you can understand relationships, and what the question is really asking. It might be tempting to skip the glancing part and go straight for the plowing part, but don't fall for it. It's kind of like cutting foam board. You score the top paper-y layer first and then you go deep. If you go deep right away, you end up with rough, fuzzy edges, and that's not cool.
When it comes to Programming and Analysis specifically, you will see a decent number of questions that I simply call puzzle questions. These are probably your main time sucks on PA (besides case studies), and as such they deserve special attention. Additional challenge with this type of questions is that there is not enough practice questions around to help you prepare. The good thing about them, on the other hand, is that you don't really need to STUDY for them. What you need to do well on this type of questions is: ability to read English (check), ability to read floor plan or axon (check), and most importantly - absence of panic. When you open a puzzle question, you will likely see more text than usual, and a floor plan or axon. Like with other types of questions, glance through it first, and absorb the graphic portion (confirm you understand the sun path, that you can locate river or whatever, that you can distinguish glazing, that you understand the difference between dashed line and solid line etc.) Then go in the deep. You will see that the text can be divided into two portions: intro and bullet points. Chances are that intro will be not super revealing, so let's focus on the bullet points. Don't waste your sharpest focus on plowing through all the bullet points, and then get to the plan to make a decision. With your sharpest focus read the first bullet point, and then look at the plan to see how the bullet point applies, what options it eliminates. Then read the second bullet point, go back to the plan. Third bullet point, go back to the plan. Soon enough, you will be able to narrow down your target. Once you have it, quickly read the question again to confirm that nothing contradicts with your judgement. Boom - you're done!
What to do if you can decipher the topic, but you have no idea what the question is actually asking, even after reading it twice or three times? In that case, you don't panic. It's time to get a little help. Imagine there is a jedi/fairy/angel/gnome/hobbit who can help you answer the pesky question. This imaginary creature, however, can only help you if you explain the question to them. Write down 4-5 what you think are the keywords to help your Yoda help you. As you try to explain the question in your own words to someone else, things will click in your brain, and you will understand what the question is asking. I know it sounds like woo woo magic, but trust me, it works like woo woo magic. I don't even know how many seemingly crazy questions became rather easy when I employed this method. Don't move away from a multiple choice question without answering it. Just click something, flag the question, and move on. If it is drag and drop, hot spot, or calculation, and you have absolutely zero, nada idea what it's asking, then flag it and move on. Again, no panic because every question counts just the same.
What I've just explained might seem time consuming to you, but it really isn't. Don't underestimate the power of your brain, it can do many things rather quickly. But you have to be strategic. Taking a tiny bit longer to work smartly can save you a ton of time on the long run.
Obviously, you need to know yourself well to make a realistic plan. Yes, I heard stories of people passing a test without answering one whole case study. I want to say Kudos to all of them, and I can only imagine what they were going through being out of time and ten-ish questions short. I don't want that situation upon myself nor anyone, though. That's why - it's time to plan out your 3 hours and 15 minutes!
I posted about this topic last week on FB, but in the meantime I improved the model/matrix. This is, again, something that you do BEFORE the test. I made it more graphic and more compact. Illustration below will show you what I mean. We have a handful of parameters here: question number - time left, break, regular questions, case study questions, brain freshness, and brain burnout. By "question number - time left" I mean "at what question you want to be at certain time", for example "I want to be at question 50 with 2 hours left in the bank". First, you will have to decide when to take case studies - at the beginning, in the middle, or at the end of your test. Based on practice case studies, or your past experience, consider how much brain power case studies consume. Is it a better idea to knock them out at first, get them out of the way while you're fresh, or work your way up to them? Above the horizontal question-time line you put question number, and below line you put the time you want to have left when you open that particular question. As you populate the line with information (you don't need more than maybe two or three "mile markers"), start thinking about when to take a break. Graphs that show your decline of focus, and rise of burnout will help you slide the 15-min break and position it where you think it will work most advantageously for you. You want to be really smart about when to take your break because if you take it too late, it won't serve you much to refresh your brain, as your brain will be way too fatigued. Trust me, speaking from experience here haha. Below you will see two examples: traditional approach of taking case studies at the end, and a bit less common approach of taking case studies first.
On the day of my third PA exam I decided to start with case studies (which I had never done before), I told myself that I should be done with them by around when second hour starts running. I obviously could not predict exact number of case study questions, but I could ballpark. I originally predicted 25 case study questions, and a break after question #25. That would give me cumulatively 50 questions, with 45 questions left. When the exam started, I went straight to the Exam Summary. I wanted to see how off my plan was, and what adjustments were necessary. I saw that the exam had 20 case study questions. I told myself - Ok, let's plan this out in 30 seconds, this is time well spent. I confirmed that I wanted to take case studies first, but I modified timing of my break. The remaining 75 questions I ended up dividing into two chunks - 40+35. So I answered 20 case study questions plus 40 regular questions and went on a break. That's about 15 questions sooner than if I were to take a break in between regular questions and case studies. That's really good news for my brain, because it gets to recover sooner. 15 questions is a lot and can make a big difference. And you really need sharp focus to finish the remaining 35. I had a little less than an hour to finish the remaining 35 and go over marked questions. At the end there were maybe 15-20 marked questions. Most of my answers remained unchanged, and 3 of them I didn’t get the chance to review again because I ran out of time. It wouldn't be PA, right? ;)