The Software World

7 Reasons Why I Disclose the Answer During a Software Tech Interview

An interview is not an examination, but a mutual interaction

Recently I conducted an Android interview and asked the candidate if we can inject an argument parameter through its Activity constructor. The candidate answered “yes.” Knowing that was the wrong answer, I could’ve moved in, but instead, I tried to give some hints. I proposed the interviewee check the AndroidManifest.xml. However, the interviewee still got it wrong.

Now, I could’ve decided to move on to the next topic or disclosed the answer to the interviewee.

In normal cases, I guess most interviewers might just decide to move on, as disclosing the answer is not part of the expected interview process.

However, I feel obligated to disclose the answer, given the interviewee is ignorant of it. I feel if I just move on, I am doing the interviewee a disservice.

Below are the reasons.

1. It’s Not an Examination, but an Interaction

A lot of time, we relate interviews with examinations. The interviewer is the examiner while the interviewee is the candidate. The question is given in a specific manner, and the answer is expected in a specific order. Hence if the answer is wrong… then just “X” that point and move on.

I think, while this can provide some relatively standard results that deem fair across the interviewed candidate, it fails the spirit of the interview.

The interview is a process for the interviewer to interact with the interviewee and get to know one better. Ideally, we would like to know the technical competency of the interviewee, but it shouldn’t be in an examination setting. Instead, it should resemble a normal conversation that we have with colleagues and friends on some tech discussion.

True enough, there’s some agenda in the conversation, but the entire setting should mimic most of our daily working tech interactions.

There’s more than just tech capability we want to know about the candidate, and that also does not resemble how we work daily.

2. That’s How Real Life Works: We Help Where We Can

In a tech interview, one of the agendas is to gauge the candidate's technical capability. We can ask the question and based on the answer provided, we move on to the next one, regardless of right or wrong. The interviewer shows no expression only a poker face. No help or hint is provided, as this is considered unfair to those who can answer it straight away.

As mentioned earlier, while this achieved “normalization” of candidates' tech capability, it also portrays a relatively inhuman environment that stresses out the interviewee. That’s not what a real software development culture is.

Instead, in normal software development today, we work in pairs. We constantly support and help each other. When our developers get stuck or get it wrong, we help them in the hope they learn and succeed.

Why not portray that in our interview process? If the interviewee doesn’t know the answer or gets it wrong, provide them some hints, and help them. Try to point them in the right direction.

Maybe the interviewee just needs some warm-up help. And with a little support from our side, they can get back on track and perform in their usual form.

3. It’s Only Fair for the Interviewee To Know the Answer

I have been through many interviews. For some interviews, I felt I did terrifically. But it came back unfavorable. I was lost. I didn’t even know what I had missed. How can I improve in the future?

This is particularly true for technical interviews. When there’s a clear case that I’m wrong, I really hope I am informed, instead of being left ignorant — or worse still, given the impression I got it right. I don’t mind not getting the answer, but minimally I want to know I’m heading the wrong way.

As an interviewer, this part is a very tricky bit to present, i.e., informing the interviewee they are not heading down the right path. It has to be done in a super tactful way, where the interviewee is not “alerted” and goes into “panic mode” knowing they are not heading down the right path.

Hence, it is important to assure the interviewee ahead of the following:

• It’s okay they don’t know and to be open about it.
• It’s part of our role to help them as much as if they were on the wrong path.
• No one is expected to be perfect.
• A wrong answer doesn’t warrant a failed interview.
• In fact, during the interview, we also tell them it’s okay to use Google, as that’s how real working life is. It’s open book.

It is also important that we shouldn’t just give the answer away immediately when the interviewee gets it wrong. Guides and hints should be given so that the interviewee has ample opportunity to try them on.

Ideally, we should avoid giving the verbatim answer, as that severs the opportunity for the interview to continue attempting. An exception is for answers that are true/false and yes/no (i.e., my case above).

Minimally, the interviewee should be aware that they are still not getting it right.

With that given, at least the interviewee is now aware. I hope that will be of value.

4. It Should Provide Value to the Interviewee

I tried to interview for an Android developer position many years back. During the technical programming interview, I got some right answers. But at the same time, I also didn’t get some right. The interviewers were friendly and yet very candid as they interview me, telling me my answer was not the best.

I’m glad they told me; it adds value to me. I know where I am deficient, and I felt I was given the additional opportunity to learn and improve it.

I grabbed hold of this opportunity. I left, did the research, and tried to improve my answer. And within the same day, I wrote an email providing a much better version of the answer to the interviewers (thankfully, they contacted me and I got another interview).

Of course, I did this tactfully, thanking them for the interview opportunity. I didn’t spam the interviewers and used the most polite tone possible to provide an improved answer. It’s not the first time I did this. I did the same in the past and didn’t get a response from the interviewer. That’s all right, as I understood they had the evaluation procedure.

But this round, I got a response from the interviewer and went on to the next round. I’m not sure if I got to the next round due to my diligent extra attempt or if I already passed the basic requirement to get to the next round.

What I know is that I learned something, and the previous interview provided me with value to improve myself. The rest is history as I wrote in my story below:

Our interview process should provide value for our interviewees. From the interview, they should learn what they have missed, and how they can improve further. Hopefully, as they learn and improve, they’ll do better in their future interviews or even in their job.

5. It’s Not Solely Technical, but Also How One Interacts

No one is perfect. That’s all right as long as one is willing to learn. That’s one very important attribute for us to find out during the interview.

