exam technique?

[phalaris_trip]

Hi everyone,

This is my first post, so a brief introduction: I am a first year Engineering student in Trinity College Dublin. We have a fairly intensive workload including Maths, Physics, Chemistry, Mechanics, Logic, Graphics, and of-course Computer Science.
The CS part of the course is easily my favourite and it's also the one I'm best at. We are exclusively studying C++ for this year and next.

So with exams looming (two weeks time) I find myself in unfamiliar territory. From within an IDE I can write any program that isn't beyond the scope of our course. But on paper (as the exam will be) it often leaves me confused. The emphasis is more on algorithms, abstraction and concepts over code.
The student who can see a familiar pattern in an unfamiliar exam question is the one who will do best. Abstract techniques are very important. To be able to recall chunks of code that have different abstract names (e.g. the "head-tail" method for recursively reversing integers, the "fill-up" procedure for determining the usable size of an array, etc.) and to be able to apply them generically -- that's the real art of programming, isn't it?
I guess it comes with experience, but most of my success with C++ has come from trial and error.

I would like to know if there are any recommended resources of general algorithms that "any self-respecting programmer should know off the top of his head".. little tricks, little famous bits of code that work in certain situations.. priceless time-savers.. things like that..

Don't get me wrong, I'm not trying to find a shortcut past learning the hard way. I've done all the grindwork all year, and I know my stuff pretty well. Just looking for an edge before my exams basically.

(Our first-year course does not extend beyond: loops, functions, call-by-reference, 1-D and 2-D arrays, recursion, string manipulation.
Objects, classes, encapsulation, constructors, destructors, inheritance and custom header files will NOT be asked this year.)
And the goto statement is banned.. hehe..

Thanks in advance! Sorry if I'm being too vague.. it's late ;)

[Narue]

>that's the real art of programming, isn't it?
Not really. The real art of programming is solving the problem without creating an unruly mess. You can learn the names and memorize the code for a thousand algorithms and still be completely incompetent.

>I guess it comes with experience, but most of my success with C++ has
>come from trial and error.
Experience comes from making mistakes.

>I would like to know if there are any recommended resources of general
>algorithms that "any self-respecting programmer should know off the top
>of his head"
When I conduct interviews, I expect the following as absolute basics in general programming:

A thorough understanding of pointers.
A thorough understanding of recursion.
The ability to at least describe the concept behind four sorting algorithms that use different solutions (eg. divide and conquer with quicksort).
An understanding of arrays and how to use them non-linearly.
An understanding of linked lists in at least three variations.
A strong foundation in binary search tree theory.
The ability to describe at least one balanced tree algorithm.
Knowledge of at least one linear probing hash table.
Knowledge of separate chained hash tables.
The ability to tell me what data structure is best suited for a situation I provide.
The ability to tell me what sorting algorithm is best suited for a situation I provide.
The ability to describe the relative strengths and weaknesses of whatever data structures and algorithms we discuss.
Practical experience with complexity theory.
A strong problem solving ability (given a tricky problem).
The ability to adapt to changes when solving problems (given a tricky problem with increasingly frustrating restrictions).
The presence of mind to know when to give up (given an unsolvable problem).

Most programmers won't know this stuff off the top of their heads (my interview is tough, but so are the jobs), but for a college course, you'll probably be expected to have minimal depth knowledge (meaning you don't need to be an expert) with very wide breadth (meaning you need to at least have heard of a lot of things). A good resource for the stuff we use is DADS, but keep in mind that a lot of those items are very specialized.

>little tricks, little famous bits of code that work in certain situations.. priceless time-savers.. things like that..
Sorry, but that's the kind of thing you can only build up yourself.

[Rashakil Fol]

Relax. You'll do fine. If you feel nervous about the exam, practice writing programs or functions that solve particular problems entirely on paper. Type them into the computer and compile them and see how they fail. Based on your mistakes, take note of what modes of thinking should be avoided.

Also, don't use an IDE; use a text editor (a good one that at least indents your code to the right number of spaces, not Notepad). You'll be more comfortable that way, since IDEs train you to doubt yourself. Then you can use an IDE later if it's more convenient.