I didn't have time to write anything on Friday. I'm not quite sure why I didn't have the time, since my memories of being busy on the day don't extend to the reason why. Perhaps the work was so engrossing that it stole both my attention and my memory.
In fact, I do remember two notable events on Friday. One was that I think we made a breakthrough on discovering what it is I'm supposed to be making next. This is very good. Secondly, I attended a job interview. I was in the role of interviewer, rather than interviewee. I'm doing this a lot, and I find it both deeply depressing and strangely uplifting. I'll explain.
In a technical job interview situation, it's important to establish whether the person you're interviewing really knows their stuff. Now, the truth is that you can sit most intelligent people down and get them to do quasi-intelligent things, given enough time. With computers, there's enough possibility for trial and error that any imbecile can knock together something which has resembles a success. However, if you're trying to recruit people to join a team, it's important that the person you're dealing with is compatible with the team in terms of ability, and can communicate about shared knowledge in a way that's easily understood.
On technical interviews, we first make the candidate sit a test. Some people do poorly on the test and don't get an interview. Some do well on the test, but then prove to have been just lucky. There are some, though I'm yet to meet one, who do brilliantly on the test and then just ARE brilliant in an interview. Bear in mind, that I've never once set out to prove that a candidate is useless. Far from it. I like to cajole the candidate into saying things which I agree with so I can like them. Despite my best efforts, some recent interviews have left me feeling empty inside.
The truth is that we just want someone who really knows enough to join in a group of people who tend to know enough too. Then we can all get along, using our shared sense of knowing enough, and our shared language for expressing what we do and don't know. We use a simple diagram and very rarely do we use practices or patterns that you couldn't read out of a university-level textbook. Obviously, experience means a lot in this field. However, at interview, I'm expecting someone to be able to reel off stuff I remember learning in first and second year at university.
It shouldn't be difficult. I know that sometimes I'm trying to backseat drive the interview. I'm trying to give so much help to the candidate that all they need to say is one word and I'll be happy that they "get it". Of course, if they can't see what I'm getting at, then I'm making things impossible. But we're talking about the basics here. In some ways, maybe I'm making this hard for people who are basically clueless and really easy for the right person to shine in the interview. I don't know.
I remember my own interview, which was presided over by the person with whom I now interview, and another technically proficient colleague of his. At the time, I found their questions both frustrating AND easy. They were frustrating, because I'd be halfway through my explanation of something, and I was trying to give solid textbook explanations, and then they'd ask me the sort of question to which my instinctive reaction was "What? Don't you even know that? Surely it's a given?". At the time, I knew that they were asking the questions in order to test whether I knew it clearly or superficially, and to test whether I could hold my own in that situation. In some ways, it was fun. In fact, I think it was the interview I enjoyed the most of all I took, even though it had a difficult technical test before it started (which I guess I must have passed).
On Friday we had someone in from France. On paper he was well-qualified and fresh. Despite his low test score. Very low. We decided to go ahead with the interview, given that he had, on the face of it, travelled from France to be with us. Perhaps his experience wasn't best suited to the exact test we'd given him. We tried to make him get through the interview stage. I liked the guy. I think it's fair to say that most interviews are determined largely on personality. Sure there's an element of ability in choosing the right person for the job, but it's a bit like buying a house; you imagine yourself and your stuff in the house. So with interviews, you end up imagining the person on your team, working with you, doing what's necessary. Personality is important.
Yet, despite liking the guy, despite the cliches about not liking the French (in fact, I think I liked him because he was French), it wasn't enough. This guy didn't "get it". To define how much he didn't get it, I can put it like this. There's an early chapter in many books on programming which describes how a particular technique might be applied to a drawing program - one which puts different shapes on a piece of paper. This is a good example, which illustrates many of the techniques we hold dear. We started getting the candidate to design a solution to this problem. Given that I'm an ex-computer-graphics-programmer, I asked a simple question - "How would you get your program to calculate the bounding rectangle of all the shapes?". Now, I realise that there may have been a language barrier here, English to French, though I felt the conversation wasn't obstructed. I also drew a picture of what I meant. I also used the word "rectangle" a lot. What I expected was some sort of description of how all the rectangles around all the shapes could be somehow combined to make the enclosing rectangle. I expected some description of how to solve the problem that each shape's bounding rectangle would have to be calculated differently. In short, I expected a professional computer programmer's answer.
Maybe I expected too much. At one point our candidate was talking about a rectangle having four values (top, left, right, bottom), which is correct, and I suggested maybe modeling those four values as a "rectangle" in a separate bit of code. In truth, this is the "right" way to do it, especially since there's almost always some existing "rectangle" thing you can use from somewhre. The so-called "programmer" told me that it was a bad idea and unnecessary.
There will be three groups of reactions to the above:
A few paragraphs ago, I said I find it depressing when I meet these poor candidates. It's a shame. I can't believe people can get through university, probably with better degrees than I managed, and yet not know chapter 2 of the "book for beginners". However, I find it uplifting too. I do understand chapter 2. I reckon, I probably get most of chapter 3. Not only that, but I'm fair minded enough to interview people in a positive way, and yet not just go on personality. That's got to be a job worth doing.
In fact, I do remember two notable events on Friday. One was that I think we made a breakthrough on discovering what it is I'm supposed to be making next. This is very good. Secondly, I attended a job interview. I was in the role of interviewer, rather than interviewee. I'm doing this a lot, and I find it both deeply depressing and strangely uplifting. I'll explain.
In a technical job interview situation, it's important to establish whether the person you're interviewing really knows their stuff. Now, the truth is that you can sit most intelligent people down and get them to do quasi-intelligent things, given enough time. With computers, there's enough possibility for trial and error that any imbecile can knock together something which has resembles a success. However, if you're trying to recruit people to join a team, it's important that the person you're dealing with is compatible with the team in terms of ability, and can communicate about shared knowledge in a way that's easily understood.
On technical interviews, we first make the candidate sit a test. Some people do poorly on the test and don't get an interview. Some do well on the test, but then prove to have been just lucky. There are some, though I'm yet to meet one, who do brilliantly on the test and then just ARE brilliant in an interview. Bear in mind, that I've never once set out to prove that a candidate is useless. Far from it. I like to cajole the candidate into saying things which I agree with so I can like them. Despite my best efforts, some recent interviews have left me feeling empty inside.
The truth is that we just want someone who really knows enough to join in a group of people who tend to know enough too. Then we can all get along, using our shared sense of knowing enough, and our shared language for expressing what we do and don't know. We use a simple diagram and very rarely do we use practices or patterns that you couldn't read out of a university-level textbook. Obviously, experience means a lot in this field. However, at interview, I'm expecting someone to be able to reel off stuff I remember learning in first and second year at university.
It shouldn't be difficult. I know that sometimes I'm trying to backseat drive the interview. I'm trying to give so much help to the candidate that all they need to say is one word and I'll be happy that they "get it". Of course, if they can't see what I'm getting at, then I'm making things impossible. But we're talking about the basics here. In some ways, maybe I'm making this hard for people who are basically clueless and really easy for the right person to shine in the interview. I don't know.
I remember my own interview, which was presided over by the person with whom I now interview, and another technically proficient colleague of his. At the time, I found their questions both frustrating AND easy. They were frustrating, because I'd be halfway through my explanation of something, and I was trying to give solid textbook explanations, and then they'd ask me the sort of question to which my instinctive reaction was "What? Don't you even know that? Surely it's a given?". At the time, I knew that they were asking the questions in order to test whether I knew it clearly or superficially, and to test whether I could hold my own in that situation. In some ways, it was fun. In fact, I think it was the interview I enjoyed the most of all I took, even though it had a difficult technical test before it started (which I guess I must have passed).
On Friday we had someone in from France. On paper he was well-qualified and fresh. Despite his low test score. Very low. We decided to go ahead with the interview, given that he had, on the face of it, travelled from France to be with us. Perhaps his experience wasn't best suited to the exact test we'd given him. We tried to make him get through the interview stage. I liked the guy. I think it's fair to say that most interviews are determined largely on personality. Sure there's an element of ability in choosing the right person for the job, but it's a bit like buying a house; you imagine yourself and your stuff in the house. So with interviews, you end up imagining the person on your team, working with you, doing what's necessary. Personality is important.
Yet, despite liking the guy, despite the cliches about not liking the French (in fact, I think I liked him because he was French), it wasn't enough. This guy didn't "get it". To define how much he didn't get it, I can put it like this. There's an early chapter in many books on programming which describes how a particular technique might be applied to a drawing program - one which puts different shapes on a piece of paper. This is a good example, which illustrates many of the techniques we hold dear. We started getting the candidate to design a solution to this problem. Given that I'm an ex-computer-graphics-programmer, I asked a simple question - "How would you get your program to calculate the bounding rectangle of all the shapes?". Now, I realise that there may have been a language barrier here, English to French, though I felt the conversation wasn't obstructed. I also drew a picture of what I meant. I also used the word "rectangle" a lot. What I expected was some sort of description of how all the rectangles around all the shapes could be somehow combined to make the enclosing rectangle. I expected some description of how to solve the problem that each shape's bounding rectangle would have to be calculated differently. In short, I expected a professional computer programmer's answer.
Maybe I expected too much. At one point our candidate was talking about a rectangle having four values (top, left, right, bottom), which is correct, and I suggested maybe modeling those four values as a "rectangle" in a separate bit of code. In truth, this is the "right" way to do it, especially since there's almost always some existing "rectangle" thing you can use from somewhre. The so-called "programmer" told me that it was a bad idea and unnecessary.
There will be three groups of reactions to the above:
- Programmers who know their stuff will go "What!?"
- People who don't understand programming will probably try to stifle a yawn, assuming they've even read this far
- People who do understand it, but don't give a damn, will feel like they may have missed the point, or just feel like I'm being all geeky again
A few paragraphs ago, I said I find it depressing when I meet these poor candidates. It's a shame. I can't believe people can get through university, probably with better degrees than I managed, and yet not know chapter 2 of the "book for beginners". However, I find it uplifting too. I do understand chapter 2. I reckon, I probably get most of chapter 3. Not only that, but I'm fair minded enough to interview people in a positive way, and yet not just go on personality. That's got to be a job worth doing.
0 Comments:
Post a Comment
<< Home