There's something to be said for understanding the theory of the design programs we learn, but if you don't understand the techniques to implement it, you're in a lot of trouble.
CS is a very hard program to "study" for. There are an infinite number of ideas that could be used or asked of you when it comes to exams. In assignments, there's a skeletal structure (that may or may not be comprehensible to the student), but is at least a means to say: here, run with this.
Exams are a whole different set of problems.
In practicality, it is useful for a CS industry professional to be able to predict a client's wishes.
One can come up with a generic outline of what they are going to be looking for, and the collection techniques needed to deal with that problem. Exams are much the same way, but with a catch.
The only way a student is going to pass a CS exam is if they understand the techniques and implementation of what they've been taught (thereby allowing them to apply it to any question that might be asked of them.
The catch is that in my experience of post-secondary education (which dates back to 2007, and includes a very large number of subjects and fields and instruction techniques), the one consistent theme is that the idea that they're going to test you in ways that make sense to them, but not necessarily to the students.
You have to think like an instructor.
The same way that when you're writing a history essay, you have to think like your TA.
Or when you're designing a program, you think like your client.
What are they going to want?
Post-secondary exams have some help if there is access to past tests (where you can extrapolate the language of the questions that they might ask). You can also look at exercises and assignments and redo them. If they gave you the time to put some forethought into the exercises, and space and time to do it, it's a fair bet that they're going to build on what they assumed you worked out for yourself.
No comments:
Post a Comment