How to prepare for an oral exam?

The standard exam for the course on functional programming is written. Except for the times under corona, where it was a variation of a written exam, a “home exam”. However, the repeat exams are regularly held as oral ones. One reason is simply expedience. There are not too many candidates who need another exam. A written exam requires a lot more preparation than an oral one, which also needs some. For a written exam, one has to come up with new questions (but not too new, they have to be comparable to those from previous semesters). Setting up a question set alone takes time and involves iterations. And the content ideally needs to be quality controlled, best actually not just read, but solved and worked through by a colleague and not any colleague, one that is more than a little familiar with the material and the course (and has time at that time of the year). The Norwegian text needs to be read and polished with the help of a Norwegian, as even with a lot of effort, I cannot reach the level of 99.5% clarity and smooth formulations and without small glitches and strange formulations. The result needs to be pressed into inspera, there needs to be a proposal for a solution and some grading instructions, to achieve uniform grading, as always at least 2 graders are involved. At least the inspera set-up need to be finished 10 days before the exam.

With the written exam scheduled for mid-January (the oral a bit later), all that needs to be done at a time of the year which is already filled up with grading the real exam, done in December and being graded till early January, resp. filled with giving feedback for the exam and preparing the new semester. That’s too much effort (especially if it’s for just a handful exams), and it’s basically not managable unless one has prepared already 2 exams in November. Consequently, many repeat exams (not only for IN2040) are oral.

In my eyes, it does not make oral exams a stopgap or nodløsning. It’s a valid form of exam for courses, independent from the number of participants. Of course with a growing number of candidates, there comes a point where an oral exam is more effort than a written one. Written exams, which may be more common at UiO, are officially called “skoleeksam”, which, in my ears, sounds strange: we are a University not a school, and an oral exam is a valid form of examination at univiersties. One should not just be able to solve some little “exercises” that one has been trained to solve, but be able to explain concepts and shed light on a larger picture. Zoom exams and home exams under corona were a nodløsning, but oral exams are not; some of course may disagree, but I think anyway there is not one single form of exam that makes sense.

Anyway, it’s not that

an oral exam is like a written one, just oral and under enormous time pressure (each oral exam is planned for a time slot of 40 minutes).

The material and the pensum is of course the same, but an oral exam examines mastery of the material for slightly different skills. Consequently preparing for an oral exam and preparing for a written one is slightly different.

About this text

This post tries to give information about the oral exam, what to expect and how to prepare. It’s my view based on my personal experience. Experience from the time when I was a student and, of course, also from the many times I was examiner resp. assisting oral exams, like taking notes, doing the protocol, or being a sensor. In the Norwegian system, there exists the role of the sensor, some extra person who is able to understand what’s being asked and answered, and who plays a more influential role than just a silent note taker or witness.

Either way, I have been part of many oral exams, both as student as well as on the other side of the table. At earlier universities were I have been, outside Norway, oral exams in the computer science and physics curriculum were more common than here (at least at that time; I don’t know if that has changed). Basically, at master level, oral was the norm, below that level, written ones were also common. But even at lower levels, and even with large lectures, orals where likewise not uncommon, besides other exam forms like project work, (pro-)seminar presentations etc… At my first university, where I myself started, at that time beginner obligatory lectures had something like 450 or more students, and that’s a lot of orals…

So I’ve been to more than a handful oral exams as student, and, starting from my PhD-times, I must have been to literally hundreds or thousands of individual oral exams for quite a number of lectures of various sorts (my own or lectures of others).

The lecture here is functional programming with quite a number of technical content (like recursion, higher-order functions, environment model, evaluation strategies etc.), and focusing on problem solving (coding). That form of content influences to some extent the style of questioning.

Another influence is the examiner. I’ve seen quite a number of examiners, with different styles how to ask questions and how to structure the exam. Some give big freedom to the candidate, some favor precisely and narrowly formulated questions (maybe even written down) and expect a quite quick, narrow (and hopefully correct) answer. The style also depends on the content of the lecture. Some lectures are more about remembering stuff that has been covered. For instance I was a number of times involved in a lecture about communications architectures and network protocol layer standards, a lecture where one had a lot to remember), other are more about understanding concepts and/or being able to solve stuff. FP is more of the latter flavor. Below I will say a bit how I structure the exam and the form of questions and answers.

What to expect from the exam?

Goal of the exam

The topic is functional programming, resp. the aspects of functional programming (and not so functional programming) in Scheme covered by the lecture and SICP. The intent is to check breadth and depth of knowledge about that, the understanding of the concepts and checking the ability to solve problems. The goals influence the design of the exam (see below). Generally, we stress the understanding aspect.

To make an example: Let’s assume during an exam there’s the question “can you sketch an example of an environment model?”

If a candidate, who has thoroughly memo(r)ized everything, remembers the details of one of the figures that has been presented in the book or on the slides, draws the corresponding boxes, balls, and arrows, then that’s fine as such. But it’s expected that one can explain what it is. If the drawing is produced together with explanations what those boxes and arrows are and what it all means, that’s perfect. If one only remembers miracously the picture, but cannot explain even when asked, that’s not worth much. That’s a bit different in a written exam. Often one is just required to produce the answer, if its correct, it’s fine, no matter if the candidate knows what’s been done and can explain it or not.

