5 aspects of a bad interview

From my Android experience

I participated in some interviews. And from time to time I noticed, that I don’t feel comfortable on them. Sometimes I had great interviews, where I received negative feedback, but still, I thought “Yeah, that’s fair. True. Understand”. But in rare scenarios, I had a wow-effect experience. And I thought “Well, why? What are you trying to know about me? Really?”. I want to write today about those aspects.

Note: I will not put names of any companies for my own reasons, but situations, that I will describe are real cases.

Repeat questions

Years ago one company wrote me and they asked me to write a test task. An app for monitoring currencies rates with live updates and the ability to enter different amounts for each currency. The first attempt was a failure. Despite the fact that I provided the working solution & even some unit tests, the company responded that the picked architecture of the solution was wrong.

3 years passed. And they came again. Well, okay, why not. But again they provided test tasks for me to implement. I thought “Okay, I’m ready if the task will be interesting enough”. And they provided me absolutely the same task they provided 3 years back. 5 mins after they received my response with completely the same solution.

Now it worked. And they invited me to the live session. But the most interesting part is the live session. They started to talk and said, that it will be some coding session. I agreed. They asked me to turn on my Android Studio and… they gave me completely the same task as I received before.

Of course, I nicely asked to quit the interview and explained that it is not quite professional from my point of view. Because if they gave this task, that means they didn’t even look into my home test task.

I think it is important to make your hiring mechanism clean and working 100%, so you will not have any issues with candidates. Such things as repeating questions are just saying that something has broken inside your mechanism. And also there is a feeling that you don’t respect your own time and the candidate’s time.

I remember, that those guys didn’t even apologize and didn’t propose to move the interview some days later after they will have a chance to look into my solution.

The alternative

Don’t repeat yourself. Famous engineering principle. Here it is applied too. Sure there are some times when you have different iterations, and you may ask a question on the same topic as the previous interviewer had, but for instance from a different angle.

But generally that just not looking great. There are so many topics and things to ask. And when you ask the same question or give the same task, it just feels like you don’t have anything else to discuss. But more importantly, it feels like your hiring system is broken. And if it is broken, why should the rest of the processes inside the company be fine?

If you ever allowed this situation to happen (I mean you give the same task on the interview as the test home task), then I think the best approach here apologize and propose a different date of the interview, when you will look into the candidate’s solution.

Cutting off additional efforts and ignoring them

I remember I had a proposal for an interview in one company. But before they proposed to write a simple test app as homework. They gave me as I remember 2 days for that. The task was really simple

You need to write an app that has search field in the center. You write something and then press search button and the second page is opened. On the second page you need to google what you wrote and extract some images and show them as a grid list. You can use any libraries you want.

Back then I was really thrilled with Android development (I am right now, but those days were the first years of my career). So I decided to add up some additional things to make an impression. That I love engineering and strive to provide additional handy animations, some information for the user that might be useful. That I’m not just invoking my job, but trying to jump higher and make an ideal app even if it is a test app.

So I provided animation to transform the “search” button into a progress bar and make it disabled (with animation too), so it would not be clickable. I provided a small bar under the toolbar signaling when there is no internet connection and when it is back. I made a smooth transition from one fragment to another. And other small things. Most importantly, I didn’t spend on it more time, than I was given.

Then I had an interview. A few questions after the lead of the department said: “I read your solution. Why did you add all of that? Your task was simple. 2 simple pages and small request” — then he grinned — “And you added those hundreds of lines for what? Who did ask you for that?”.

That was harsh actually. Before that, I had never been blamed for adding extra features. People liked my extra efforts and always thanked me for them (even if they didn’t need them). And I always do that when the candidate sends to me not just a solution but the additional handy things.

I didn’t have the guts back then to just stand up and leave, because probably I was too young and something stopped me. But I’m pretty sure right now that this should be a red flag of the interview. Actually, it was a outsource company, and then I understood that some outsource company just does not care about the quality of the apps, they more care about earning money and getting the job done (some but not all of course). That’s it.

Here is another example. I was asked to provide a simple chat on the prepared API. One page is a chat list, the second one is the message list. What the company asked is to make it really quick.

I decided to put all my efforts into that. And btw, that was when this article was born. Plus, I put some effort into creating a special photo grid. It was some kind of collage that would be generated automatically, considering the different size and aspect ratios of the photos.

I remember that feedback. “App is working but there is a mess in a codebase”. Well, I agree, that there was a mess, but still, it was a second time when my additional efforts were ignored.

