5 aspects of a bad interview

From my Android experience

Repeat questions

The alternative

Cutting off additional efforts and ignoring them

The alternative

Live coding session with Android app

  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

The Alternative

  • 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

  • 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.

The alternatives

  • 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

--

--

Love being creative to solve some problems with an simple and elegant ways

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Michael Spitsin

Love being creative to solve some problems with an simple and elegant ways