That may sounds as if oral exams are harder. On the other hand, if the given solution contains errors (the picture from the example, or or some piece of code), that typically leads to deduced points; the errors are defects in the answer. Errors are of course don’t count positive in an oral one, but no one is expected to write don’t immediately a flawless answer. In a written exam, the end-result of an answer is graded (and one has decent time work out some answer and think it though and double-check it). For an oral, there is much less time, and it’s the process of arriving at an answer or solution or approaching it. If there is some error, there might be question (intended to clarify things), like: “look again at this arrow at the procedure object, it goes from where to where?” (maybe the arrow is the wrong way around or the arrow had is not drawn etc). And if the candidate then sees the error, explains what should have been there and why etc. then the whole glitch doesn’t count negative. As said, no one is expected to provide a flawess response on first attempt and without hesitation.

Of course, it depends a bit on how much helpful questions or outright help from the examinor is needed. If a halfway decent solution cannot be reached without major assistance from the sensor (giving hints, asking helpful questions etc), if that drags on too long that counts negative, already for the fact that it takes time and the amount of material that can be covered gets less.

Design of the exam

The oral exam is a form of dialogue or interview with a fixed time. It’s also a structured or guided dialogue: the examiner asks and the candidate answers. It’s not 100% rigid, also the way the answers are given shapes the dialogue, leading to follow a up question, or resulting that the examiner gives help or hints, or tries to get to the answer by reformulating the question.

I have seem exams like this: at the beginning of the exam, the candidate is given one or maybe more than one question, and then having some minutes to think out or work out an answer or solution. During those minutes, perhaps the student is left alone to think undisturbed, before called back to present the solution.

We don’t do that, the questions won’t be of the nature that requires 10 minutes working out or solving something, resp. if it’s a question that refers to working out something, it will be like “how does one solve this-or-that”, and the intention is to see if the candidate knows how to approach the problems, which steps one would go through if one had the time, perhaps starting to sketch some steps, but mostly not carrying them through. There is simply not enough time to do that in many cases.

Covering different areas

As said, one goal is to check the breadth (to a certain extent). Of course we cannot ask everything, so there will be a selection. In other lectures, I often use 3 main sections of roughly equal duration (plus maybe a shorter general questioning section or side issues). For functional programming, it will be probably more, maybe 4 sections or even more. Each of the sections is dedicated to one topic. Once the time for that slot is up, we shift to the next part: “ok, let’s move on to a different topic, say streams. For a start, tell me ….”. Strutcuring the exam that way is similar to the written exam; also there there is a number of problems, each covering mostly a specific area (sequence-operations, tail-recursion, procedure-based objects, streams etc), and some questions arranged in a number of sub-problems,

The reason why for functional programming (unlike for other lectures) are probably 4 sections or more, not 3 and maybe not as clearly separated is that the material and the kind of material does not lend itself too well to selecting 3 topics where one can go into deep.

Inside an topical area.

Inside some topical area, we typically try to steer the question from high-level to more low-level or more detailed ones. That’s to check the depth, how deep can we go.

At least in theory, since for some lectures that works better than for our lecture about functional programming. That’s because the material has not too much “conceptual depth”. It’s not meant to say, the lecture is not challenging or complex.

But if we start a line of questioning for “recursion”, one can follow-up with “tail-recursion vs. ordinary recursion and tree recursion”, but there’s not much “deeper” we can go in this linear line of question. One can dig deeper and pose a e questions involving code or maybe too, but that’s more or less how deep we can go. That means, even if recursion is a plausible question, the “field” is too small for one “section”, and in that section there will be other mildly related questions, but not necessarily deeper. If we also ask about tree recursion, or processes etc. it’s maybe in the same section, but it’s not really deeper, it’s just another question in that general area. So the questioning goes more sideways, not deeper sometimes. But still we want to structure and plan the session (per exam) somehow, not throwing random questions (small and big, from arbitrary places in the material) at the candidate.

Generally, trying to start a line of questioning from the top is done also for psychological reasons. If one starts right away with a very specific one, the chances are higher that maybe the candidates does not know the answer; that increases the nervousness, and then one may try a littler simpler, but still the answer not really going smooth, so in the end, the candidate cannot focus on anything else than thinking that already some early question were not done well, and that can influence the rest of the topic negatively. So, better is top-down, I guess (to the extent that’s possible here for our lecture).

Another reason why strict top-down lines of questionings, even if planned, not always works is that the answers shape the questioning. It can happen that I ask a question, and perhaps it turns out difficult to answer, so one backs off, making a more high-level or more general formulation instead, or a slighty other related issues (while sticking to the general “area”). That’s no immediate reason to worry either. To partly back off is meant to have something else to talk about, partly as assisting, because one can come back to the original question afterwards. When backing off a bit and talking about something a bit less specific or something slighty else, that often brings back ideas what is meant by the original question which then one can answer. It’s not uncommon, and as long as questions are answered it does not matter in which order.

What questions to expect?

I always say:

The questions that will be asked are actually known!

Maybe not the exact wording of them. If one asks “look at this piece of code and tell me…”, the exact piece of code may not be known and vary. But apart from that, the pensum (the slides, the book, the exercises…) should give a comprehensive picture what will or can be asked.

