Readers of this blog will know I have a huge axe to grind about bad HR, particularly here in Israel (here, here, here and here). Bad interviews, bad interview questions, not bothering to filter candidates properly. As my company grows and I start to look for new people, I strive to find better techiques for interviewing and hiring, that I have mentioned as potential solutions in my earlier posts, to getting that perfect match. I have just found Skills, a company that may go a long way to ensuring that the right CVs land on my desk. I look forward to using them the next time I am hiring.
I got to them from browsing the jobs on another site that I am excited about Gigantt. Not that I am looking for a job, when I seen new companies I always like to look at what kind of people they are hiring. It gives me a wider view of what they do and how they go about doing it. Gigantt looks like an interesting and very userfriendly project planning tool and maybe just what I need right now. Waiting to hear when I can start beta testing.
Showing posts with label hiring. Show all posts
Showing posts with label hiring. Show all posts
Sunday, February 5, 2012
Wednesday, January 4, 2012
Interview questions - some ideas and why they are helpful
I have been away on vacation and I got some time to read, so I dug in to Black Swan by Nassim Nicholas Taleb. He is an excellent and thought provoking writer. I am reading this book extra slowly as I like to stop after every page or so and think about what he has written.
In the book he poses some interesting questions and I think some of them may be interesting to use as interview questions. So that I don't leave you in suspense I will put the questions here and allow you to think about them while I give an further introduction to what I want to achieve, which is not necessarily the point that Taleb was making.
A) If you had no restrictions on folding a piece of paper and could physically fold it 50 times. How tall approximately would the folded paper be?
B) Given the number sequence 2,4,6. Find the rule that determines the sequence. You give three three number sequences that I will answer yes or no to if then conform to the rule of the sequence.
C) If I flipped a fair coin 100 times and it came up with 99 heads, what is the probability that the next flip will be tails?
I have talked before about stupid interviews that waste my time as well as the time of the employees of the company that has been interviewing me. I should note that I have been asked interesting questions and puzzles in some interviews and one or two silly ones too. The one that springs to mind here is when I got asked if I could have any superpower what would it be. If you are an interviewer asking that question be damn sure you have a good interpretation of the responses to this question. Some people, even geeks, are just not in to comics and superheroes. My answer to that question was that it is very hard to give an answer that couldn't be sinister. Flying is probably pretty harmless, but mind reading/ control, invisibility, super strength are all things that could be used for bad just as easily as for good. I didn't think it was a good question, but I tried to answer it as best as I answer good questions, by showing that it was flawed. I then asked the interviewer the same question. He gave me an unsatisfactory answer. I should have asked him how he interpreted my answer, I don't think it made any difference to the result of the interview. I will concede here that if the future employer is a huge comic book fan as are the team that the position is for, then it may be a useful tool for assessing how good a fit it will be for the future employee.
Additionally mathematical and logic puzzles may not give the best metrics for good employees when used incorrectly. Know what you want to get out of the answers, it is not good enough to find a question on the internet and ask it hoping to determine that the answer will give and indication of whether the potential employee is capable of thinking outside the box or has above average logical reasoning skills.
Looking at the questions in a little more detail:
A) Firstly the answer I don't want to hear is that a piece of paper no matter what the size cannot be folded more than 7 times (This is the current accepted number for a regular piece of paper, though apparently a girl managed 12 times and came up with and equation to prove it). I am not testing knowledge, and no one likes a smart ass. Additionally I asked the question stating there were no physical restrictions.
I want to see the reasoning and thought process. First state your assumptions. A piece of regular printer paper is clearly not 1cm thick. I would accept the candidate making the assumption 1mm, though that is a factor of 10 out. It is much closer to 0.1mm, however I am not testing knowledge here just reasoning. Lets assume it is 1mm we can always divide by 10 to get the real answer later. It should be fairly clear that the answer is 50^2 * thickness. I do not expect the exact answer here. But I would like an order of scale. I have a short cut. 10^2 is 1024. So for every ten folds the height of the paper goes up by a factor of 1000, this means that the answer is 10^15 times the thickness. If the thickness is 1mm then the length is approximately 1,000,000,000 km. The real answer given the actual thickness is 100,000,000km, about two thirds the way from hear to the sun.
I have a confession, I am horrible at mental arithmetic. I could train myself to be better at it, but I guess I just got lazy. If I need to add something up accurately I usually have a computer, calculator or even a pen and paper handy. What I am good at is estimating. This is phenomenally powerful. The ability to this well and accurately enough can be more useful than just plugging the numbers into a calculator. If I look at some calculation and estimate the answer first, it is easy to see errors if I make a mistake when plugging the actual numbers into a computation device. I attribute this lesson to Mr Roger Hand my A-level physics teacher, thank you so much for this it has been an invaluable tool throughout my life.
I like to know the scale of big numbers. It puts things in perspective, it is not the most important thing here but you can expand on the estimation aspect by equating a large number with something that it represents. 100 million km really doesn't mean that much to me. The distance to the moon is 400 thousand km, so it is considerably more than that and as I said two thirds the distance to the sun. If someone said its about the distance to the sun, then that would be satisfactory. It's about the right order of magnitude.
Enough about estimation. The other skill this highlights is knowledge and understanding of powers of two. I honestly wouldn't care if the candidate had to write down the powers of two, as long as they stopped at 10. It should be obvious at that point how to short cut to the answer from there.
I will highlight why these two things are necessary for a candidate that I would employ. We deal with large numbers. Millions and tens of millions of dollars. We multiply that by fractions of pennies. If we are producing results that are factors of 10 out is should be obvious from an estimate done before that calculation. This is pretty critical as we are talking about real money transactions and position management. The powers of two should be second nature to any Computer Science graduate. We recently had to send out messages to a system in byte codes. I spent far too much of my time explaining the binary, decimal and Hex representations of these strings to my employee. It was immensely frustrating for both of us, but we got through it. In a world of high level languages, it is too easy to forget the roots of computing lies in bits and bytes.
B) What three sequences did you think of? 1,3,5; 8,10,12; 20,22,24. The answers would be yes, yes and yes. Your conclusion would be increments of 2. You would be wrong. That answer is clearly a possibility but not what I was looking for. You may argue that it fits your sequences. Of course so does the correct answer. You may get defensive, and say how was I supposed to determine that. To which I would answer that you must try to find a sequence that doesn't fit. Using the following 3 sequences: 1,3,5; 5,10,15; 6,5,3, would result in yes, yes and no. 1,3,5 confirms your initial assumption that the number increment by 2. 5,12,15 disproves that the increments must be 2 and that they must be regular. Finally 6,5,3 shows that the sequence cannot be descending. The answer is that the sequence must be ascending, and that is all.
It can only be shown by finding counter examples as well as examples. If you just go about proving yourself right with each suggestion you will get locked in a corner. A candidate able to simply solve this should be good a bug testing. A successful bug test is one that fails, any other bug test does not show evidence of a bug. This must not be confused with show evidence of no bugs. A semantic difference for sure, but a very important one.
C) This takes me back to school. The concept of a fair coin and a fair die. That means that it is not unfairly weighted, there is no bias. It should conform to probability. Of course if the question was I flipped a fair coin 5 times and it was heads. The probability of a tail would reasonably still be 50%. I would not expect anything else. However as the numbers grow the statistics should tend towards conforming to the true probabilities. I would reasonably expect around 60/40 one way or another for 100 tosses and maybe 55/45 for 1000 flips. To have 99 out of 99 flips come up the same, you would be a little foolish to assume that I was telling the truth about it being a fair coin. So OK, its a trick question of sorts, but it is more of a real world problem. I have been told something, but I have evidence to prove otherwise, now I must draw a reasonable conclusion. I am not trying to trick you, I am trying to get you to solve a problem of two conflicting bits of information. I want to here that it should be 50/50 if its a fair coin, but it doesn't seem to be a fair coin. Equally I do not want to hear that it's clearly going to be a 100th head. You would have ignored my statement that its a fair coin, and assumed that just because something has happened one way 99 times in a row then it is going to be the same on the 100th time.
Here we see that that real world problems do not always fit into classroom style examples. The world fits the normal distribution less than we think it does. It also gives an example of how probability and statistics fit together. A reasonable candidate should understand and show this in their discussion of the question.
I hope this has given and potential interviewers some ideas on what to ask and how to understand the answers they get. Please comment and let me know what you think about this, and if you have any other suggestions.
Saturday, June 11, 2011
Programming tests: is there a shortcut
For those of you not following my tweets, I tweeted the other day about http://www.codeeval.com/. This is a great service that basically allows you to create job applications online (no big deal) with the bar to sending it in as passing the programming problem that it presents (very big deal). This could be a big help in theory. You can see how organised they are about coding, for a good enough problem it will show their problem solving skills and their thought processes.
I have a problem with this though, there seems to be no way to block the applicant looking the answers up. There are timed problems, but copy paste is pretty quick once you have found the algorithm on the web. In addition it has a plagiarism detector so you can see if candidates are sharing their answers. This could actually be used by submitting answers that you find on the web. Once a candidate uses the same answers from searching the web the plagiarism detector will flag them.
Considering all of this I would still want to do a reasonable live test as well. My main reason being efficiency of programmers is quite important to me. I cannot stand sitting with someone who is repetitively doing the same slow process over and over again. I saw recently a description of programmers as being "Inherently lazy with just the right amount of motivation." This description presents us with someone that is too lazy to keep doing something that takes 2 minutes over and over again, but will be motivated to spend an hour finding or writing a solution that will make this process automatic. I love this, its true about me, and about many other coders. I remember hearing a quote by Richard Stallman, Founder of the GNU project, who said that he would have never got it done if he wasn't lazy. I cannot find any reference for that right now so don't take me at my word. But I am pretty sure that I read it in Rebel Code. I digress...
I want to see not just efficient solutions to problems but efficient working method to get there. There is nothing more painful than watching someone click on the file menu and select copy and paste, even using right click in an editor, everyone should know ctrl^c ctrl^v. Thats ok, I doubt you would come across many programmers that don't, but there are more examples of things that people can do to work quicker. Selecting, single words and lines are very easy to select by double or triple clickling, no need to be exact about highlighting all the letters. The less a mouse is used the better. Users of VI and EMACS will be proficient at this and will probably be mouse free in other environments too. Additionally X windows users will know that if you highlight something it is copied to the clipboard and can be pasted using a single middle click. Saving too, most of the time its just ctrl^s but not doing it will mean you get prompted to save a few seconds are required of a mouse click, these things do add up. It sounds like I am talking about some pretty irrelevant or small things but trust me when you watch some one who doesn't use these things its slow.
I am not the best at these things, but I definitely notice when they are not being done. When I spent more time in EMACS and VI I taped a list of common commands on the wall behind my monitor. The more I used them the less I had to refer to the list and the faster I got at using these wonderful tools.
One weird thing that I have is about searching through code. I get it if you don't know the code, but there are many shortcuts especially in the IDEs to make it quicker. I much prefer ctrl^j to ctrl^f in Eclipse, but what I prefer the most is being familiar enough with the code to know where to go. Don't search just go straight there. Someone who can type quick enough and knows the shortcuts to search should be able to beat me in a large file. However its the familiarity with the code that I am looking for. If you are my programmer and you don't know the code well enough how can you solve bugs or make feature changes. I am not talking here about new code, I am talking about code the programmer has written themselves. Searching is fine, I would never say to someone that they cannot do it, but I want to see some indication that the code they have spent a few weeks writing is somehow bouncing around their heads.
I have a problem with this though, there seems to be no way to block the applicant looking the answers up. There are timed problems, but copy paste is pretty quick once you have found the algorithm on the web. In addition it has a plagiarism detector so you can see if candidates are sharing their answers. This could actually be used by submitting answers that you find on the web. Once a candidate uses the same answers from searching the web the plagiarism detector will flag them.
Considering all of this I would still want to do a reasonable live test as well. My main reason being efficiency of programmers is quite important to me. I cannot stand sitting with someone who is repetitively doing the same slow process over and over again. I saw recently a description of programmers as being "Inherently lazy with just the right amount of motivation." This description presents us with someone that is too lazy to keep doing something that takes 2 minutes over and over again, but will be motivated to spend an hour finding or writing a solution that will make this process automatic. I love this, its true about me, and about many other coders. I remember hearing a quote by Richard Stallman, Founder of the GNU project, who said that he would have never got it done if he wasn't lazy. I cannot find any reference for that right now so don't take me at my word. But I am pretty sure that I read it in Rebel Code. I digress...
I want to see not just efficient solutions to problems but efficient working method to get there. There is nothing more painful than watching someone click on the file menu and select copy and paste, even using right click in an editor, everyone should know ctrl^c ctrl^v. Thats ok, I doubt you would come across many programmers that don't, but there are more examples of things that people can do to work quicker. Selecting, single words and lines are very easy to select by double or triple clickling, no need to be exact about highlighting all the letters. The less a mouse is used the better. Users of VI and EMACS will be proficient at this and will probably be mouse free in other environments too. Additionally X windows users will know that if you highlight something it is copied to the clipboard and can be pasted using a single middle click. Saving too, most of the time its just ctrl^s but not doing it will mean you get prompted to save a few seconds are required of a mouse click, these things do add up. It sounds like I am talking about some pretty irrelevant or small things but trust me when you watch some one who doesn't use these things its slow.
I am not the best at these things, but I definitely notice when they are not being done. When I spent more time in EMACS and VI I taped a list of common commands on the wall behind my monitor. The more I used them the less I had to refer to the list and the faster I got at using these wonderful tools.
One weird thing that I have is about searching through code. I get it if you don't know the code, but there are many shortcuts especially in the IDEs to make it quicker. I much prefer ctrl^j to ctrl^f in Eclipse, but what I prefer the most is being familiar enough with the code to know where to go. Don't search just go straight there. Someone who can type quick enough and knows the shortcuts to search should be able to beat me in a large file. However its the familiarity with the code that I am looking for. If you are my programmer and you don't know the code well enough how can you solve bugs or make feature changes. I am not talking here about new code, I am talking about code the programmer has written themselves. Searching is fine, I would never say to someone that they cannot do it, but I want to see some indication that the code they have spent a few weeks writing is somehow bouncing around their heads.
Monday, June 6, 2011
More on Hiring: or how to avoid moron hiring
I have written about hiring before and I felt there was more I could say about it. I do not have a huge amount of experience of searching for jobs elsewhere but here in Israel I feel the whole process is lacking. I am originally from the UK and though I spent most of my time since high school studying at university I did apply for some jobs. One experience jumps to mind. I had a phone interview with a big consulting firm. At the time I was not so confident with my programming ability. I was young and naive and I guess what ever I said came off as, "I don't like programming, I don't want to do it." I was told later by HR from this company that I did not progress because I said that I did not like programming. (things have changed considerably for me). There was no attitude of 'lets interview him some more and see how it goes.' Later interviews, here in Israel, with other big companies have resulted in my not progressing for good reason, failing to pass whatever puzzles, tests and problems that were set out for me (Google, Bloomberg, and Brevin Howard), and being offered a job by Intel because I did pass these tests. These are big companies, with HR that has been developed over many years. They are efficient and are able to take on the best candidates.
So why here do we have this attitude of wasting interviewers' and candidates' time by interviewing them when they are inappropriate. Additionally at my previous company, for all the positives that they gained from taking a chance and hiring me, there were many people who were hired who were let go in 3 months or less because they were just unsuitable for the job. The turn over of employees in my time there was ridiculous. I suggested that they paid more to new candidates in order to attract better people, they didn't believe me and stated that there just isn't anyone out there. This I find hard to believe.
Testing is the way forward. As I stated in my last post on this topic it should be not just one question but a number designed to demonstrate many different abilities and not to prejudice a decision by the candidate failing at one thing. There are certain things that I want to know from a candidate that I should implement for the next interview process. I work with linux and the commandline a lot. I use Cygwin on my windows machines to interface with my linux boxes and more importantly to gain the power of bash to manipulate files in windows. Where am I going with this. If a candidate claims knowledge of linux I have an easy question to test something basic. Given the directory C:\src\ (or whatever) find all the java files in that directory and its sub directories that have classes that implement a certain interface. Lets say the action listener interface. I could even sit them at my keyboard and get them to do it. If the candidate has no understanding of linux this would be impossible. If they do but are unfamiliar with the syntax of grep or find for example I would be happy for them to spend 5 mins reading the man pages. I would expect an answer like:
grep -Ri ActionListener * | grep -v svn | grep implements
I would expect to see them remove the svn directories from the result and refine the use of ActionListener to only when it is implemented in the class and not used as an anonymous class.
This is an ideal list of things a candidate should know. Its use is explained in a link near the bottom. A good score would certainly make a an ideal sounding candidate. But these things especially the in depth knowledge of computer science things like sorting and search algorithms do not always translate well into the best employees. Discussed in a further article about the hiring process, it seems different approaches can be taken and are valid.
Another thing that I would like to see is their participation in something like StackOverflow, Experts exchange or some other forum of this type. Alternatively involvement in an open source project.
Regular expressions are such a useful tool. Everyone should know about them and how to use them. Again its easy to set up a simple test to discover the number of words of a certain type in a give text file. I am reminded of this wonderful xkcd cartoon.
Finally here is another article on some positive traits to look out for in a new candidate.
Happy hiring!
So why here do we have this attitude of wasting interviewers' and candidates' time by interviewing them when they are inappropriate. Additionally at my previous company, for all the positives that they gained from taking a chance and hiring me, there were many people who were hired who were let go in 3 months or less because they were just unsuitable for the job. The turn over of employees in my time there was ridiculous. I suggested that they paid more to new candidates in order to attract better people, they didn't believe me and stated that there just isn't anyone out there. This I find hard to believe.
Testing is the way forward. As I stated in my last post on this topic it should be not just one question but a number designed to demonstrate many different abilities and not to prejudice a decision by the candidate failing at one thing. There are certain things that I want to know from a candidate that I should implement for the next interview process. I work with linux and the commandline a lot. I use Cygwin on my windows machines to interface with my linux boxes and more importantly to gain the power of bash to manipulate files in windows. Where am I going with this. If a candidate claims knowledge of linux I have an easy question to test something basic. Given the directory C:\src\ (or whatever) find all the java files in that directory and its sub directories that have classes that implement a certain interface. Lets say the action listener interface. I could even sit them at my keyboard and get them to do it. If the candidate has no understanding of linux this would be impossible. If they do but are unfamiliar with the syntax of grep or find for example I would be happy for them to spend 5 mins reading the man pages. I would expect an answer like:
grep -Ri ActionListener * | grep -v svn | grep implements
I would expect to see them remove the svn directories from the result and refine the use of ActionListener to only when it is implemented in the class and not used as an anonymous class.
This is an ideal list of things a candidate should know. Its use is explained in a link near the bottom. A good score would certainly make a an ideal sounding candidate. But these things especially the in depth knowledge of computer science things like sorting and search algorithms do not always translate well into the best employees. Discussed in a further article about the hiring process, it seems different approaches can be taken and are valid.
Another thing that I would like to see is their participation in something like StackOverflow, Experts exchange or some other forum of this type. Alternatively involvement in an open source project.
Regular expressions are such a useful tool. Everyone should know about them and how to use them. Again its easy to set up a simple test to discover the number of words of a certain type in a give text file. I am reminded of this wonderful xkcd cartoon.
Finally here is another article on some positive traits to look out for in a new candidate.
Happy hiring!
Wednesday, May 25, 2011
Hiring right
I saw this the other day:
http://www.inc.com/ss/7-unconventional-ways-hire-best-tech-talent#0
While I like the idea, it was truly impractical for my needs. Having said that I do feel that I could have been more thorough in my interviewing process.
Lets start at the beginning. Over the past few years I have been to a few interviews. I have had some tough questions. I have done OK in some and not so great in others. Three companies, two of which I have had multiple interviews, where I have basically been told at the end of it, "we like you but you don't have any experience in Java (or what ever it was at the time that I didn't know)".
I have to say this is particular annoying and a huge waste of both my and their time. If they were looking for a Java programmer why were they interviewing me. I didn't have it on my CV. Ok I have a few interesting things on my CV but at the time Java wasn't one of them. I said during the interview that I didn't know Java right now but I could learn. In fairness most people when they are looking for a Java programmer they are looking for someone with 3 to 5 years experience that can hit the ground running. But again they shouldn't have looked at me. So the conversation continues. "Really you can just pick it up, huh. What evidence can you present us with that would convince me?" Well for my current (at the time) job I learnt Perl Javascript and SQL and became proficient enough at them to run my own two man projects within a month. "Oh thats interesting, what about a real language?" Harsh! Though again I get it, no proof that I have an understanding of OOD, but having said that I believe it is possible to learn the basics in a week reading on the internet. The fact that this guy was so conceited that he thought learning Java was harder than the 3 languages I had to get to grips with prior to this, was a little narrow minded. Aside from reading about Perl in the week running up to the start of that job everything else was done offline. We were on a closed system with no internet in the office. That meant man pages (perldoc to be specific). Javascript and SQL had to be learned from reading pre existing code and talking to others in my office. All done with Emacs, no fancy IDE like Eclipse which does so much for you. So a little context helps when responding to answers.
So I finally landed a job, this job, I didn't know Java but I had a month to read about it before I started. I played around a little and the rest I learned as I went along. Its been two years. And you know what, I rate myself pretty highly. How do I know this. I hired someone. Someone I expected to blow me out the water in terms of coding. You know what, she has 9 years of coding experience, c, c++ and Java. As I understand it 3 years of each. She doesn't know much about Threads or Swing or Sockets. She is proficient at what she does know. But somehow after all her time doing this, I still have a greater breadth of knowledge.
(Additionally I was on track for becoming Rookie of the Year in Java on Experts Exchange but my responsibilities took up too much of my time to actually continue doing all this work for free. I will post more about EE and Stackoverflow later.)
I am the CTO, I need to know everything (not saying that I do, just that I should have a wide range of skills and knowledge). I am confident that my employee will be fine, it will start off slow and she will improve, but there is a lesson. Assuming that someone who has the experience you think is necessary is not necessarily the best indicator of whether they will do well in your company. I believe that had these companies taken a chance on me then they would have been pleasantly surprised by what I could have achieved. They weren't willing to take that chance, and why should they they have I am sure they could have found plenty of other coders out there.
This is the lesson of hiring, you never know what you are going to get. You want some one great, with experience, broad knowledge, in depth understanding and the ability to pick up things they don't already know. You try to test for this. But its still hard to know for sure.
Lets step back again, I have had some interviews where I have been asked to solve some problems, or give examples of code. Generally these have gone badly for me. Personally this is where I crack. Its not the pressure I just don't think well like this. And worst of all I don't end up thinking quickly, which is the worst part, as they not only want to see the correct solution but they want it done quickly. So I decided that I would not ask these types of questions, firstly I don't know how to interpret the results, and secondly if they know how to do this already then it doesn't show me where they are lacking, and if they don't know how to do it then it doesn't show me other areas where they are positive.
Back to my recent hire. I have spent too long going over basic Hex and Binary. This stuff should be second nature to a true CS grad, granted many coders might not be CS grads, but I have a CS grad and I wanted one specifically. The reason: because they should be able to solve problems like this. I am beginning to see the logic in some of these harder interviews and the fact that (big headedly) I may have "slipped through the net", anyone that answers the type of problems I was getting from Google, Bloomberg and Brevin Howard deserves to be there or at least get another interview. It shows a basic level of knowledge/understanding/problemsolving skills.
So for the next interview I will ask the following:
given the a byte array which has the following bits:
sfff ffnn nnnn nnnn nnnn nnnn nnnn nnnn
show me how to extract the one bit sign s, the 5bit denomenator reference f, and the 26 bit numerator n.
the answer would be pseudo code that shows a bit mask for n
a shift and a bit mask for f
and a shift for s.
In fairness to my employee she did solve the big problem that we were having that the byte array we were receiving looked different from the one we were trying to send. The problem was that we were receiving the byte fields as little endian but reading them as big endian.
So now one gets in the door with out understanding these concepts. I am going to keep track of these problems for the future. If any more crop up I will be noting them here and using them for interviewing. I propose a system by which any one incorrect answer will not be the end of the world. A scoring system will be used to decide if the candidate has a satisfactorily broad knowledge and with good problem solving skills.
More on this as time goes on.
http://www.inc.com/ss/7-unconventional-ways-hire-best-tech-talent#0
While I like the idea, it was truly impractical for my needs. Having said that I do feel that I could have been more thorough in my interviewing process.
Lets start at the beginning. Over the past few years I have been to a few interviews. I have had some tough questions. I have done OK in some and not so great in others. Three companies, two of which I have had multiple interviews, where I have basically been told at the end of it, "we like you but you don't have any experience in Java (or what ever it was at the time that I didn't know)".
I have to say this is particular annoying and a huge waste of both my and their time. If they were looking for a Java programmer why were they interviewing me. I didn't have it on my CV. Ok I have a few interesting things on my CV but at the time Java wasn't one of them. I said during the interview that I didn't know Java right now but I could learn. In fairness most people when they are looking for a Java programmer they are looking for someone with 3 to 5 years experience that can hit the ground running. But again they shouldn't have looked at me. So the conversation continues. "Really you can just pick it up, huh. What evidence can you present us with that would convince me?" Well for my current (at the time) job I learnt Perl Javascript and SQL and became proficient enough at them to run my own two man projects within a month. "Oh thats interesting, what about a real language?" Harsh! Though again I get it, no proof that I have an understanding of OOD, but having said that I believe it is possible to learn the basics in a week reading on the internet. The fact that this guy was so conceited that he thought learning Java was harder than the 3 languages I had to get to grips with prior to this, was a little narrow minded. Aside from reading about Perl in the week running up to the start of that job everything else was done offline. We were on a closed system with no internet in the office. That meant man pages (perldoc to be specific). Javascript and SQL had to be learned from reading pre existing code and talking to others in my office. All done with Emacs, no fancy IDE like Eclipse which does so much for you. So a little context helps when responding to answers.
So I finally landed a job, this job, I didn't know Java but I had a month to read about it before I started. I played around a little and the rest I learned as I went along. Its been two years. And you know what, I rate myself pretty highly. How do I know this. I hired someone. Someone I expected to blow me out the water in terms of coding. You know what, she has 9 years of coding experience, c, c++ and Java. As I understand it 3 years of each. She doesn't know much about Threads or Swing or Sockets. She is proficient at what she does know. But somehow after all her time doing this, I still have a greater breadth of knowledge.
(Additionally I was on track for becoming Rookie of the Year in Java on Experts Exchange but my responsibilities took up too much of my time to actually continue doing all this work for free. I will post more about EE and Stackoverflow later.)
I am the CTO, I need to know everything (not saying that I do, just that I should have a wide range of skills and knowledge). I am confident that my employee will be fine, it will start off slow and she will improve, but there is a lesson. Assuming that someone who has the experience you think is necessary is not necessarily the best indicator of whether they will do well in your company. I believe that had these companies taken a chance on me then they would have been pleasantly surprised by what I could have achieved. They weren't willing to take that chance, and why should they they have I am sure they could have found plenty of other coders out there.
This is the lesson of hiring, you never know what you are going to get. You want some one great, with experience, broad knowledge, in depth understanding and the ability to pick up things they don't already know. You try to test for this. But its still hard to know for sure.
Lets step back again, I have had some interviews where I have been asked to solve some problems, or give examples of code. Generally these have gone badly for me. Personally this is where I crack. Its not the pressure I just don't think well like this. And worst of all I don't end up thinking quickly, which is the worst part, as they not only want to see the correct solution but they want it done quickly. So I decided that I would not ask these types of questions, firstly I don't know how to interpret the results, and secondly if they know how to do this already then it doesn't show me where they are lacking, and if they don't know how to do it then it doesn't show me other areas where they are positive.
Back to my recent hire. I have spent too long going over basic Hex and Binary. This stuff should be second nature to a true CS grad, granted many coders might not be CS grads, but I have a CS grad and I wanted one specifically. The reason: because they should be able to solve problems like this. I am beginning to see the logic in some of these harder interviews and the fact that (big headedly) I may have "slipped through the net", anyone that answers the type of problems I was getting from Google, Bloomberg and Brevin Howard deserves to be there or at least get another interview. It shows a basic level of knowledge/understanding/problemsolving skills.
So for the next interview I will ask the following:
given the a byte array which has the following bits:
sfff ffnn nnnn nnnn nnnn nnnn nnnn nnnn
show me how to extract the one bit sign s, the 5bit denomenator reference f, and the 26 bit numerator n.
the answer would be pseudo code that shows a bit mask for n
a shift and a bit mask for f
and a shift for s.
In fairness to my employee she did solve the big problem that we were having that the byte array we were receiving looked different from the one we were trying to send. The problem was that we were receiving the byte fields as little endian but reading them as big endian.
So now one gets in the door with out understanding these concepts. I am going to keep track of these problems for the future. If any more crop up I will be noting them here and using them for interviewing. I propose a system by which any one incorrect answer will not be the end of the world. A scoring system will be used to decide if the candidate has a satisfactorily broad knowledge and with good problem solving skills.
More on this as time goes on.
Subscribe to:
Posts (Atom)