The standard answers to programmer interviews are not standard

[[165225]]

Peter Verhas asked a seemingly irrelevant question in a technical interview and received a correct but inappropriate answer. Later, he declared, "Sometimes, I get candidates who not only don't know the answer, but also try to be smart and give the wrong answer. Knowing the wrong answer is worse than not knowing. A few even insist and try to explain to me how I should understand their answer. This becomes a personality issue and is a surefire way to pass the interview." I want to state that not only is Peter wrong, but such interview conditions are completely detrimental to the interests of the company he works for. I personally would never work for a company with such an attitude.

You can start by reading his original article. In fact, it doesn't take long.

Okay, now that you understand the material, let’s explore it thoroughly.

Asking the Wrong Questions

For starters, in my opinion, the whole process went wrong from the start:

There are many Java technical interview questions that even the most entry-level newbie can give the right answers to. When I face candidates who are not so junior, I don't waste time by asking these questions. I assume that the candidate knows the right answer. However, sometimes there are candidates who I think are newbies from the beginning, and I will cut the interview to avoid wasting his/her and my time, so I will ask some simple questions. The answers to these questions usually reveal the true level of knowledge, so we can evaluate the level in a shorter time.

But guys, let's be clear: if you're the interviewer for a technical interview, you have to ask them to write code, not answer questions. Unless they're applying for a position that asks them to answer programming questions (in which case you're interviewing teachers, not actual programmers), you have to ask them to demonstrate their technical skills, not their verbal knowledge.

The reasons for this should be obvious, but if you still don’t understand, I will explain it from the perspective of logic, examples, and analogies.