Like: if there is a slide with header “memoizaition”, there can be a question “what’s memoization?”. If there is topical area or section called “streams”, so there can be a question “What’s a stream?”. The latter topic contains details like “delayed evaluation” and “implicit stream definitions”, so there might be in the exam the follow-up question “thanks for the explanation of streams, but can yo also explain implicit streams” (or give an example in code, or say what’s delayed evaluation is” or “We discussed memoization in the context of streams, can you elaborate? Maybe start what by saying what memoization is in general?” etc.

Being asked the original question about streams, a good way of answering it is, maybe after say what streams are in general is, to proceed by explaining also implicit streams or given an example or explain delayed evaluation. In other words: to “volunteer” additional elaboration instead of waiting until resp. if that follow-up will be asked. Remember: for most questions we don’t expect one-liners as answer, there is basically always meaningful further elaborations to add, and offering that (by continuing adding relevant related information) is good. If we think, that’s enough, let’s move on, we say so. Volunteering in this way for relevant elaboration does not only show that you know yourself what is additionally relevant for the questions, somehow getting the bigger picture and how things hang together, but (hopefully) represent also that additional material correctly. And that’s time used positively in the exam.

Of course, if one vaguely remembers, memoization was somehow discussed in connection with streams, but one cannot remember why that was and what memoization actually is, it’s a bad idea of course to volunteeringly mention “memoization” (because mentioning the word will trigger a follow-up), but rather hope the line of question stops there, or offering delayed evaluation of stream-cons instead (because one remembers that stuff). Or not elaborating on anything, waiting for whatever questions, if any, will be posed as follow-up (hopefully not memoization…).

Offering additional relevant information is also good in connection with examples. For instance saying “Let me illustrate this with a small example”, that’s often a good way to demonstrate knowledge. And this way, you have control over the example. That may be preferable over waiting until or if the examiner ask “Look at this small example, can you explain the concept with it?” Already choosing a relevant, interesting example (and not too big) shows understanding. Of course, explaining a concept on a non-self-chosen example shows also understanding.

Now, back to the original point: what questions will there be?. I said, basically the questions are known (apart from details), and I mean it like that. In an earlier university where I worked as posts-doc, there was a professor from some other chair, who was known for publishing a long list of questions before the exam (on the internet and/or on the blackboard of his group, so the students could print them or make a copy). By coincidence, his lecture was about functional programming and it used SICP (I myself was not involved in the lecture, but was a few times involved in the exams about the material). Publishing the list of potential questions sounds weirder than it is.

Similarly, when I was a student myself, the student organization had collections of questions having been asked by this or that professor for this or that course. After surviving an exam, students were encouraged to note down the questions to the extent remembered during the exam (that’s not always easy) in order to help next year’s students. Welcome were also remarks commenting on the style of exam, like “that professor wants details, be careful, I had to solve things like XXX from the exercises in detail” or “the exam focused for me mostly on general stuff, I was over-prepared remembering tiny details and notation, but I was not even asked, but it went still ok”. After noting that down, one dropped that in the post-box of the student organization (nowadays via email or an “app” or a digital “løsning” no doubt…). So, when preparing for an oral exam, a smart thing to do was to go to the office of the student organisation for computer science, borrow the collection, and make a copy of the compiled questions of the last years.

So, since everything repeats more or less, the questions were more or less known. But even if a question is known, it may still be answered well or less well. And those lists where both helpful and, actually, not so helpful. They were not so helpful insofar that in principle, what’s being asked was clear to a good extent resp. should have been clear anyway. That’s why the public list of possible questions of the mentioned professor was not such a big deal. On the other hand, the lists were helpful. Not only because they contained (sometimes pieces of) information what kind of questions would typically occur and the style of exam, but giving the feeling one knows what to expect. Especially for the early semesters, if it’s one of the first oral exams, one could perhaps avoid loosing sleep speculating what on earth could happen. Seeing a (long) list of possible questions doen’t cut down the pensum, or make it easier to understand, but still it may feel more manageable.

How to answer?

I mean, how to answer, beyond giving correct answers…

There are two points to keep in mind, one is the fact that the exam is time-limited. The second one is, that the questions almost never expect a one-liner. For illustration, assume a question “what’s tail-recursion?” and an answer

“That’s recursion at the tail!. End of message”

That’s a, well, correct one-line answer, or at least a not incorrect one, but in this particular case is of course not very insightful either, almost an empty answer. So there will be a follow up, like “can you elaborate?”, or “what do you mean by tail?” or “what’s alternatives” etc. If the response to that is “What do you mean, I should elaborate in which way, can you ask more precise?” then the next question may be among other directions “What are other forms of recursion?” or “why is tail-recursion important?” or something related, just to obtain more information in connection with the initial question and to see whether the candidate understands what has been said.

This way of prodding interaction, trying to tease out information (with extra questions, help, or hints), is not ideal. For once it makes a better impression, if one elaborates relevant aspects in a structured manner oneself. Furthermore, it wastes time. Even if in the prodding-style, every single answer would ultimately be correct, not much ground would be covered. Before asking something more detailed or deeper or something else, the time for some batch of questions is over, and we start with a new line of asking, leaving many questions unquestioned.

Scratching only at the surface or covering only little ground, even if all answers are correct (or ultimately correct after trying to reformulate questions over and over), influences the outcome negatively.

For the same reason (avoiding waste of time), one should in answering not repeat information already given. Once answered, it’s done , and normally one gets signaled, that it’s answered (“ok, thanks about this, but what about that”) and then one should not say things about “this” again, maybe in different words: saying two times the same correct thing counts positive only once, the second time it’s a waste of time.

Of course not all follow-up questions by the examiners are prodding in a negative way, in fact many are not. So being asked an additional question as follow up is not a sign of having not volunteered enough elaboration. But if the questions consume more time than answers, it’s imbalanced.

What if I (as candidate) don’t understand what’s being asked or unsure what’s expected?

In such a case, just respond by “can you repeat/reformulate the question?” Or “Do you expect me that I do or explain the following?” “Does that question refer to ….?”.

What to do if I understand the question but don’t know the answer?

Well, not ideal, but it can happen. One should avoid to panic, of course. I think it’s seldom that one is completely blank. One could either volunteer for information about (mildly) alternative and related issues (but one not already answered). Or putting it into more general context. Maybe that is accepted by the questioner, however, the original question will probably not be forgotten (“ok, thanks, that’s correct, let’s come back to the original question…”) But as long as correct and related (and not already covered) information is given, it’s not bad, better than saying nothing probably and waiting for the follow-up question which may be in the same direction.

Also, it may feel better than plainly saying “I don’t know” avoiding panic, and it may be the case, that while talking about on slight background- or side-issues in connection of the original question, in the back of the brain, the original question resp. an answer becomes clearer, and one can answer. That can be a good answering tactic, saying something relevant, but slightly off first, delaying slightly thereby and while talking the real answer comes to one’s mind. It can work. Of course, one should use it with care. So when asked about streams, one should not try an answer like “Streams are a topic in functional programming, so let me start by explaining what programming is and then functionanal programming …”. That form of digression is way off, but there is always a bit wiggling room.

What will not be asked?

No trick questions.

From time to time, one has the impression, a candidate hesitates to answer a question, not because the answer is unknown but because a trap is suspected, a trick question. If the question is “what’s memoization”, then one sometimes see a dialogue like that (exaggerating for the purpose of presentation):

• A: “what you mean!?! You mean just explain what it is or the definition?”.
• Q: Yes sure.
• A: “You mean like explaining in words? or making an example?”
• Q: “Yes, sure, whatever you prefer.”
• A: “An example, is it allowed to use one from the lecture?”
• Q: “Yes, sure, if you remember one from the lecture, fine, or a different one, but don’t make it too complex”.
• A: “So a small example would be enough?”

In such situations, one has the impression, the candidate fears “there must be more to it, I understand what what’s being said, but that’s too obvious, I wonder what they really mean with this question, if I just say what memoization is, it’s probably a trick”.

But it’s never a trick question. It’s said, that some companies in IT use fancy questions. Microsoft especially is said to employ those as part of their recruiting (there are whole books collecting questions preparing for interviews with Microsoft or other companies that use that technique, like “how many ping-pong balls fit into an oil tanker?” or strange puzzles and brain teasers). Those questions are supposed to require imagination, improvisation, thinking on the spot and, an all time favorite “thinking out of the box”. There’s no thing as thinking out of the box at a university ;-) So questions posed are meant the most obvious way. The task is not to guess or detect the hidden meaning behind a question, it’s to answer it.

