Interviewing

Interviewing

Recently I had a discussion on one of the forums (here but polish only sorry) about the Interviewing process when applying for a C#, Java position.

Generally people tend to split into two groups:

1. the algorithmic only - the test is composed only from algorithmic problems
2. the object oriented only - the test is a set of framework and architecture questions.

Both have some good points about their Interviewing process.

There is another group though but this group has 0 good points if you ask me, those are the triva questions tests, example:

"Having a bit variable in SQL set it to -1 what the output will be?"

Now WHY THE HELL I NEED TO KNOW THAT!? Will this make a better programmer? NO, is this common in ALL SQL standards? NO.

Test Types

But let's go back to the two groups that have some very valid points:

The algorithmic only test will test your thinking and your ability to solve problems, but then nowadays It devs work on data centric business applications and servers where those algorithmic solving problems don't apply mostly, and besides having a fast algorithm applies that the code will be very messy and hard to understand, and this is not desired. Business applications (CRM, Finance, Consulting, Management) change constantly so the more focus goes to good, flexible architecture then small algorithms. But then again you'l never know what the next project going to be and wouldn't it be cool to work on a database engine? then you need to know tour way around algorithms.

There is another problem I see with this, that this is not a way to test your thinking skills. The science has shown when people are faced with problems in certain domain they get better at it, so if a candidate has 3 years of experience in Tree algorithms he will be excellent in this domain but can totally fail when it comes to problems that require matrices, so when facet with a matrix problem on a test does this apply that he cannot think? Hell NO this only means that in that particular domain he has little experience.

The object oriented only test will test your skills at a certain language or the object oriented problems like inheritance, static functions, and problems of designing classes that do XYZ. For most of the business applications this should be sufficient, you get abstraction in the object oriented domain and you can do your job. The problem is that when the more advanced problems will pop up and the performance issues that are caused by some design problems, your candidate can struggle with the problem or say "This cannot be done, we will need to buy the bar code reader library i don't know how to read those dots in a picture", or when the ORM fails and you will have to wait for a fix or give up (reminder:ORM is a mapping graph problem).

Both of my points regarding those two approaches can be totally wrong, as the candidate may learn fast and be very passionate about his job, and this in my book mean that there are no problems (algorithmic, logic, object oriented) that he cannot solve, a little time in needed though. So when this kind of candidate will fail at the tests what that basically means? Stress to my understanding, that he needs more time with the task (NOT A BAD THING!) to create the best possible solution.

I for example fail most of the tests, and does this apply that I suck at programming and algorithms? NO, the interviews get me all stressed up, and a few times I had the problem solved in my head but was not satisfied with it and one time I just told the interviewer that I don't have the solution yet, and the other that I have the solution but I will never accept it as it's slow and I don't like it, so there must be a better way. Needles to say my solution way was the one that the interviewer intended but as I sad it's plain bad I failed as I hurt his feelings :-)

My Way

Being an intervier myself and doing some interviews for other companies (btw you can hire me to do the interviewing job ;-) ). I always did a plain conversation with the candidate and asked about the things he is passionate about, and that's all, usually you can tell if the candidate is good at solving algorithmic problems and object oriented ones.

Question like: "Can you tell me about your coolest project, what was your role and what great things you did?" can tell you if your are talking with someone that loves programming and was born to be an IT Dev Ninja. When all goes well and you see that the concrete technical question you are asking are going well, add: "Here is a piece of paper can you use it ti explain me how you did the XYZ in that project." The best possible candidate should be the first to ask for a piece of paper, because his is so passionate about his work that he want's to tell the whole world how cool is this thing he did.

But if he is a student and has little experience with project BUT is passionate and for some strange reason hasn't got any open source project, the conversation must be changed a little. And besides most companies want to see binary reports when conducting test so I made a Interview form that is a concatenation of problems that I think are right for the interview process.

Lets Look At The Test

The test has three questions types:
1. Algorithm.
2. Object oriented problem.
3. How stuff works.

The first two are from the two distinct test groups, the last one is the concatenation of the first two and it's the most important if you get how stuff works and can tell me how to solve the problems contained in the question and define them then you know how to solve the first two but are just in stress, have bad day (or something).

The header is also very important! and I cannot stress that enough as this will lower your stress levels, and enable your creative process. 99% of my test failed because I panicked from stress and 1% because I was plain stupid :-)

This line: "All problems can be done “by hand” just by talking with the interviewer (usually the guy is in the room somewhere :-) ), discussion is desired." means that I will be there for you, you can ask me questions, and I will not leave you, and no paper solving the paper is not a compiler and you are not a robot!. the paper will be purely to write down ideas, UML diagrams, Interfaces etc. The problems will be solved by hand so that means you will write down something that must explain to me that you understand if you cannot express that with words, this is desired.

Tips: Generally tips will not be present on the test, if the candidate will have problems and our discussion will go to a halt then i will give such tips, so those tips are just an example.

Also if you will fail most or all of the questions, but our discussion will tell me that you are just so stressed that cannot think, we will talk about problems, and if you will have some cool solutions to other problems that are not in the test, ten you are fine by my standards, discussion relieves the stress and other domain problems may help you to get into the tinkering and creative process, and if you will show outstanding knowledge we may skip the test or compose a new one or return to this one and I'm sure you will solve that.

Summing Up


Interviewing is not an easy process and it's not binary, sure the decision is ("yay" or "nay") but everyone is different so the process of conduction an interview is very dynamic, therefore dynamic filters are required not just one sheet of problems for everyone, you cannot judge if one candidate is better then the other by using a static filter, this judges that one is better then the other IN THIS PARTICULAR PROBLEM DOMAINS nothing more. I will be coming back to this problem some more as i'm not done.

And if you want my interviewing services be sure to know that this is the process I will suggest you, if you give me do it my way, everybody will be happy.

EDIT: After a more in depth discussion about the example test on the forum, I decided that the first question needs to be more open, so the problem would have to be converted to write a fib(x) function that you think is best and then I shall ask you "can we do it any other way, is there a better way? etc." :-). This was the candidate can have a better solution then originally intended (for fib this not a big deal but considering different algorithms it will have a great impact).