Recently (around Sep 2012) I got a chance to interview a few persons (five) but I did not select any one of them. It was because that I interviewed them with a constraint that they should be able to write some good code. I also expected a couple of questions from them by framing my questions ambiguously. I wonder whether I did anything wrong there.
The first two were of 2 to 3 years of experience; the other one was with 1 to 1.5 years; the fourth one with 6 years of experience and the fifth one also with 1 to 1.5 years of experience.
The first two answered more or less very similarly (yes, both of them from same team).
They told about their application clearly. They were aware of ETL concepts. They also knew something about Unix (including vi editor). They also mentioned that they tuned a few queries by replacing IN with EXISTS. Both of them mentioned the same SQL tuning. They didn’t do any application level tuning. One of them told that it was based on guidance from senior members. And the other one cleverly mentioned that he tuned by himself (but he told he referred Google).
They were not exceptional but they were good enough to fill in the requirement we had.
Though with some IFs and BUTs, I was really impressed with them.
To finish-off the interview, I asked them to write a simple PL/SQL procedure which prints no. of employees in a particular department and no. of departments. (Well, the question is not exactly this, but sort of this). (Standard SCOTT schema; EMP;DEPT tables).
The 1st person wrote a SQL query without any line breaks (or) indentation. But perhaps he word-wrapped it. The 2nd one wrote a query without using the parameter which the procedure takes.
The 3rd person had 1.5 years of total experience but worked only 2 months each in 3 projects. He was on bench for the other 1 year. I did not expect anything. But he tried so hard to answer my questions. Though I appreciate that he wanted to answer, he should not have struggled at the time of interview. He should have put some efforts on interview preparation, at least. (Even I was rejected once for the same reason. I understood now why they rejected me 😉
The 4th person had 6+ years of experience which is similar to my level of experience. So, I hesitated to interview him. I thought that he might also be a better skilled person compared to me. But it was topsy-turvy. He spoke a fluent English but when I gave the same task to print the no. of employees for a particular department, he just wrote four words “CREATE OR REPLACE BEGIN” and then told “I don’t know”. I did not want to disappoint him by quitting the interview at that moment itself. So, I asked him a few more questions for which also I received the same answer “I don’t know”.
It is not me who decided on whether to select or not select. It is the time constraint we had in our project. We did not have enough time to train the persons. “There is no plan to attack. Attack is the only plan”. With enough time, I would have gone to take either the 1st or 2nd person.
I just asked “the programmers” to write 10-15 lines of code.
Am I asking inappropriate stuff?
I read somewhere in the web that hiring a programmer who does not write code is like hiring a driver who does not know what a clutch is.
After these four interviews, the fifth interview was a good one.
She had 2 years of experience. She use to write SQLs for generating reports but our project requirement was to migrate PL/SQL code to Perl. Whatever the question shooted from SQL, she answered perfectly. She wrote the SQL code for two queries. We selected her and she quickly learned Perl and PL/SQL in no period of time.
Happy on selecting her!