At least a question is intended to be obvious and we don’t intend to speak in riddles. Whether the question factually is obvious, however, depends also on the one being asked. But if in a question like “what’s memoization” the word “memoization” remains unclear, that would be a sign of not having studied or understood that part and does not make the question a riddle. The normal reaction in that case would not be the above dialogue, it’s more like “I don’t know the answer, I skipped that part”, or “I can’t remember details, I just remember that…”.

No long blind alleys (and maybe no too long thoroughfares either)

When we see that a question is misunderstood or the answer goes into the wrong direction, we “intervene”. So, it will not happen that a answer runs for minutes down a blind alley, and after the answer is given, we say, thanks, and note it down as answered all wrong (and having wasted precious time). So we try to correct the course, and put the answer back on track.

That does not mean, that the millisecond the answer goes wrong, we shout “stop!”. I believe, being interrupted abruptly a few times in mid-sentence can cost nerves. So we keep our horses for a short while, until the answering sentence is finished or something, and only then interfere in some way. Note that if the answer is slightly off, we might let it pass and let the explanation take its course slightly longer, even if it does not 100% fit to the question asked (but we are still happy). In that case, since we are ok with the answer anyway, this would not count negatively or as “answer not given”. We might afterwards try to come back to the original question, or maybe not.

In case the answer is correct and well-formulated, on track, and proceeds smoothly, more interesting information is added etc., then we may let it run for a short while. Still we may pose additional questions, or also try to redirect or stop the argument. Sometimes we stop, because we have seen enough, it’s all good, the candidate sure knows the answer and the field, so no need to continue. Or if the argument, while still ok, has run it’s course, and the answer starts going in circles or covering ground that is more or less explored, so does not add much new information and it becomes a bit a waste of time. So we move on.

Finally, it sometimes happens that the argumentation goes too slow. For instance, one could see that sometimes when asking for an example or when the candidate offers an example: “let me sketch it with a piece of code or a figure”. In principle, that’s all good. But then, line by line, letter by letter, parenthesis by parenthesis, a code snippet slowly unfolds on the whiteboard or paper, hesitantly checking and rechecking the parentheses. That sometimes results in a bad use of the time, a low information transmission rate, so to say, especially, if someone works on the whiteboard silently, without additionally sharing information on what is being done and why.

