Monthly Archives: May 2013

Exam, job interview

I grew old. Now my son visits university classes and passes exams. Many years ago I was delivering some lectures at TU Budapest in Hungary, right during my university years as assistant and later as a PhD student. During those years I also conducted exams although I am not absolutely sure that level I was allowed to do so. Practically it was correct. I always wanted to be fair and correct and after that many years I still believe I was.

Shortly after 2000 I created a special tutorial that students could select to attend optionally for credits. We delivered the subject with my old friend George Pongor. The topic was about the structure of ScriptBasic and generally about the how to create a scripting language. Compilers were favourite subjects for George anyway. He was the first person I learned Java from. The tutorial was delivered only in a single semester. During the next semester only a few students applied, and thus the subject was not started. Before the next semester George died in a sudden heart attack finishing a tennis game. He was about the age I am closing now. His personal home page at TU is still frozen, and available as it was.

This did not conclude my carrier as a teacher, since being teacher is not a job but a profession. I did deliver lectures for living at a Hungarian high school and also as part of many projects in my own company. At my current employer I also deliver trainings regularly.

When you are a teacher it is not only delivering the lectures and the training but also the exams. And even nowadays I also do exams: job interviews. There is, however a significant difference between exams and job interviews. When you perform a job interview you face people you have never met before. On the other end, exams close a period of teaching, learning: you were delivering knowledge and helped them to develop skills.

I realized that this is a very significant difference. When a student fails the exam, the teacher also fails: I did not teach sufficiently, could not motivate to learn the subject, or at least awake his/her awareness. Sometimes I realized that the subject is simply not for the person. After all not everybody is meant to be a programmer. But this is also a failure if the discovery happens during the exam.

On the job interview, however, the candidate can be clever, can be dumb as earth: it does not qualify me. Even though it makes me happy to meet a candidate I would like to work with later and sad if I can not recommend the candidate. Before making false assumptions: I am not measured on success rate. No more glory or money comes to my pocket if I turn down a candidate or if I suggest for hiring.

Job interviews are usually successful. At least that is I feel, though I can not be sure. How come that a job interview is always successful? Comes from the definition of success: it does its job perfectly. If the candidate fits, he/she can go on. If the candidate is not appropriate for the position, the knowledge and skill set is not compatible with the requirements then this is better for the company as well as for the candidate if it is discovered during a one hour session. There were a lot of people, who passed and got recommended from my side. There were many, who were not appropriate for the position. Did I turn down anyone who was appropriate and I judged wrong? I can not now, but I hope I did not.

The job interview, the exam is full of stress. A bit less for me, a bit more for the candidate. This is the case even though the exam itself does change very few things in life. When it comes to the exam: all are decided. The candidate either knows what he/she has to know, or does not. There is only risk in the exam if the teacher is bad. It does sometime happen that the examiner turns somebody down because of bad mood, or the other way around: the candidate is successful fooling the examiner presenting more knowledge than really there is. As for the first one: I pay extreme care not to let my judgement been affected by mood. As for the second one, fooling the examiner, all I can say: lol.

There is a very small, though mathematically not zero, positive chance that somebody could fool me continuously in diverse subjects. I ask something about a subject and after a half sentence I am 99% sure when the candidate has no idea at all. I wait a few sentences and I know the next few questions to ask to disclose that remaining 1%. These are very important questions. It did happen that I asked the questions just for me being sure and I had to realize at that time the 1% change was winning. The candidate knew the subject, there was only problem with the communication skills (which are also very important, but I do Java tech interviews.) And there were example just the other way around as well.

