0

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 even though one of the person 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).

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?

  • It could be that they intentionally left it vague to see how well you'd do. It's best to stick with your intuition when answering and don't be afraid to ask questions about things. – Dan May 30 at 16:40
  • 2
    As others have said, years experience is no measure of an individual's ability. I have a guy on my team who is still in uni and he could wipe the floor with some of their more experienced colleagues. I often bring juniors into interviews to give them experiences of being on the other side of the table - when I was first asked to lead an interview I was like a deer in the headlights so I'm trying to develop their interviewing skills. Finally, remember they could have had him/her there to see how you treat juniors - are you dismissive of them or will they learn from you. – amcdermott May 30 at 16:46
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.

15

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.

  • So, basically according to you going full force to give your best in an interview is being a smart alec? I just hope you are not interviewing anybody because who knows how they are being judged. – user163824 May 30 at 17:28
  • 10
    Based on your initial post and your response to this answer I think Dan was spot on. – jesse May 30 at 17:44
  • 6
    +1 Agreed. Anyone that comes out of an interview with two main points of "Those guys were idiots" and "Why didn't they like me?" should really try a bit of introspection. – Kevin May 30 at 18:01
  • @user163824 As you said they didn't seem to understand your solution and on top of that you called an interviewer "idiot" though not in front of him but it seems like they knew you were thinking this. It seems to me like the reason(s) you didn't get to move forward are due to reasons you mentioned but if this is your best effort you should work on that. – Dan May 30 at 18:06
  • 1
    @Dan It's also common that someone in a technical role needs to interact with non-technical people. If the interviewers didn't understand the OP's solution, the right move (to land the job) would be to explain the solution and why it's the one the interviewee chose, as if presenting to an executive allocating a budget for a related project. Assuming idiocy is generally not the right move. – Upper_Case May 30 at 18:11
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.

1

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.

1

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?

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.