Anyway, being “interrupted” in one way or the other or having the course of an answer re-directed is not necessarily a sign of a wrong answer, indeed, it’s quite common.

Can I answer with stuff I know outside the pensum?

That’s quite tricky, resp. it depends. You are not expected or required to know things outside the pensum, and we don’t pose corresponding questions.

If you know material outside the pensum, that you are sure is relevant for the question, and if you are sure that the examiners can understand what you are offering or at least get the clear impression that you know what are talking about and also get the impression that your answer is relevant for the question, then one may try that. If you happen to impress the examiners with relevant extra things outside the curriculum that nonetheless fit to a question, that counts in your favor.

Having said that: this is of course not (!) an advice to read up on all kinds of extra-curriculum stuff planning for a shock-and-awe strategy, dazzle the examiners with all kinds of additional related stuff. That has a very low return-on-investment ratio and may easily backfire… If one happens to know such extra stuff for one particular question or other for whatever reason, why not.

What one should definitely avoid is to offer alternate material instead of pensum material.

This quite seldomly happens, but still one sees it happening. Like “I don’t know what a message passing is according to the lecture, but I stumbled upon an interesting article on message passing on Wikipedia/on some paper” or “I could explain it for Julia; I like that language, and you sure know it too, right?”. Sometimes, it might not be a problem (but very seldomly so). One might for instance be tempted to try to illustrate tail-recursion, abstract data types etc. also with other languages (if one happens to knows that and is shaky on the SICP coverage) . To that extent it’s partly answered (to the extent that one has shown understading of tail-recursion etc). However, the lecture discusses those concepts with Scheme and that is also part of the pensum and material. At any case, answer deviating from the pensum or from halfway conventional terminology may to the least slow down communication, it may lead to misunderstanding and all that is not good.

Actually, it does not happen offten but sometimes people seem to use “alternative” explanations or definitions as evasive tactic claiming “but in some other book, message passing is used differently”. Argumentation like that is ill-advised, at least during the exam (it happens now and then), to the very least it wastes time. And as examiner it’s normally easy to see through that, if it’s used as evasive tactics. If there is really a significantly different definition from somewhere, maybe outside SICP or computer science and someone really know that material, then it’s not even relevant, and trying to explain what the alternative definition means may be successful (and in the end the examinor believes the candidate knows what’s being talked about), but also that wastes time (and is still probably irrelevant). Anyway, when it goes into that line of answering and we are not happy with that, we intervene anyway (as explained).

How fast should I answer, how long should I think before the answer?

One should not feel obliged to blurt out an answer. Sometimes one sees candidates, they start talking before a question is even finished; there is not much gained by that. Better carefully listen to what’s being asked till the end of the question. And perhaps taking a breath while collecting one’s thoughts.

However, there is not much gained either in remaining silent for a long time, until one has found the best way to say things. There is no best answer, so no need to try to formulate one silently in one’s head, and start speaking only after the perfect one is mentally chiseled out. The only situation where I can imagine a “best” answer exists is for very precise and narrow questions: “Is this procedure tail-recursive or not?” “yes”, ‘nuff said. Actually, nothing wrong with saying something like “Let me see, here’s a procedure proc it calls itself here and here, and at this place it’s called inside a cons and therefore it’s not tail-recursive”. That’s a bit longer, but maybe even better (if not dragged out too long).

So for a question like “is this code tail-recursive or not””, one could of course say yes or no. If tail-recursion has not already been asked and answered, one could shape the answer like “Tail recursion is a specific form of recursion. It’s characterised by the fact ….blabla”. Maybe even offer its advantages, before coming to saying specifically something on the shown code. If the question is answered by a short “yes” or “no”, the follow up will anyway be (if tail-recursion has not been covered as concept already)

“why you think it’s not tail-recursive, can you elaborate, maybe start by saying what tail-recursion is?”.

How precise should my answer be, resp. how “evasive” should I answer?

Well, the more concise, the more to the point etc. the better. However, it depends also on the question. Some questions are more “loose”. So the precision of the answer should somehow fit to the precision of the question. To respond to a question

explain the concept of environment models

by

let me start by illustrating the notion of interpreter, because Scheme is a interpreted language, so that I can more clearly position the role of the environment model afterwards…”

is probably not a good move (besides the fact an actually environment models or run-time environments apply to compilers (and other languages, not just Scheme) as well). The reaction from the examinor will probably be, “wait a second, could you stick more closely to the question”. Offering to start by shedding light on a super-broad context feels like evading the question. And maybe hoping the question will be forgotten. Even if somehow I would let it slip, like allowing to starting with a broader context, the question will typically not be forgotten (except that in the end, time’s up, like being “saved by the bell…”). But it depends on the deviation. For instance, if the question is about streams, an answer starting like

“let me first shortly explain what evaluation strategies are, specifically what delayed vs. non-delayed evaluation means, before I clarify what it has to do with streams”

that’s is probably ok (again if evaluation strategies have not been covered already), maybe even good because it shows that one knows that streams have something to do with delayed evaluation. Trying to shed light on the even broader of “interpretation” of programming languages or similar on the other hand would stretch it. Also starting by