We want to avoid getting an interviewee that aced the technical interview without flaw and joined the team later — but doesn’t take input from others constructively. They are smart but not willing to work in a team consensus decision. Their view is always right and others’ views are less than ideal.

In the interview process, this can be discovered when there are different opinions and thoughts shared. Does the interviewee take “ahem, that doesn’t seem right” as an opportunity to correct their steps or do they take the remark sensitively and react negatively towards it?

It’s much better to hire a developer that’s technically still learning, and willing to take input and learn and work very well with others, than one with some personality challenges that don’t blend well with the team.

Therefore, if the interviewee is heading the wrong way, it’s crucial for the interviewer to try to help correct it. That resembles the real working situation in a daily manner. All interactions should still be constructive, tactful, friendly, and handled professionally.

In actual fact, it’s not important who’s right or wrong, but how both parties interact and bring up the fact in a considerate manner, without demeaning each other.

Therefore, if we avoid letting the interviewee know this is incorrect, we might lose the chance to observe how such an interaction could turn out.

6. Maybe We Have Missed Something?

Sometimes, we might have missed something that’s totally valid from the interviewee's point of view. Hence our probing and guidance might help enlighten ourselves instead. Below are a few case examples.

Case 1: We miss taking into consideration their background

I recall many years back I was interviewing a pool of college graduate students. We provided an algorithm question: to write a program to calculate the Fibonacci sequence. I was expecting the answer to be a recursive answer.

One of the college graduates answered it using a for loop instead of a recursive function. The answer was correct but much longer than I was expecting. We wanted developers that can think recursively and not use the normal loop.

When we asked her why she didn’t try using recursive, we realized the graduate was not from a Computer Science degree background but from Electronic Engineering degree. Her exposure to programming was rather limited.

Knowing this gave us better insight into why such an answer is given. The fact she could still program and get to the answer with limited exposure was amazing. She got hired.

Today she is highly successful in her technical career. Don’t think she’ll have a problem answering any recursive programming questions today.

Case 2: The interviewee might have thought deeper than needed

We are pairing interviewed using code that had blocking dual-network calls that slowed down the app code. We asked the interviewee how can we avoid the slow down. The answers were supposed to be placing the network calls behind a background thread.

The interviewee seemed to think hard and deep. Seemingly struggle to come up with an answer. Instead of just “times-up,” we asked the interviewee to tell us what he was thinking.

Apparently, the interviewee was thinking hard on how to make a network call parallel and synchronized. That’s a hard problem. We didn’t expect the interviewee to do that within the ten-minute answer.

Therefore, we gave a hint, stating we didn’t a need parallel network call. Instead, we asked the interviewee to focus on the thread used between the network call and the UI code. He now understood our expectation, and was able to get to work on it then.

Case 3: We might have not provided the needed context

There was this famous (or maybe infamous) interview question. The interviewer asked the interviewee: “Can you swap the content of two variables without using a temporary variable?”

The interviewee thought deep and tried various approaches. After thinking for a while and scribbing on the paper, the interviewee stated it was impossible.

When the interviewer gave the hint,

X = 25, Y = 23

The context became different. This was now feasible. The reason was because it was only applied to a number, and not any variable! The question was supposed to be “Can you swap the content of two integer variables without using a temporary variable?”, and not for any variable.

The question was not formed correctly and misled the interviewee into thinking it was harder than needed. Luckily, it was corrected in between.

These are just a few examples. In short, it is so crucial to interact, communicate, and guide the interviewee as much. Not only might it enlighten the interviewee, but it may also help us interviewers on things we have missed.

7. Maybe Our Answer Is Not Actually Valid Anymore

Hopefully, this happens rarely, but it does happen.

If there’s no interaction and discussion, we might have mistakenly “wronged” the interviewee, while actually, our answer is wrong :( .

Let me share a simple example below:

In Android development, the app could at times get killed by the system.

• To ensure we restore the state, we need to use savedInstancestate.
• Optionally, we can use the Architecture Components’s ViewModel, which will restore the state on configuration change but not when the system kills it.

Hence, the interview question is, what’s the difference between using savedInstanceState vs ViewModel in restoring the Android app’s state?

We would expect the answer as per the two bullet points above. However, the interviewee disagrees with the answer. After some discussion, we find the following:

While the answer above is valid (before 2019), it's dated. In 2019, the Google team has enhanced the ViewModel to have savedStateHandler, which also performs state restoration as what can be done using savedInstanceState. (refer to this article for details).

It’s fortunate to have such a tech discussion with the interviewee, as we disclose the “answer” we have. Not only do we not “wrong” the interviewee, and fix our answer, but we also learn the interviewee is up-to-date on Android development, which we have missed.

There’s No One Right Way of Interviewing…

While the topic states why the interviewer should consider guiding and perhaps also disclosing the answer during the interview, I understand there are much more considerations on whether we should provide answers or not. It’s based on the situation, for example:

• The nature of the answer to the question (definite, subjective, open-ended)
• The interview setting (e.g., time available, number of questions, the environment)
• How interactive and receptive is the interviewee toward inputs

The point is that the entire idea of an interview is to explore and see how suitable the interviewee is for the targeted job position. Hence it would be best to have the interview process mimic the needs of the job nature itself as much as possible.

Besides, in the interview, it’s our opportunity to share our friendly, positive, and collaborative development culture with the candidate.

Remember, the interview applies to both parties. We are deciding their suitability, while they are deciding our worthiness.