What I’m trying to say by those two examples is not that I like to receive some appreciation (of course I like as we all). I think that those are just good manners to thank the candidate that he spends his additional time on it. Because it means something right? Maybe it means that the candidate loves his job, or that he really wants into this company and tries to make an impression.

And the completely red flag is when you directly say that his job was useless and not needed. Because that means for him, you will say something similar to his/her job.

The alternative

Very simple. Just appreciate additional efforts. It always means something.

And if you ignore them for the test task, why wouldn’t you ignore them, when the candidate will become a part of your team?

Live coding session with Android app

Well, this is an interesting one. Personally, I like coding sessions. Moreover, I think, this is the general way to check your brain capabilities without going into deep-deep detail. After all, we are solving different tasks and face different areas of our work, and it is hard to match the specific theme with a specific candidate.

But I’m totally against Android Live codding sessions. Why? Because:

1. The interview is a stressful thing. And I mean it. Especially when it is an interview with the company you want to join. Sometimes you have 3–4 live sessions (coding, system design and etc). Sometimes you have 1 big 1–2 hours session with everything inside. Sometimes you have min 2 interviewers on the other side. Sometimes there are 4 persons.
   
   Indeed, the interview is very stressful. And it is more stressful when you have a coding session. Because you need to be focused (you writing the code after all). At the same time, you should «speak loud» so the guy on the other side will understand, what you trying to write.
   
   Now imagine that instead of writing one small method (okay, maybe 2 or 3), that solves some relatively simple task, you need to use Android Studio and write the whole app.
2. If it is not just «Hello world» app then you possibly will write something more, than just a simple activity. You probably don’t remember all methods from API, some methods (as we all Android engineers know) have some nuances, some methods are already replaced with a new version of Jetpack’s KTX analogue. It is hard to keep all of it inside your head. So you probably will go and google it.
   
   Moreover, some people (me as an example) like to write everything in one or several places and improve approach or local architecture solution as the solution gets more and more complex. This means you will spend some time rewriting the code twice or trice before you will get the final answer.
   
   And all of that is fine, but not all engineers like to share all internals of their working process. We have a code review as we remember, not a live-code review when you track every character written.
3. The second item leads us to a simple conclusion. You as an interviewee will spend time rewriting and investigating solutions. You as the interviewer will waste time watching how the candidate digs in internals instead of spending it on something useful. For instance, ask broad theory/practical questions.

The alternative

• If you strive to get from the candidate the android knowledge it is better to propose to him a broad theme question that does not have the right or wrong answer. For instance, you can ask «If you were creating the mobile app, what routing approach would you choose (for instance, single-activity or one-page-one-activity) and why?» or «If your BE team requested from the app providing some internal log, how would you organize the process of sending them?»
• If you want to see how the candidate writing the actual code, then a simple algorithmic task would be more than enough. You will see, how he/she writing the code, what naming is used and etc.
• If you want to have a conversation about some Android App creation, just have a small system design session. Just give a broad task like «Let’s create a Taxi application» or «Let’s create our implementation of Firebase messaging system» and let the candidate express her/his solution and provide some questions if you are interested in some details.

Asking very specific things

Oh, I love this one. I had some interviews like that. And most of them were in Russian companies. People love to ask some very specific things and sometimes they just don’t care that you didn’t work with such things, so you obviously don’t know. In that case, they ask you to think or guess.

Once again. The interview is a very stressful thing. And let’s just ask ourselves and everyone «what are you trying to achieve? Who are you searching for?»

Well, there are some companies (it tends to outsource company), when people ask you specific things because they need a «robot» who will just work in this area and provide fast solutions. Why fast? Because otherwise, you don’t need to know, that password is better to store in CharArray instead of String. You can google it and read about it when you will face with this code or will have to write this code. But it will slow down things. Much faster if you already know that.

But if your company looking for an engineer in the first place, not just a developer who working with a specific list of things. Then this approach has some flaws. For instance, in the aforementioned CharArray for a password, you could just know the answer because you have read JCA Reference Guide, but at the same time, you can not master a good relationship between the objects in the code. For instance, you don’t know how to apply the Decorator pattern where. This is a much more important thing because you work with classes every day, but with passwords rarely (in usual apps at least). Moreover, you could just guess. :)

I had this exact question in the interview. And I failed to answer, I admit that. But the reason I mentioned this topic, is because this question is too specific. More importantly, that there is a JCA recommendation, yes, but also there are a lot of discussions on this topic, which means, this is not the right interview question when you have to ask simple “yes/no” questions to count some candidate’s score.