Let me first explain first the substitution models before I come to the environment model

feels evasive (though it shows knowledge that both model have some connection). Starting by explaining the environment model, addressing the question, and afterwards offering “this is more general than the so-called substitution model, namely in the following way…”, that’s not too bad, so one might be lucky to be allowed to continue explaining.

In general, as mentioned before, one should not ponder silently the best answer for long. Mostly there is no such thing than the best answer. Starting to say something meaningful and related things in the direction of a useful answer is preferable over remaining silent for long stretches. Silence counts for not much, saying something correct and in response to a question counts positively, even though one could have said it better or shorter or more understandable, given enough time to polish the answer. Therefore, also doing an mistake during an answer (especially if it’s about details of code) does actually count negative, everyone makes errors, provided one is able to either spot the error, resp. if the examiner points to it, recover from the error. It’s checking that you know and come up with the answer when thinking about it, not if you can know the answer by heart and immediately blurt it out fast in a stressful situation.

What kind of reactions to expect from the examiner?

I don’t have recordings of what I am saying or how I behave during the exam. So it’s just an “introspective” statement of what I intend to do and what I think I do. During an exam, I (and the sensor) must focus on the questions and answers, on what exactly is said, all concentration is on that. That’s also the reason why doing an oral exam is actually pretty exhausting (being questioned in an exam of course, as well). Anyway, one has no mental capacity to observe oneself. Afterwards, one can try to reflect on it, or the sensor remarks things (“I think your second question was not very clearly formulated” or “you should give the students more (or less) time to answer”, or whatever). But not during the exam.

Anyway, as examiner one gives feedback. Of course, when a candidate asks something like “can I illustrate it with an example?”, one says no (or more probably yes), that’s obvious.

But also without being asked there is feedback, an exam is also a dialogue, not an iterated monologue. There’s a couple of things I try to keep in mind. First, I don’t want to be too negative. I don’t want to communicate by body language, facial expressions, or words that it’s going bad, even if it is. Of course, if a question is misunderstood or an answer goes in the wrong direction, I need to try to put the answering process back on track (see the paragraph called “no dead alleys”). That’s done by words (“ok, I understand, before you continue, let me repeat and reformulate the question”), not by frowning, exchanging glances with the sensor and sharing a chuckle, or a face palm…

Actually, I have the impression, that a few candidates try to “read” the examiner, consciously or probably unconsciously. That may divert mental capacity from answering the question to the attempt to getting a feeling if the examiner is “happy with the answer”. But maybe some people have antennas for that and it’s natural and comes easy for them, I don’t know. Sometimes one sees people tentatively saying a partial answer, hesitatingly, without committing themselves, as if fishing for hints in which way to continue. I don’t know how successful it is, especially when it becomes too obvious… Anyway, try not to give too obvious body-language signals of what I think of an answer.

One the other hand, doing a complete robot-like poker-face during the exam to prevent fishing for answers is not possible. On top, it can create an uneasy atmosphere. It’s hard to talk to someone without receiving a slight nod here and there or a “Hmhm, ok, I see”. One can make people feel uncomfortable even stressful when showing no reaction at all. There’s even a name for it, it’s called the silent treatment…

So we don’t do it. The above reactions like “ok, fine” or “Hmhm, I see” are not meant as “that’s correct” or “that is what I want to hear” as answer. As bottom line, “ok” simply means, I am still following, I have heard and understood what’s being said, and if I don’t intervene beyond “ok”, then I see not need for ending that line of answering.

If I say “ok, that was correct”, or “ok, very good”, that is confirmation that the answer was correct. Actually, people mostly don’t need this confirmation to know themselves that their answer is correct; but there’s no harm in saying it anyway. On the other hand, most people are also aware while answering when the answer is not correct or evasive, or wishy-washy or delaying the real answer, or when unsure about the answer. So one does not have to explicitly state “ok, you were swimming here”, people mostly are aware of that, I think (I know that for a fact for myself). I could say “ok, let’s look more concretely at…”. But the latter could also be asked as just follow up for more information, it’s not necessarily meant as to communicate “I think you’re swimming”.

Are these hints useful in any way?

Perhaps they are, perhaps you think “ok, good to know”. On the other hand, if you think about those pieces of observations, they might actually not really useful for preparing, like giving actionable advice. They just describe behavior that I see repeatedly during oral exams, some with positive effects some with negative. But there is anyway not just one proper way of answering, different people handle dialogue differently. For instance, when saying, it’s better not to blurt out an answer before even the question is finished, but it’s also not good to remain silently for five minute before coming up with a crisp and to-the point one-liner, well, sure. But it does not give guidance like “during exam, I should collect my thought for 10 seconds, that’s the best and recommended”.

That specific advice makes no sense, and one is not graded for how many seconds it takes to start an answer, for instance. But the smoothness, structuredness and, of course, correctness of an answer counts. And of course, if every small answer takes 10 minutes, not much ground is covered, and that’s also negative. The fact that answers come super-slow is mostly a symptom of not being familiar enough with the material. So it cannot be addressed (during preparation) by training how to speak quicker, it’s addressed by learning the material better.

