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!
Experiences and Lessons learned from my position as CTO in a small tech company in Israel. Follow me on twitter @ctoisrael. Comment if you want help with something that I have written about.
Showing posts with label management. Show all posts
Showing posts with label management. Show all posts
Monday, June 6, 2011
More on Hiring: or how to avoid moron hiring
Monday, May 30, 2011
Even I have a boss
I am a bridge between two worlds. I manage the technology of the company. Everything that is not financial or administrative I am responsible for. However when it comes down to it I have to do what I am told. The good news, it just has to get done. The bad news, they don't understand what needs to happen to get it done, and usually they think that it is always easy and could be done in a matter of minutes. In practice what this means is that some times as a programmer you can do something simple that the non techie people think is amazing and should have been time consuming. Other times the opposite is true.
Either way I'm screwed, if I do something quickly that they think should take a long time, it raises their expectations for the next time. If I have something that the bosses think should be straight forward, then they simply do not understand why it is that its taking so long.
This gets in the way of my work, I have to either spend time explaining the reasons why things take time or not get them done properly. In the past when I have been required to get out a new product or even a big feature I work hard on it to make sure its done and out there working, even if its missing a few things. Then I let smaller tasks take longer as I use the time to add in all the features left out of the bigger project. In the end most things get done, other things fall by the way side, usually by that time they don't matter anyway.
My bosses aren't bad bosses, in fact quite the opposite. They just don't always get it. Looking back on things I wish I had time to build the infrastructure we work on before going live. I have built it as needed and gone live as quickly as possible. Over time new versions and bug fixes have resulted in better software. I am left wondering whether this has worked out better than creating a whole system over a long period, testing, retesting, and then going live. Would it have just taken me longer to make the same mistakes.
As my staff grows and the codebase gets larger, I can implement better development standards. Better testing, better design, better implementation. I have more man hours available to me through my team, I can get things done faster and better at the same time. That means I will spend less time coding and doing other techie things and more time managing the staff and being a bridge from the bosses to the techies. I am their protector. I know how long it will take, I have been there, when the programmers say its going to take 2 weeks, I know it will take 4. But I know that I will put the right pressure on to get it done, and my bosses will be kept at bay knowing that I am competently managing the project. They will bug me, I will be the one disturbed leaving my staff to get on with it without the added pressure. Hopefully resulting in better products at the end.
Either way I'm screwed, if I do something quickly that they think should take a long time, it raises their expectations for the next time. If I have something that the bosses think should be straight forward, then they simply do not understand why it is that its taking so long.
This gets in the way of my work, I have to either spend time explaining the reasons why things take time or not get them done properly. In the past when I have been required to get out a new product or even a big feature I work hard on it to make sure its done and out there working, even if its missing a few things. Then I let smaller tasks take longer as I use the time to add in all the features left out of the bigger project. In the end most things get done, other things fall by the way side, usually by that time they don't matter anyway.
My bosses aren't bad bosses, in fact quite the opposite. They just don't always get it. Looking back on things I wish I had time to build the infrastructure we work on before going live. I have built it as needed and gone live as quickly as possible. Over time new versions and bug fixes have resulted in better software. I am left wondering whether this has worked out better than creating a whole system over a long period, testing, retesting, and then going live. Would it have just taken me longer to make the same mistakes.
As my staff grows and the codebase gets larger, I can implement better development standards. Better testing, better design, better implementation. I have more man hours available to me through my team, I can get things done faster and better at the same time. That means I will spend less time coding and doing other techie things and more time managing the staff and being a bridge from the bosses to the techies. I am their protector. I know how long it will take, I have been there, when the programmers say its going to take 2 weeks, I know it will take 4. But I know that I will put the right pressure on to get it done, and my bosses will be kept at bay knowing that I am competently managing the project. They will bug me, I will be the one disturbed leaving my staff to get on with it without the added pressure. Hopefully resulting in better products at the end.
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.
Labels:
hiring,
HR,
interview questions,
interviews,
management
Subscribe to:
Posts (Atom)