Botched Interview
I had an interview yesterday and I totally botched it. What happened? Basically, I gave the interviewer an impression that I am some junior programmer who know nothing about development of Enterprise grade applications. Of course, anyone who has ever worked with me professionally would immediately scoff at the notion that I'm a "junior programmer", so what happened?
There are several reasons, all of which are my fault. Prior to this interview, I have always had jobs through people who are already familiar with my level of knowledge and experience. The interview process in these cases were mere formalities and I usually able to jump straight into whatever projects they required me to do. And I am usually able to deliver beyond expectations. Thus, I was not well equipped to handle a "real" interview by people who totally do not know me, especially my sometimes unorthodox ways of doing things.
As a consequence of my lack of experience with interviews, I had focused solely on preparing my case based on my skills in informatics research and machine learning. These were things the interviewer were totally uninterested in because they were looking at me as a software developer and most definitely have already excluded me as an expert in machine learning. I did not prepare myself in anyway to handle any software development questions and was immediately struck dumb by the interviewer's first question, "How do you do debugging?".
To me, that is a very open ended question that heavily depends on what kind of application, and what resources I have available. If I have an automated build system that runs daily tests, I would already know which modules to look at. If all I had was an IDE debugger, or worse just the source code and text editor, I would be doing manual debugging by tracing variables and inserting debug statements. Since this was the very first question, I figured the interviewer wanted to know that I was at least competent in basic debugging techniques and I told them I would use a debugger to step through the source code and trace variables. If needed, I would put in debug statements.
"How do you go about designing an application?"
Again, this very open ended question stunned me. One could literally write a series of books on this and the interviewer wants me to summarize it in a few short sentences? On hindsight, I should have answered it the "standard way", that is to take a top down approach by breaking down the application into its major parts. For instance, a J2EE or web based application would first be broken into standard n-tiers, a data-store/database tier, a "business logic" tier and a presentation/web tier. I would then drill down one level to design a suitable database schema for the application, build OO business-level component managers around the database to manage database transactions and ensure that only properly validated data goes into the database as well as provide only the necessary data for each business action, etc...
I did not answer that because to me, it was elementary stuff that I have been doing for over a decade. And all that experience has told me that 90% of any application is straightforward in terms of design, implementation, coding and maintenance. As a seasoned developer, I know that it is the remaining 10% of that application that eats up the majority of development time. As a result, I usually start with an iterative bottom-up approach by constantly hammering that 10% difficult to code part of the system until it is done before moving on to tackle the rest of the application, which can be done in a jiffy if I have available RAD tools.
I should have said all this in the interview. Instead, I jumped straight ahead into difficult, the "iterative, bottom-up" part. This gave the interviewers the impression that I knew nothing of Enterprise grade application development *groan*. By that point, I basically shot myself in the leg and blew the interview away.
The interviewer switched to an even lower gear by asking me even more junior level questions, such as what is the "third normal form" in database design. I have been designing databases for over a decade, these design rules are so ingrained in me that I do not need to validate my designs against these "normal forms" to know that I have a fully normalized, well indexed database. Oh for pete's sake, how am I supposed to remember the formal definition of something I learnt over 10 years ago? Anyway, my failure to answer what the third normal form is probably sealed the interviewer's impression of me as a know-nothing programmer.
That's the end of that job interview. I'm totally disgusted with myself right now.
There are several reasons, all of which are my fault. Prior to this interview, I have always had jobs through people who are already familiar with my level of knowledge and experience. The interview process in these cases were mere formalities and I usually able to jump straight into whatever projects they required me to do. And I am usually able to deliver beyond expectations. Thus, I was not well equipped to handle a "real" interview by people who totally do not know me, especially my sometimes unorthodox ways of doing things.
As a consequence of my lack of experience with interviews, I had focused solely on preparing my case based on my skills in informatics research and machine learning. These were things the interviewer were totally uninterested in because they were looking at me as a software developer and most definitely have already excluded me as an expert in machine learning. I did not prepare myself in anyway to handle any software development questions and was immediately struck dumb by the interviewer's first question, "How do you do debugging?".
To me, that is a very open ended question that heavily depends on what kind of application, and what resources I have available. If I have an automated build system that runs daily tests, I would already know which modules to look at. If all I had was an IDE debugger, or worse just the source code and text editor, I would be doing manual debugging by tracing variables and inserting debug statements. Since this was the very first question, I figured the interviewer wanted to know that I was at least competent in basic debugging techniques and I told them I would use a debugger to step through the source code and trace variables. If needed, I would put in debug statements.
"How do you go about designing an application?"
Again, this very open ended question stunned me. One could literally write a series of books on this and the interviewer wants me to summarize it in a few short sentences? On hindsight, I should have answered it the "standard way", that is to take a top down approach by breaking down the application into its major parts. For instance, a J2EE or web based application would first be broken into standard n-tiers, a data-store/database tier, a "business logic" tier and a presentation/web tier. I would then drill down one level to design a suitable database schema for the application, build OO business-level component managers around the database to manage database transactions and ensure that only properly validated data goes into the database as well as provide only the necessary data for each business action, etc...
I did not answer that because to me, it was elementary stuff that I have been doing for over a decade. And all that experience has told me that 90% of any application is straightforward in terms of design, implementation, coding and maintenance. As a seasoned developer, I know that it is the remaining 10% of that application that eats up the majority of development time. As a result, I usually start with an iterative bottom-up approach by constantly hammering that 10% difficult to code part of the system until it is done before moving on to tackle the rest of the application, which can be done in a jiffy if I have available RAD tools.
I should have said all this in the interview. Instead, I jumped straight ahead into difficult, the "iterative, bottom-up" part. This gave the interviewers the impression that I knew nothing of Enterprise grade application development *groan*. By that point, I basically shot myself in the leg and blew the interview away.
The interviewer switched to an even lower gear by asking me even more junior level questions, such as what is the "third normal form" in database design. I have been designing databases for over a decade, these design rules are so ingrained in me that I do not need to validate my designs against these "normal forms" to know that I have a fully normalized, well indexed database. Oh for pete's sake, how am I supposed to remember the formal definition of something I learnt over 10 years ago? Anyway, my failure to answer what the third normal form is probably sealed the interviewer's impression of me as a know-nothing programmer.
That's the end of that job interview. I'm totally disgusted with myself right now.
|
|
0 comments:
Post a Comment