That answers come slow (or hesitatingly or not directly or with a lot of hints etc) may have also a slightly different reason. There is to some extent the phenomenon “I know the answer, but I don’t know how to say it” (though I maintain to understand something really means to be able to explain it). This “I cannot properly say it” effect that can be addressed, and I talk about it in the “How to prepare for the exam?”.

How to prepare for the exam?

Having discussed what to expect, the question is how to prepare for the exam. To some degree, it’s the same as would be for a written exam. The usual general advice, start-in-time, follow the material to some extent during the semester etcetc. Nothing new there.

First things first: Know your stuff!

That’s clear and generally not different from other forms of exams. There are, however differences what it means to know one’s stuff.

Drawing a parallel to written exam preparation

Written exams can be “open book” or “closed book” exams (for FP it traditionally closed book). For open-book exams, certain questions make no sense, like “what’s memoization”. But for open book exam, it obviously makes no sense to ask that question.

But even being closed book, the written exam for FP is mostly about solving problems, similar to the ones from the exercises or obligs. A collection of the written exams of previous years is also available, so one can look at the kind of questions that have being asked.

Those problem sets are intended for a 4 hour exam. The question are estimated to be solvable within 4 hours, provided one has solved or tried at least similar problems before, as preparation. Just “knowing the concepts” from the lecture without ever having done exercises oneself will probably be not good enough for a smooth sailing through the 4 hours (not even if it would be an open-book exam).

Anticipating the exam and planning the battle

Why talking about preparing written exams, when here it’s about an oral one. Because the underlying principles of how to prepare are the same. Some vary. Knowing the stuff, as said, is still the basics.

As mentioned, time is too short to solve a complete new programming task like one from a typical written exam, but still, there may be questions about “how to do this or that?”. That means one know how to address a problem, the direction of problem solving, something I sometimes called battle-plan.

Especially in a oral exam, if there are algorithmic problems to address, it’s not fancy ones, no problems that are large, or that requires some clever insight, no puzzles to be solved. It’s a bit like what I discussion also about “no trick questions”.

So there are standard problems, and one should be aware without much hesitation with what Scheme patterns one could address them (like when working at a list, one needs to do a list recursion, and one knows what typically the base case and the recursion case(s) is or are, and one has not to search long for such concepts).

One can then explain the problem, explain what steps should be taken, and why, while trying to sketch the code while taking. There is typically no time to actually code a fully a runnable solution (e.g. I will say: good enough, it’s fine). The point is to convincingly give the impression:

I can solve that, given enough time, with techniques from the lecture, and I can explain the steps it takes to do it.

Concretely solving it as in a written exam, of course also gives a convincing impression that one can solve it, but that takes too long time.

Not all or not even the majority of questions in the oral will be problem solving, there will be also conceptual questions. Like: “what’s tail recursion? What’s memoization?” Those may lead to code or “programming” problems, of course.

Conceptual question also those need (additionally) a battle-plan of a slightly different kind than the problem-solving battle plans, like “when being asked about memoization,

What concretely do I say, how do I structure my answer? Which example will I offer. If I don’t offer an example, what will I say if the examinor asks me for one. What else could I say in that connection?, Do I know what memoization is good for?

The battle plan is not reading about memoization one more time and nodding and thinking “all right, I think I get it”. It’s about being prepared for exam situation, anticipating it. Trying to concrete think about “what concrete words will I use when asked about memoization?”, even verbalizing it loud or writing it down: It’s more than . It’s good to “get it”, better is to double check “can I speak about it and explain it”. It’s like with preparing for a written exam. It’s not idea to read exam questions or exercises, read up the solution and nodding and thinking “all right, I think I get it”.

So hen preparing, one has to ask oneself “can I speak meaningful, relevant (and correct) things, for some time answering that question?”. Ideally in some structured form, like starting generally, going deeper, sketching some example etc. This may not the only way one can structure an answer, there can be others, but in general some structure is better than no structure, like hopping from one small piece of concept to another one, just in the order they pop up in the mind.

Even if they know one’s stuff, its for most not ideal if the actual exam is the very first time the words come out of the mouth. That’s what I meant that it’s a bit like

I know the thing you ask, I really do, but I never thought about how to say it, therefore I have a hard time now collecting my ideas, aligning my thoughts and actually saying it.

Some people are naturals, knowing the stuff means directly being able to lay it out in words clear and crisp on any given topic. But not for everyone. Sometimes one hears (not just in the context of exams) things like “I know it basically very well, I just cannot say it”. That dubious. I really believe: if one really knows something, one can to some extent explain it, even if it may not be elegantly formulated, one may stutter or the answer is rather unstructured, but still, one can communicate it. In an exam, a messy answer (that may additionally need lot of help) is kind of a proof that the candidate “knows” the answer, and can “explain” it, but it still counts less as a smooth explanation.

But what I believe or not is actually not too relevant: An answer like “I know it but I cannot say it or write it down” (no matter the help) is not worth much. Even if it were true, how could one know.

That form of preparation helps in more than one way. Firstly, as said, it’s typically not a good idea if the actual exam is the first time one searches for words to express something. Secondly, if one is critical to oneself, the attempt to really say things can show where one perhaps should read up a bit more. Finally, just the fact that one forces oneself to verbalize stuff in an clear way helps actually learning the stuff itself. It’s not the only way to learn it, but it contributes.

Same can be the case writing it up in one’s own words. Of course that takes time, it’s not clear if that would be an efficient use of preparation time.

