How to approach technical challenge with vague requirements in interview?

Question

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:

1. Read the information on the piece of paper a few times.
2. Asked some questions that I thought needed some clarification.
3. 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.
4. 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.
5. 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?

Answer 1

Well here's my guess. They were asking about "data model" as in, relational (which most DBs use), object oriented (if you start from classes, objects containing objects... you could do that, then use an ORM like Entity Framework to create a db), network model, document model and whatnot.

The reason why the question is vague is that for 99% of the use cases people use relational model or think in terms of it, so this is kind of assumed, and people only discuss other models in very specific use cases.

If their DB was MySQL, it's reasonable to assume a relational model and not discuss other models unless specifically asked for - because that's how the data will be stored, no matter what fancy library or ORM you use to define it.

Answer 2

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.

Sometimes it's not about what you know but how you present that knowledge. Without meaning offense to you, after reading your question I feel like you're a smart aleck, know it all who thinks he's better.

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 even though one of the idiots was probably someone with hardly 3 years experience (I don't understand why such less experienced person is supposed to be part of a technical interview decision)

Well there you go. They probably read the fact that you feel your answer is superior to theirs and they did not have the "brains" to figure it out.

Answer 3

Is there anything wrong with how I approached the technical question as I described in the steps above?

There is nothing wrong per se, other than the fact that you were not prepared. You did not know about the data modeling ( and you admittedly still do not know ). There is nothing wrong with this if this isn't your primary area of expertise, but if you were selling yourself as knowledgeable in this subject and were confused by one of their questions then I could see why they would not move forward with you.

Answer 4

one of the [interviewers] was probably someone with hardly 3 years experience (I don't understand why such less experienced person is supposed to be part of a technical interview decision).

There are lots of reasons a less experienced employee might be involved in a technical interview of someone more experienced.

Perhaps their manager wants to expose them to interviewing, and so they are there as an observer. Perhaps in the role they are considering you for, you would be that person's manager, and so the more senior interviewer is trying to see how the two of you interact. Maybe the role that you are interviewing for involves a lot of management or interaction with more junior employees, and the senior interviewer wants to see how you can work with someone less experienced than yourself. There could be many other reasons.

What I will say, especially as you called them "idiots" in your original version, is that it is very hard to be successful in an interview if you think the interviewers are idiots.

I'll often "play dumb" a bit when giving a technical interview, to challenge the interviewee, to see how well he/she can deal with a bit of adversity, to see if they can make their point without losing their cool, etc. If the candidate becomes condescending, rude, obnoxious, etc., I'll pass on them right away: how can I hire someone who cannot communicate with a client, the head of sales, or the CEO, people who might be very smart, but aren't software developers, without becoming obnoxious?

Answer 5

The interview is two-way process. You are not applying blindly for a job, but look whether you will be a good fit for the company and whether the company and role the offer fit your style.

In your case, it seems, that both you and company didn't like each other too much.

From what you wrote, it seems they were looking for architect (design objects) and you were looking for a role of a DB designer, so it is good thing you didn't end up together.

I talked about the table, the columns, primary keys, foreign keys, unique index constraints, performance etc.