1) Awkward silence
2) A flat out refusal to answer any of my algorithmic interview questions
3) An excuse not to answer my questions, usually mentioning that we are running out of time
On a few occasions the interviewer willingly answers my questions and we end up having a great technical discussion and both parties involved learn something. I think it is great because it shifts some of the nervousness back on the interviewer to remind them that the candidate is probably nervous as well.
I am wondering why the power dynamic is so skewed towards the employer in these situations? Is what I am doing considered so faux paus?
Normally in a good interview environment the conversation will naturally lead to a situation where a candidate asks a tough question or an algorithm etc. Or as happened to me once, they asked me why we didn't use Y, to which my answer was WTF is Y and why would you suggest it as an option here? I was genuinely curious why he felt it might be a good fit and it led to some awesome discussions where he proved to professionally kick my ass in the details. We made an offer that evening to him because as we all sat and talked about his interviews he had made really great observations and was an awesome team fit.
So I think if done as part of the interview conversation fine, but if you are doing it to just try and leave an impression or have a ego contest it is a stupid idea. And I do think you are right to ask non-softball type questions of a potential employer, its a big decision on both parts so you should know what you are getting into too. It really boils down to how it is done.
I had an interview recently where my solution was O(n^2), which I could tell was bad. I asked the interviewer if he code show me/code up the more efficient solution he mentioned previously. He mentioned that we didn't have time and dismissed my request which is very disheartening.
I think your example here is a fair question, but if there is still a lot to cover I may not take the opportunity to answer it either and instead move on to the next part of the interview, if your answer/question gave me what I needed from you. e.g. you gave an answer, and you knew it wasn't the best but were willing to look for other options and collaborate. That said, many times I am the guy who wants to talk through it with you because learning your thought process to me is WAY more important than whether you got the right answer.
you pretty much hit the nail on the head.
If you want to have a technical discussion, why not ask them about what they do, and maybe the algorithms involved there? That will tell you something about the company while also giving you a chance to get a taste of working with them.
Aside from that, I don't think it's a good idea to look at an interview as a power struggle. It's not a you vs. them situation, but rather you're both kind of gauging if you want to work together. The first part is kind of where they determine if they want to work with you (gauging your skill) while the second part (your questions and beyond) is kind of where you determine if you want to work with them.
As far as things go, unless you're well proven, people are probably going to need to gauge your skill in some way. Don't get too nervous about the algorithmic questions. Just think of them as a type of puzzle just with much higher stakes. For some practice, if you're not familiar with this website: oj.leetcode.com.
Disclosure: I don't have much experience interviewing. That's just my take on how to look at it.
also in a previous job interview, a guy showed up with a quick map traversal algo written in no less than ms word. right out i recognized the 6 line function, with a bug. while he asked "do you know which data structure this code expects" to which i replied "a graph, and you have a infinite loop on the visited check..." there he cut me as if he didn't want to hear what i was saying and proceed with questions he had planned/rehearsed.... until 5 questions later he actually asked "why would that fail" to which i had to point the bug mentioned before.
i just ruled that out as he being nervous as i was. but later i found out he was just a control freak and he actually said i lacked any technical knowledge in the hiring review. :) got the offer as everyone else obviously saw the opposite.
anyway. all that to illustrate that you should ask away. after all, you're going to spend 8h+a day with those people. the least it will do is to know then better.
what op does is when he has a chance to know more abt the position/company, he chooses to test interviewers like a counter strike. i dont understand what he tries to get out of this: he wouldn't join the company if future colleagues suck? is that a sincere gesture to show his interest in the job?
I do some hiring at a big systems company. We want to simulate your performance as a team member. We treat you as if you're a member of our team already and see how you do it.
Here's what I do:
First 5 mins: - Ask the candidate about their day and how they're doing - Calm their nerves by asking them about something on their resume (their college, previous workplace, some project that caught my eye)
Next 10 mins: - We use C and C++. This is systems programming, so I need people who understand pointers at least. A simple question like string reversal or linked list insertion. While the syntax isn't that important, I need to know that you understand pointers
Next 15-25 mins: - A pre-selected problem from our codebase (or something we're thinking of adding) and see how they would approach it. The solution isn't just code. It is also how it would perform with different memory sizes, disks and cpu configurations. Again, syntax isn't as important as the approach.
Usually, this is the killer question because we tend to go deep into a solution and the problem. This is more like a 1:1 meeting with another engineer instead of a traditional interview. We're basically simulating a problem solving discussion we have everyday. What we want to see is how you absorb the problem and how you start solving it. Doesn't matter if you don't know the best solution from Knuth. What matters is having a good discussion about it and solving the problem the best you can.
If there's time to slip another question: - Ask a quick scripting question. They can choose their language. Again, syntax isn't god almighty. It's more about the approach.
Last few minutes: - Give them time to ask their own questions. Most people ask about the kind of work they'll be doing or the company. Some people like to ask more about the pre-selected problem earlier because those problems are genuinely interesting and relevant.
To answer OP's question, some people do come back with algorithmic questions and we try to answer them too. But this ends up being more of a friendly team discussion instead of clashing egos. To be honest though, we'd really like you to ask some genuine questions about our team/company/product here. This is why asking an algorithmic question back would be bad. It's just unproductive. We want you to be absolutely sure you want to work with us too. As I said before, interviews are a two-way dialogue.
Disclaimer: This is only how we approach interviews in my team. This doesn't apply to all companies, especially the ones which interview people in bulk, have random hiring committees and assign candidate to random teams. We only invite people who we think are a match or who are interested in low level programming and willing to learn.