Logic: Not every programmer you interview has traditional training. They may not know all the preferred terminology. Is it "getters and setters" or "automatically-defined properties" or "accessors and mutators"? That depends in part on what language you grew up with (e.g., if it's C++, I preferred the latter for quite a while). It depends on what book you read. It depends on whether you've discussed this with other people—perhaps learning it from a book and reading about it on the web. (A recent StackOverflow poll found that about a third or more of the developers you're interviewing consider themselves "self-taught.") Are you going to kick out perfectly qualified candidates because they didn't use the right word? And that doesn't even include the people who get so nervous during the interview that they blunder through even simple questions.

Example: One developer who worked for me for two years was a pretty capable C# developer. This was a guy who could lead a team, mentor some of the more junior developers, and come up with some pretty solid designs. Then, when a potential client asked him in a meeting what static methods were, he completely blew it and started talking about constructors and other irrelevant stuff. I had been sitting there looking at him with a "what the hell?!?" expression on my face for several minutes before he finally realized what he was talking about. By Peter's standards, he would have failed the interview without a doubt. However, after that meeting, he continued to work as a team lead for that client for 9 months, and no one questioned his skills, his abilities, and his answers to the static questions (ironically, no one ever talked about this!). In other words, he did well without the pressure of the interview, and his work showed it.

Analogy: For example, if you were hiring a band to play at your wedding, would you really care about their ability to explain music theory and composition? Or would you be more concerned about whether they can play your favorite dance music, the songs your spouse chose, and get your grandparents on the dance floor? Many bands (dare I say all bands!!) get gigs based on their work and/or demos, not their ability to answer questions.

Expect the wrong answer

Then Peter said,

Knowing the wrong answer is worse than not knowing it. A few even insisted and tried to explain to me how I should understand their answer. This became a personality issue and a surefire way to pass on the interview.

Haha, you are so arrogant, just call yourself "Programming Interview God". What I mean is:

Here is a simple question: Can a static method of a class call a non-static method of the same class? If you know a little bit of Java, you know the answer is: no, it can't. Static methods belong to the class, not to the instance. You can even execute a static method directly using the name of the class without any instance of the class. It can even run without an instance of the class in the entire JVM. So, how can you call a normal method that runs connected to an instance?

Arrogant fellow, there is no reason why static methods can't call instance methods, okay. Peter's question here is based on the fact that static methods have no reference to a specific object (usually a "this" reference), which is the reason for the answer given: "without this, no method call".

However:

Then again, a candidate came out and his answer was: yes. He even started to explain that this could happen when a static method accesses an instance. It might get an instance as a method parameter, and through that reference, it can call the instance method. He was right.

but:

This answer does not change the fact that he does not know much about Java, although his answer is correct in this very specific question.

So, please forgive my bluntness: this answer can be said to be correct, but you can also say it is wrong, because "this candidate does not have a deep understanding of Java"? But conversely, I can also say that it is because this candidate fully understands Java that he can find an answer that is unexpected to you but is actually correct.

It’s obvious what happens next: the interviewer, who is confident in his skills, prepares a series of questions with prescribed answers to ask the candidate, and if the candidate does not answer according to his answers, he will be deemed “unqualified”.

Let me give you an example from my own experience. A few years ago, I went to a company for an interview for a C++ position. When I was asked, "Can private fields be accessed from outside the class?", the normal answer should be "No, private will encapsulate this field, as if it is isolated from the world."

 #include <iostream>
 #include <string>
 using namespace std;
 class Person
 {
 public :
 Person ( const   char * fn, const   char * ln, int a)
    : first_name (fn), last_name (ln), age (a)
 { }
 string description () {
 return first_name + " " + last_name + " is " + to_string (age) + " years old" ;
 }
 private :
 string first_name;
 string last_name;
 int age;
 };
 int main () {
  Person ted ( "Ted" , "Neward" , 45 );
  cout << ted.description () << endl;
 }

By definition, the "age" field is not accessible from anywhere else, right?

However, my answer is: "Of course you can. You just need to convert the object instance into a void pointer (void*) and then calculate the offset from the beginning of the object so that you can access it."

 int main () {
  Person ted ( "Ted" , "Neward" , 45 );
  cout << ted.description () << endl;
 void * pTed = ( void *)&ted;
 int offset = sizeof (string) + sizeof (string);
 char * pTedAge = (static_cast< char *>(pTed) + offset);
  cout << static_cast< int >(*pTedAge) << endl; // prints 45  
 }

I even showed them how to boil this down to a template (I called it "THackOMatic" and consider it one of my best work in the language).

Well, your response might be:

• Wow, I didn't expect you to think of that. Very interesting. I was thinking...
• Well, it is possible, but it is not a good idea.
• You totally miss the point of the question. So, you are still wrong.

If your response is one of the first two, then I'm in the same camp as you. It's an attempt, anyway it is an attempt, and attempts are usually a sign that you're doing something wrong, except in very narrow circumstances where there is no other way, and unless you are the only one touching that code from now on.

But if you responded in the third category, then you may be missing the point. The point of the question is that the candidate has pointed out a way around the stumbling block. If you fail to recognize that, then I think the fault lies with you, not with the candidate.

The people you hire are relevant to your interview criteria

Right or wrong, you give your question, the candidate thinks about it their way, and then comes up with a novel answer. But by focusing only on the answer, you'll miss the important component - the way they found to get around it.

Interviews can be used to find candidates who meet certain technical requirements, but they can also be used to find candidates who have ways around obstacles. Bugs, production outages, design flaws, whatever it is, you need to look for people who don't get stuck in the old ways.

But when the candidate actually does that, you reject him again.

So, what you actually want is the kind of ordinary, boring, and uninitiated answer, but what they give is an "out-of-the-box", creative, and refreshing answer.

Do you claim that you only hire "the best"? But know that if you do, you're hiring programmers who are just average in the middle of the pack, at best. The programmers who stand out from the crowd are often the ones who think outside the box because they know that sometimes and in certain situations, rules are made to be broken.

At this point, do you think they will be satisfied with you being a conventional interviewer? I don't think so.

Summarize

So the challenge here is: if you were the interviewer, what would you be interviewing about?

By the way, remember that company I mentioned interviewing with years ago? The interviewer's response was typical: "Sorry, the correct answer is 'no', but I know what you mean. You're the first person to ever give me that answer." They hired me shortly thereafter, and before I left, I used a number of my language skills to help significantly reduce the size of their code base.