The software engineering exam was the first oral examination in this study program for our semester group. Or in fact is, because it’s not over yet, not for all of us leastways–it lasts three days. But mine was yesterday morning.
I spent some hours this weekend reviewing my flashcards for software engineering for the umpteenth time, and practising my opening statement. We are allowed five to ten minutes at the beginning of the examination in which we can talk about any subject of our choosing, so to be on firm ground at least at the start. At some point, the professor said, he would interrupt and start questioning us. I picked user stories in agile software development for my starter; it’s a fairly basic core subject, without any major pitfalls, and easy to present. Still, my first version of the statement was way too long. I started with requirement analysis in general and talked about various techniques, including the somewhat confusing Value Proposition Canvas model, before even getting to user stories proper. When I recited the thing to my wife on Sunday, it took about a quarter of an hour. She advised me to radically cut it to just user stories, period. I did, and as a result I had something that had structure, punch, and was about seven minutes long, plus a lot easier to remember without need for eloborate mnemonics.
Even though my exam was on Tuesday, I still went to the university on Monday in time for the first examinations. For one thing, my programming partner and I had agreed to meet for some last-minute studying. For another, I considered it a good idea to watch the first exam day to get some idea how things worked.
As I said earlier, the professor had only fixed the day, but not the hour for the individual examinations. Apparently it happens that people don’t show up, so rather than have gaps in the schedule, he simply assigns the time slots to the people who are actually there at the appointed time in the morning. This Monday, however, it seems he was early and started assigning people as they showed up, so that when two of my co-students arrived ten minutes before the appointed hour, the morning slots were already taken and in spite of their being officially still early, they only got time slots in the middle of the afternoon and had all day to wait and get nervous. Naturally I resolved there and then to be really early on Tuesday.
I spent most of Monday in the cafeteria with some co-students and we asked each other questions from our flashcards (as I said, meanwhile everyone uses them), taking turns. As I said the contents of the software engineering lecture had been rather limited, and we mostly found that we already all of us knew most things by heart. Though one co-student surprised me by having memorized every little detail from all the different notation systems we had at some point briefly covered in the lecture, such as UML activity and component diagrams, BPMN, and so forth. I had rather considered these things brief disgressions of which it sufficed that we know that they existed.
Then gradually people starting coming down to the cafeteria after their own exams, and we listened eagerly for their experiences. For that’s of course the novelty of this setup–unlike in a written exam, we’re not all in the same boat. Rather, the earlier candidates are necessarily the guinea pigs, and we others benefit from their experience.
Turned out though there was little to worry about. The exams apparently took place in a rather relaxed atmosphere and felt more like easygoing chats than like actual examinations. The professor usually let people finish their opening statements, unless they were really lengthy, before chiming in with questions. None of the reported questions were really nasty, and most people got out with really good grades (yes, you were being told your grade right away, which is another upside of this format). In fact, until the evening I knew only of one person who didn’t get an A+, and his grade was a B+. (Later I learned of one B- and one straight C.)
I did take note however of the questions of which people thought they had made the difference for their A+. There was usually at least one question that went beyond the contents of the lecture itself, one intended to make the candidates think and demonstrate their problem-solving skills. Notorious was the question of whether an application facade obeyed the principles of high cohesion and loose coupling (how should it) and what to do about that. But one co-student had been asked how one might resolve cyclic dependencies in a component architecture. That’s a fifth-term problem! But everyone agreed that the professor, in asking such questions, was not really after the answer, but wanted to see whether you had a brain to think with. And practically everyone had either been asked to draw some UML diagram, or interprete one given to him/her.
So on Monday afternoon I belatedly studied all the notation systems, including the details of UML use case diagrams and activity diagrams, things that had hardly been touched in the lecture, and then read up on resolving cyclic dependencies. Apparently the textbook answer is dependency inversion: you drop in an interface somewhere that’s implemented by one class and then referenced by the other, so they are no longer dependent on one another. Even though I had some trouble understand the ramifications of this solution, I thought even having heard of it might be enough to show I knew some things outside the lecture box, just in case. In between, I reviewed random selections from my flashcards, but at this point I hardly ever found one that made me think twice. In fact, I think I have never been so well prepared for an exam.
On Tuesday morning I waited before the examination room a full hour early, so I could secure an early time slot. Waiting another full day for the exam would simply have been a waste of time at this point, and with the last exam (graph theory) still before us, I could make better use of my time. One co-student from our study group also showed up really early in hope of then getting examined early. Yet unlike on Monday, this time the professor waited until all 10 students had showed up, then took out his schedule and asked “who wants to go first”. I said “gladly” very quickly and determinedly, whereas a few others merely raised their hands, and thus I got the first spot, right at 9 AM. My co-student was not quite as quick and got the tail end at a quarter to three in the afternoon. Even though I was lucky, I’m not sure I quite approve of this first-come, first-served practice (in German, revealingly, it’s called the Windhundprinzip, literally sight hound principle, but what it means is race hound principle–the fastest dog wins), though at the same time I can’t really think of any procedure that would be substantially fairer. My co-student was understandably rather pissed off.
The exam itself went really well. The professor almost let me finish my statement on user stories–he only interrupted when I said I wanted to say a few thing about Kanban and user story maps (tools to organize user stories), pointing out that he was sure I knew all about these. Then he asked me how I would prioritize user stories within a Kanban backlog, and what to do when I wanted to assign one story to two developers. I believe this was my thinking question, and I am not sure I answered really well. After about a minute of guessing on my part he said “maybe it’s too simple”, whereupon I suggested one might simply have the same card twice, and that was close enough for him, it seems. The rest of the exam was a breeze. I don’t remember even being asked more than a couple of questions. One was how I would find dependencies in a component architecture. I said basically by analyzing the structure and a lot of common sense, but didn’t fail to drop in the fact that cyclic dependencies were really bad. (Come on, ask me how to resolve them! But he didn’t take the bait.) And I did get the question about cohesion and coupling in an application facade. The exam was over before I even knew. And diagrams were never even mentioned.
I had to leave the room for a few seconds of token deliberation between the professor and the minute taker. I half expected an A- or so because of the Kanban question that I took so long to answer, but I got an A+ alright. The professor said it was obvious that I had understood the contents of the lecture and could have talked a lot more about most things. In fact, talking was my thing anyway, he remarked.
It’s true, of course. Not only had I done most of the talking on the student side in the lecture itself. It’s also always been my conviction that in an oral exam your best bet is never to stop talking if you can help it. You see, I have been on the other side of that desk. For the examiner, asking questions is work, and having to worm the answers out of the candidate is hard work. Most examiners like nothing better than a candidate who doesn’t have to be interrogated, but just keeps talking–as long as what s/he says makes sense of course! And from the student’s perspective, any second in which you not talk is a second in which the professor might ask you something you don’t know. So just keep talking about things you do know, and in the end everybody will be happy. That’s the main reason I like oral exams.