A month ago I saw this tweet from @theshalvah

So, guess what? I asked them for feedback, and it was a rejection. Thankfully, they provided some feedback. But what pains me is that a third of it is plain wrong, as though they didn't look at my code at all. https://t.co/HJYmEuqMPA

— Thor, God of Static Electricity (@theshalvah) September 17, 2018

I immediately resonated with his pain and any programmer that has taken home an interview coding "assignment" or done pair programming in an interview can also relate. I encourage you to read the conversation that evolved out of that tweet but the short of it is that the interview process for developers is broken and there is a disconnect between what interview candidates think is required from them and what the employer is looking for. This will not be a post about how to fix the developer interview or how to prepare for an interview but an expansion on my reply to @theshalvah and hopefully help others get in the right mindset when doing coding interviews.

My dad once told me that while employing someone there are only three things you should look for:

1. They have a happy positive attitude towards life and your company
2. They are humble/obedient
3. They like to learn

At first glance, this looks like nothing. I first heard this as an employee but now that I hire people, it is a very insightful summary that captures what a good or smart employer is trying to capture in an interview and I'm stating it here to put some context around the advice below.

Ask A LOT of questions

I learned this trick from a friend while preparing for interviews in university. When an assignment is given to a developer, it is instinctive for your mind to start working. You start making assumptions and taking initiative, which is good, developers are creative minds and that's how it should work, but at this moment it is best for you to pause, slow down and drain EVERY answer you can get from your interviewer. For example, let's say they tell you to build a forum. It is easy to jump and start working, cause we all know what a forum is, we have all used one and we have even made some, so its an easy project... NO, this is a trap. Ask mundane questions like:

1. Who will use this forum?
2. How should it be branded?
3. Do they need accounts?
4. How often does the average user return?
5. Should their session be persistent or do they log-in every time?
6. Does this forum have multiple topics or just one?
7. Do you allow unregistered users to read / post on the forum?
8. Is there a moderation system?
9. How do moderators invite other moderators?
10. etc. etc. etc.

Some of the questions above are silly and in the context of an "assignment" it does not even matter but it is important for you to approach the problem as you have never heard of a forum before. It is tempting to show "initiative" and suggest the best implementations of a forum you have seen or thought about but that triggers the wrong flags for the employer. What the employer sees is someone who thinks he/she knows everything, has their own ideas about how their assignment should be done (Basically telling your teacher how your assignment should be marked) and what is even worse is if you get into a debate with the employer on the best implementation of the assignment... but more on this later.

Asking questions is the best way to show initiative. By asking questions you signal to the interviewer that you are thinking, you are humble and making no assumptions about the assignment, it also signals you are obedient cause you are asking for direction. When it starts to sing is when you ask questions that the interviewer has never asked himself/herself yet, that signals initiative to the interviewer, they are like hmmm, I like the way this guy is thinking and then you both collaborate to find out the answer together and suddenly the interviewer gets a glimpse of what it is like working with you as a team member. It is very refreshing. This strategy also eliminates the gotchas interviewers usually put in their interviews to throw you off base. While asking "silly" questions, the interviewer will be forced to divulge that the forum is for blind people. Something he was gonna toss out at the end when you thought you had conceived the best forum ever. Another good effect of asking questions is when you can suggest features based on the new information you have. For example, you find out the forum is for blind people so you can suggest if they can make posts by talking to the computer instead of typing or if it will have text to speech. You cannot make these suggestions if you took forum at face value.

The developer has to remember that the company started without them and will continue to operate without their wisdom (if they are not hired), because when they go out to look for someone to hire, they are rarely looking for someone to "Save Us" but someone to do what they need to be done, having your own relevant ideas is a bonus to them, not a requirement. So someone who assumes he gets everything about their company from an hour interview is irritating at best. Asking the dumbest questions till you cannot think of anything else is the best single advice I can give when asked to build a system for an interview. It is a shame that this is not well communicated by interviewers when they are looking for candidates because as developers we are taught the opposite.

Concede when you disagree but be clear on your stance

While asking silly questions, you may find your potential employer making decisions that you think are terrible. It is natural as a developer to interject and explain to them why their decision to animate their web page with C++ is wrong, this is a mistake no matter how politely you say this. A better approach is to ask them why they decided to use this tool to execute this task, listen to their answer, ask them follow up questions if needed, truly try to understand what drove such a decision and then summarize what they told you back to them, for example "I understand you are using C++ to animate your web-page because it is an object-oriented language" and then proceed to tell them that you think Javascript can do the same for them and even more in detail and then ask them if this is something they have had a chance to look into, if they persist on C++, concede by saying "Ok, I understand your rationale." and move on. If they ask you to tell them about javascript... by all means blow their minds. This shows obedience on your side and a willingness to learn from them. Getting into a sparring match with them only signals how stubborn you are to them, which is counter-intuitive for a developer because we are in an ecosystem that is democratic. Technologies usually win based on merit, so it is in us to explain logically and factually why they need to re-evaluate their stance, although this is a good move when you have the job, it is not during an interview.

They want you to win

It is easy for a developer to feel that an interview is an obstacle course set up to trap them and embarrass them and make them feel less than, but it is quite the opposite. Developers have to realize that people who work at a company must have more important things to do than to ask strangers hard questions only to watch them fail and laugh about their answers in the company kitchen during lunch breaks. Every interviewer is secretly rooting for you to win. They want this whole process to be over almost as much as you do. It will be great if the very first person they interviewed was good enough for them to hire. Aligning your attitude to the fact that the interviewer is your friend, brings out the smiles in you, the calmness, the jokes and puts your nerves at ease to show your best self. Better than being on edge waiting for the next bomb to drop from the interviewer's mouth wondering if that is the one that will take you out. But why won't the developer be on edge when we call it a "coding challenge". This only gives the vibe to a developer that this is an attack in which they have to defend themselves... but I digress. Understanding that the interviewer wants the developer to win helps the developer ask the right questions and bring the best mindset to the table.

I will like to finish by saying an interview is like a date. The fact that you are there is because they are hoping for you to be "the one". You should also be aware that this is two-sided. You are selling your time and they are buying time. As much as companies like to keep the dynamic they are doing you a favor by hiring you, it is an illusion, they need you as much as you need them, so only take jobs that you are comfortable about the amount of your time they are buying.