I had an interview experience that I wish to learn from so that I do not make mistake again. The interview was in 4 parts with 2 people each time.
The technical part was where I stumbled a bit although I had researched on how to approach such a situation without appearing panicked. The interviewers gave me a piece of paper that had a requirement (I am guessing from their day to day work) about creating a database/table. This was my approach:
- Read the information on the piece of paper a few times.
- Asked some questions that I thought needed some clarification.
- Moved to whiteboarding by creating a table, asking more questions as I went. I wanted to show that I was engaging and getting information where I think I needed it.
- I gave many perspectives about the different decisions that would need to be made before creating a database/table. This is from my work experience. This is what I would do if I was assigned work at my job. You don't just jump into creating a database or table without thinking through how it affects the product.
- The interviewers asked what data model I would use and that may have confused me. I am still not sure what data modeling is to be done when creating a table? (theirs was a MySQL database).
Overall, I think I did a good job answering all questions but I could read the faces of the interviewers and they seemed like they were not satisfied.
Basically, I have not yet been able to find out what I did that they did not want to move ahead. The recruiter said that they thought I had good product experience but I did not seem to do great in the technical part. I don't agree. I talked about the table, the columns, primary keys, foreign keys, unique index constraints, performance etc.
Is there anything wrong with how I approached the technical question as I described in the steps above? What could I improve? Are there other approaches that I should use instead?