Inverting Binary Trees Considered Harmful

The problem that I see with the interview process is the same problem that I see in computer science cirruculum: focusing too much on things programmers should know, rather than how to know things.

"How so?" pretty much describes the situation to a t.

Interviewing is hard. Both for the candidate and the interviewer, if he/she knows the value of hiring - as assessing the overall qualities of a candidate in a one-hour chat is mostly impossible. Also, you're interviewing someone whose future life depends on the outcome of that exam, to some extent. That makes a fraction of the people you interview very nervous and thus perform badly. Then, you have the introverts, and people that don't have great communication skills, who usually get the interviewer in a bad mood because the conversation gets uneasy. It's really a minefield not to create a huge amount of false negatives. So, I agree that uber-specific CS questions would just test your memory, or more precisely your luck. That's the same as "cultural fit", only in terms of technology.

My strategy, when interviewing is: - If the candidate has some FLOSS project he mentions in his resume (we actively encourage them to do so), I take a look at his/her code. That is usually one of the best indicators of their abilities. If the project is interesting, I usually start the interview from it. - Ask general questions which a candidate for this position should reasonably know. Try to get the candidate to talk to you, and then try to get the conversation to a more detailed level, to test how deep the knowledge of the field has gone - Ask the candidate to talk to you about something they have passion about in the tech field, a project they loved to work on. Again, use things the candidate is describing to get to dig a little deeper - Look at the CV, find any language that the candidate affirms to know well and to use daily, and ask some specifics about it. - Finally, make a small thought experiment of building an application.

These are normally questions that should not weed out anyone because they don't remember that particular detailed thing I love so much, and still weeds out very quickly whoever is superficial, or is pretending to know things he/se doesn't know.

You'd be amazed how many "rockstar web developers" fill their mouths with "RESTful webservices" and then have no idea of which the HTTP caching headers are. Or what's the HTTP status code for Not Modified. Or by how many python "hackers" can't tell the difference between a list and a set in their favourite language.

So, I definitely try to make the candidate be in a comfortable place during the interview. I know of at least one guy that told our internal recruiter that I use the interviews to show off... and that was because I explained a senior Java programmer that yes, Java's GC system is a bit different than Perl's.

So be advised, sometimes people are just bitter with the interviewer because they performed badly and can't admit that to themselves.

Candidates naturally feel uneasy when interviewing. In the end, one hour of chatter will either get you a job you kind of desire, or not.

I think it's our responsibility, as interviewers, to make people as comfortable as possible so that they can perform at their best. It's our responsibility to prepare for the interview, smile to the candidate, downplay any hiccup they may have.

I don't believe all the BS about "taking people out of their comfort zone": 98% of people will feel uneasy at an interview and they will be well out of their comfort zone already.

I wouldn't fret about it too much.

There are a lot of interviewer egos out there and kids being put in the position of Ultimate Power(tm) can really do a lot of damage to the self-worth of qualified candidates.

Just keep coding, studying algorithms, etc, and putting yourself out there. Eventually you'll get a job that you want and is well suited for you. You're fortunate to live in a time where it's a seller's market, employment-wise.