One could also try to compromise: not writing up everything, but condensing a topical area into a number of items, keywords or memorizable cues. That requires focusing on the important stuff, organizing and structuring it, distilling it, perhaps writing it up with tiny handwriting to a small memo paper or sticky note. That’s of course the good old cheat-sheet technique. Organizing material in such a way is a good way of memorizing it, and one can go through the cheat-sheet memos before the exam.

Of course, using cheat-sheets in the exam is not allowed (but for an oral it does not matter as one cannot use them anyway). But writing cheat-sheets and using them to learn, I think is still allowed…

I stressed that verbalizing answers is, in my eyes, a good thing. Additionally, I think, a very good way of verbalizing it is not for oneself, but with one or more fellow students, so

Explaining concepts to others in a good way of preparing. One can even play examiner and examinee. Both profit from that. The examinee is forced to give answers, and what is being asked is controlled by someone else (the “examiner”). Also for the examiner, already listening to the answers repeats the material, and one can learn from it (“That’s a good way for answering, I should remember that for my self”). The examiner can give constructive criticism, but already a “Frankly, that was pretty confusing, I did not get it” may be helpful.

I think everyone profits from such a thing. Already going through the material (speaking or hearing) is a repetition. This form is not a replacement of first-time learning. One must have a certain level of learning progress and understanding before explaining things to each other or doing a mock exam. That’s clear, if no one has read Chapter 3, one cannot explain it to each other. Also if only one has read it but not the other, it may feel a bit unfair, so everyone should have at least some understanding.

Some remarks as reaction to the written exam 2023

The written exam, as basically always, also had some conceptual questions, This year, one small question of that type was what’s a procedure object?. That was the very first question, and there were some others later)

This question was answer disappointingly. Fact is, it was the question with the lowest percentage point score of the whole exam. To some lesser extent the other conceptual questions were answered not well.

For an oral exam, where conceptual questions that will play a larger role than in a written exam, the unability to explain things like that is problematic. In the written exams, where those questions had not many points riding on it, not much damage was done if one cannot say what a procedure object it. In an oral exam, the inability to explain things weighs heavier.

As illustration, let’s take a concept that everyone “knows”: recursion. That’s almost never asked in a written exam, one just assumes that everyone knows. Many of the coding problems in the exam will use recursion, and if one sees as grader that those problems are more or less solved, one can conclude the candidate can solve problems that involve recursion. And in that sense recursion is “understood”.

In an oral exam, one may start a line of question by just throwing in the question

What’s recursion?

maybe intended as a soft-ball, warm-up question. Being unable to answer that makes a bad impression, probably worse than having missed maybe 2 out of hundred points that such a simple question would have harvested in a written exam.

The question (also in an oral exam) is intended as an easy one that should take not much time. Therefore, the best answer itself should be not concise (= not too long, correct, and precise). Of course, as explained, one could extend the answer by volonteering to add information about tail-recursion etc., but that’s not the same as being imprecise or short.

The lecture material seldomly gives explicit definitions (as one can sometimes find in theoretical, mathematical, maybe alor also other kind of lectures (maybe from the law faculties ect). So there is no statement one-liner in bold face, preceded by the something like “definition 2.3.5” like the following that one would be expected to remember (and perhaps reproduce) as the one and only correct one: “Being recusive for a procedure means it calls itself in its body, directly or indirectly. End of official definition”

But when asked the answer(s) and the follow ups are graded how well what’s being said is correct and shows understanding of the material. And clear and concise and structured is better than, well, unclear, wishy-washy, or confusing.

What about code?

A written exam is to a large part about coding small examples. The text and advice here contained large parts about how to structure answers, how to answer, and how not and how to prepare for an oral situation. As illustrations, often I used conceptual questions (“What’s memoization?”). It reflects the fact that such conceptual questions and examining for understanding concepts plays a larger role. And that there’s no time for posing an written-exam-style coding question and wait until it has been solved.

But that does not mean that code or sketching code or understanding code does not play a role in an oral exam.

It will mostly not involve problems that need some challenging insight in the underlying problem itself. An example from the written exam might be the charity question. It had conventional patterns (let-over-lambda, procedure-based objects etc) that had been thoroughly covered, but also a twist, namely the two layers of encapsulation.

So solving it would including mastering the known patterns but applying it to a (mildly) novel situation. In the oral exam, the weight will not be on applying Scheme to really novel problems, but to more standard ones (however no garantee that all code examples show up literally on a slide or similar). Also the “coding question” may be not to code or sketch some Scheme code by the candidate, but that the examinor shows some code (which one may have seen in this or similar form), and asks to explain what the code does. The purpose is not to check if one remembers the code, but to see if one understands small pieces of code following known patterns from the lecture and one can make sense out of it conceptually. So a not-so-good answer is to “explain” things like “in the first line there is a define and it defines fac which I remember is something the lecture called factorial and then there is a newline and a parenthesis, and then an if following by more parentheses”. I am exaggarating for the purpose of illustration, but such low-level “explanations” show no deep understanding of what’s going on.

But also for possible questions or answer involving code (either when asked for code or as part of a conceptual question or when asked to explain a given piece of), one can prepare by anticipating that: “If I am asked to explain tree-recursion, and I am asked to give an example, which one would I take, and how would I sketch it and what do I say”.