Once I gave a helping hand to a job interview when we were searching someone knowledgeable about ITIL. We were searching the person because this special knowledge was needed for a given project and we did not have anyone being expert in ITIL. I also was not a ITIL expert, but in my previous position a few years back I did some work related to it and therefore I had at least the knowledge to reach for the spoon or the fork when it was served. The candidate came in and listed the different projects and tasks he performed utilizing ITIL. He was communicating overwhelming but somewhere in my brain there was an itchy feeling that most of it is empty talk. But I did not ask any question since I avoid asking question for which I do not absolutely know the perfect answer. (About this later.) At a certain point I asked him how he could create a DSS in the imagined situation we were actually talking about. He listed the different aspects for five minutes and he was such a good talker that I only suspected that he had no idea at all. Twenty minutes later at the end of the interview I asked him the question: what does DSS stand for? Abracadabra: no more empty talk. You know it or you do not know it. He did not.

And now the topic: why you should not ask something you do not yourself know the answer? Because the job interview or the exam is not for that purpose. I am not oraculom to know everything. I also do not expect the candidate to know everything. Why would anyone expect me to know all the answers. When you talk to a peer over a coffee, it is joyful to talk about your profession and learn new things perhaps on both sides. In an exam there is the examiner and the candidate. One of the job of the examiner to evaluate the exam (not the person, only the actual performance) and this works only when the examiner is above the candidate on some kind of knowledge scale, otherwise a refused candidate will not accept the result at least remains mentally disturbed. It is no good for anyone. It bad for the candidate as well as for the company. Knowledge, however, is not an ordered set. It is rather a multi dimensional vector space or something. You just can not say that Einstein was cleverer than Napoleon, or that Mary behind the buffet counter is cleverer than Kathy, the cleaning lady. Everybody has some knowledge that he or she knows better that someone else. If I do seem to be cleverer that the candidate in each and every topic that is raised during an interview: there is no problem. The candidate will accept the judgement. Even though it is obvious that I am not cleverer in all aspects. I can not be. But I can pay attention to seem like cleverer. That is the best solution. For both of us.

What happens if there is something he knows better and the topic comes up? If (s)he passes and I need not turn him/her down: it is OK. He or she will accept it. There is also no problem when the candidate does not have any chance to be cleverer than I am in the narrow area of my profession. This is sad, because it not only means that he is not appropriate for the position but it also means that there is a huge gap. Probably the candidate is not aware of his/her own knowledge and/or skill. I realize the situation early and the rest of the hour I spend teaching the candidate. I tell him/her (usually him, for some magical reason women are way better knowing their capabilities) what the problem is: what to read, how to practice. If I suspect some behavioral problem: why not to be a programmer. There are other positions, like project manager, business analyst, still in the wider area of the profession.

The real problem is, when the candidate’s skill and knowledge is somewhere in the middle. He/she just does not make it and still thinks that he/she is ok, and only the evil interviewer turned him/her down for false reasons. There was a single occasion when a candidate expressed openly his opposition about my decision refusing him. It was discomforting. It was discomforting for me, but I am sure that this was discomforting for him as well. It would have been better to protect him from this experience and having the false feeling that he was knowledgeable enough only the bastard interviewer turned him down. That is the way such a person usually experiences the situation. They are in the deny phase and many of them remains that phase until death or until Herr Alzheimer is knocking on the door. There was a certain and good reason I decided not to accept the person. And it was not the style and the arrogance. I am not evaluating behavior, though it certainly influences me. I also have psyche and I can not disclose feelings. Knowledge and skills. Those are the only things that matter. If I seem to be cleverer in all aspects it is better. At least safer. And I am extremely happy when I interview a person about whom I have the feeling that he/she will be a good co-worker a lot to learn from.

But there is another source of stress on a job interview. At the end you feel that you knew nothing. I had the same feeling when I was applying for my current position. What is the reason for that? The specialty of the situation: I ask something from the candidate. I know the answer, therefore I am not interested in the answer as content. I just want to know whether the candidate knows the answer. When he/she said enough I stop him/her. That time I know the knowledge level on the area the question covered, it would be waste of time to let the candidate go on talking about the obvious. Getting stopped when you know and then getting new questions all the time is extremely frustrating. To soothe the pain I always give positive feedback when I stop the candidate. I tell him/her that this was good. It helps.