The Alternative

Just stop applying your newly received knowledge about some narrow and specific thing and torture the candidate with it.

• If you want to know about candidate's knowledge, better to ask some basic and broad things. Because my experience shows that people like to dig into Rocket Science but not master the basics. People can not recognize when to use decoration, and how to effectively apply Command Pattern. Moreover, not everybody knows about the pluses and minuses of Singletons, and where to use them. And you trying to ask them how to build a nuclear engine (and surprise-surprise, some people know that, but don’t know how to apply the Adapter pattern). :)
• If you want to see, how deep can be the candidate’s knowledge (does he/she like to dig into problems to find the most appropriate solution) then you can ask something «what the hardest task you worked on?» and let him speak. Let him express how he/she tackle hard things (you can even provide the list of such possible questions before the interview, so the candidate will prepare instead of sitting and trying to remember). If the candidate can not prepare for that or does not have interesting tasks or can not describe the situation, then it is already a warning flag for you as an interviewer.

Making the interview turned into an exam with right/wrong answers

Yes, I already mentioned that in the previous section, when noticed that some interviews have a scoring system. This paragraph is about a slightly different thing.

• There are interviews when you receive 10–40 questions with answers and you need to pick the correct one. Such interviews tend to turn everything into robot work. Although I don’t like even this approach, it is a pretty discussible one. Probably it is usable if you make this test a quick online part for filtering out some of the candidates. But what's worse, when you have this paper with test questions right in the onsite interview. Imagine, you and two interviewers sitting in one room. And instead of speaking about you, about some problems, let you express your thought, they give you pages with some questions. And when you say “Oh, I didn’t write on Java 3 years already, I don’t remember that, but I know how this will work in Kotlin”, they will answer “No problem, try to guess”.
  
  Try to guess. And if your guess is right, you will earn the point. If you’re wrong, you will not earn it. Why? What it will give you as an interviewer?
• And there is a different scenario. You can receive some questions that should be broad enough but instead, you already placed in limitations that are imagined by the interviewer. For instance the questions like “Why MVI is a better architecture approach than MVP?”. Who said that and why? And what’s the input data? What app are we building? And why we can not use different approaches in different features (which will be placed in different modules)?
  
  Now you sitting trying to explain that there is no better approach, and both of them are pretty much the same in testability and maintainability and there are nuances that you will solve specifically for your project. But you already have less score, because you think differently from the interviewer.

I think as more mature and experienced the engineer gets, the more he/she understands that interview is a two-way process. The company is not the only interviewer here. The candidate is an interviewer too. And he also can give you a score. And if she/he sees that the company is doing only “right” solutions by giving such monosyllabic, plane questions, then he may be surprised when he will discover that internally there are some “weird” looking personalized decisions, like custom routing, or slightly changed MVI, or etc.

The alternatives

As I said if you looking for a robot who is sharpened for the exact knowledge you need, then you are fine. You know that you hire this guy, and then when trends will be different, you can fire this employee and hire a new one.

If you looking for an engineer, this is a bad idea. People are persons. They can have their experience, which can be richer than your as an interviewer in some questions. And in other questions, your experience is richer than the candidate’s one. And that fine. That’s why it is important to have a discussion. That’s why it is called an “interview”, not an exam.

You can check any interviews with movie stars, politicians and etc. Do you see exam questions there? No. Just broad questions or questions about specific things without intention to receive simple “yes/no” answers. This is a discussion to get to know the interviewee better and deeper, to understand his position on different topics.

So be like that:

• Do you have tonnes of candidates? Pick 5–10 whose resume is most impressive for you and have less amount but more quality interviews.
• You want to ask small questions with fast answers, because if you have a 40–50 min session with a small live coding task. Then just ask a simple question like “What is the difference between dp and sp?” or if you have slightly more time “Why the fragment was presented initially? What benefits nowadays do you see for yourself?”

Afterwords

Indeed the interview is a hard thing to master. Like everything in life, I think. And possibly for every topic, there is a counterargument that explains why this approach is good in some scenarios. If so, please, share it in the comments. I will be glad to read them. :)

If you liked that article, don’t forget to support me by clapping. If you want to support me more, just subscribe to my blog and keep an eye on new articles. Also, if you have any questions, comment me, and let’s have a discussion. Happy coding!

Also, there are other articles, that can be interesting:

Stop rewriting projects

Think twice when you ready to add new library in project

Why it’s not bad to go on interviews