[akshat_h]

Aren't a lot of so called 'algorithmic problems' similar to brain teasers? If you have seen it before, you'll know it. But otherwise, there is not much chance of you cracking it without an 'Aha' moment, which may or may not come during the one hour allocated for an interview.

Weird tricks in bit manipulation, linked lists, array, hash problems etc. are all standard in interviewing and are still used, even at Google, at least 2 years ago, when I last interviewed there.

This works though as Google's, and the industry in general has a policy of rejecting candidates, rather than accepting them, because hiring is very risk-averse. Candidates switch jobs frequently at the beginning of their career and so there is a rotating pool of good candidates the companies can pick from.

[xtracto]

Yes they are, and as you, I consider themselves exactly the same. An example one that I used to ask during interviews were the "traverse a matrix in inverse diagonals" or "traverse a matrix in circular way" or the typical "first duplicated number" (that one is on CodeFights and CodeWars).

Those are problems that you either know the "trick" or you don't.

The main problem with the majority of them is not the problem itself. The main problem is that originally they are meant to understand the process of problem solving of a candidate. However, as they are passed among interviewers, they become an "solved or not solved", because it is the path of least effort.

I once created a problem that I love to ask in my interviews, it deals with binary search to get the total elements from a list that is only avilable through a "broken" API. A lot of people I interviewed told me that they loved the question, however, when some colleagues started adopting it, I realized that they were basically expecting the specific answer they knew... when the real value of the exercise is to work with interviewees to "solve a problem together".

[akshat_h]

I think this is also because no one really teaches you how to interview. Giving multiple interviews doesn't, at least IMHO make you knowledgeable to be on the other side.

It is kinda at a certain level in your career you are expected to just know how to do it. For other skills like management, you at least have your peers who are doing the work day in day out, who you can learn from. Interviews are closed room, usually, though I have had some where one person was shadowing the interviewer.

Also, if you take a terrible interview, its not gonna really impact you. There is no performance report that'll negatively impact you. There will be another candidate, who you'll have a rapport with. Or someone else will interview someone else.

As you said in your anecdote about the binary search problem, not everyone is best at being an interviewer.

But aside from there being a dedicated person for interviewing for big companies, or outsourcing interviews for startups, I don't really see a solution. And outsourcing, whether internally or externally comes up with its own set of problems.

[xtracto]

> I think this is also because no one really teaches you how to interview. Giving multiple interviews doesn't, at least IMHO make you knowledgeable to be on the other side.

This is something that I have ameliorated in my teams in the following way: When an Engineer is going to start interviewing people he goes through the following process:

0. Before starting, we provide some guidance on what we look in interviews and what we ask (1 hour meeting with the new wannabe interviewer and the manager)

1. First he shadows an interview done by a Tech Lead or Sr. Engineer (those are the ones that generally do the interviews)

2. Then he does two interviews, where he asks the questions but is shadowed by a Tech Lead of Sr. Engineer. He gets feedback about his interviews and is asked to explain his feedback and we tune it to the expectations from the team.

3. Finally he starts interviewing people on his own.

This has worked well enough for me, specially once we had a shared GDocs with a) The list of questions to ask (along with notes on what to look for and how to guide guys) and b) A "competency matrix" ( like http://sijinjoseph.com/programmer-competency-matrix/ ) tailored to what we were looking for.

Finally, one of the things I always emphazise the people that is interviewing for my team, is to remember how they felt during interviews. And be aware that as interviewer ALWAYS you have the upper hand. I hate being interviewed, I hate the feeling there, and the fact that you have 60-90 mintues to demonstrate that you know what the company is choosing to ask you, without regards of all other stuff you know that will be useful for the position, but they don't ask. And the nerves.