The interview consists of two parts: there is a series of theoretical questions we talk about and there is a task. Different task each time. Well, being honest there is only a bunch of tasks and not a new one for each candidate. Somehow these task definitions slip out of the building. Once a candidate made the oblivious statement: “This is not the task I was expecting. My friend two weeks ago had to solve a different task.” Well, life is hard. Btw: he could solve the freshly pressed task easily.

There is a lot to learn from the two parts and how the two parts relate to each other. There are candidates who have great experience in technology, but can not solve a simple algorithmic task. At the same time there are freshmen, who had little experience but were genius solving the task. And it was also very valuable when a candidate was carving a solution on the white board that was different from the “official” one I created beforehand. It was shorter, faster and most importantly more readable and elegant. He is my colleague now.

As I mentioned before it is extremely important that I never evaluate the person. I only evaluate the actual performance during the interview. I never says that “Hey, buddy, you are dumb.” It can be argued and does no good to anybody. Pointless. The result of the interview is different though. Go or no go. But does the result of the interview correlate with the real skill and knowledge?

When I was teaching at the university a student raised this question and said that exams are not fair since they measure the actual performance and not the knowledge that they are supposed to. By that time it was not only informatics, but rather electric engineering they studied and thus I could refer to quantum mechanics that guarantees that you will never measure the physical quantity you are interested in. With the measure itself you affect the system, thus the result of the measurement will not be accurate. We also know that we hardly ever measure the physical quantity we are interested in. We are, for example, interested in the current. Instead we measure how much a pointer swings to the right by the forces of magnetic fields caused by the current. We prefer the situation when the measured quantity and the quantity we have the interest in depend on each other. If this can not be reached we are lucky to measure something that does not depend, but at least correlate. In real life, many times the measured thing has no relation at all to the quantity we would like to know. For example not the person, who drives dangerous is fined, but the one who drives fast.

However, as a bottom line statement, if the teacher, interview is professional, then the result of the interview and the skills and knowledge of the candidate correlate.

Advertisements

Partial redesign

The difference between refactoring and redesign is 10 minutes.

Ten minutes a lot of time. It is just enough to get drown. If you are young it can be enough for a quick something, for example to run a mile. And ten minutes is the difference between refactoring and redesign. Anything that takes longer than ten minutes can not be refactoring. That can be redesign.

Based on these I could imply that refactor is what you can do holding your breathe, but that won’t work. First of all there are only a few men, who can hold their breathe for ten minutes and usually they are not quite good at programming. At second thought you need brain power to do programming and the apnoe diving is not about deep sinking… thinking.

So now we know that redesign is something like refactor but it is longer. Horsey refactor is redesign. What about partial?

Partial redesign is practice when you can not perform a whole redesign and therefore you chop it up. There can be multiple reasons for not being able to perform the whole redesing in a single sprint besides being old. There may not be enough time. That is a 100% indicator: if you planned redesign in a sprint and the plan says that it will not fit, you can be very sure, no matter how bad you estimate that it will not fit.

When you chop up a redesign into small drops you have to ensure you have working code after each drop is swallowed. This is also a difference between refactor. When you do refactor you continuously have working code. (Or not.) You can do redesing also that way but sometimes you just decide not to do that since that may be too expensive requiring lot of temporary code that is needed only to keep the code alive during the process and that is not needed nor before neither after the redesign. (Lucky we are. Doing open heart surgery there is no such option.)

So you make partial redesign. And then comes the experience: if you successful with the first drop of the partial redesign it will stuck at that point. There will be no further time to continue with the rest of the redesign. Trust me, I am an engineer: it is the way it is going to be. In other words if the drops do not deliver value individually: better do not do them at all.

Making it clear and clean: If there is a scout camp that has to be redesigned and you want to replace the location of the kitchen and the latrine, do not start transforming the kitchen, because when you stop after the first partial redesign you will have two latrines and no place to eat. And then you will be in deep trouble.