I have interviewed more than 100 different people throughout my 7-year career as an Android engineer. In this blog post, I would like to share some very easy questions that I often asked during phone screens and even some normal interview rounds.
These are all fundamental stuff that I wish all Java/Kotlin programmers knew, but practice shows that still many people are not able to give a complete or correct answer to them. I hope someone finds it useful for their interview preparation and won’t make mistakes in these basic questions.
Intro
Introductory pitch
I often see people recommend preparing a pitch about your background and using it during the introduction part of the interview. Out of all candidates who I interviewed, I didn’t remember any of that and it didn’t have any impact on the interview results. So, I recommend not wasting your time, limiting the intro to just a few sentences, and getting on with the actual interview ASAP.
Pro Tip: Keep your introductory pitch as short as possible.
First impression
To get the first impression about the candidate and also help them feel more comfortable, I usually ask about their recent experience or what is their favorite thing at work. It’s a “Tell me about yourself” question, but more specific.
Question. Tell me about some interesting or challenging problem you worked on this year.
This question allows me to assess person’s communication skills and is supposed to help the candidate relax. After all, I am asking about something they are very familiar with and should be comfortable talking about.
Sometimes, I would get candidates who would tell me that they didn’t have anything interesting or challenging in their past project. Some people had something interesting but would struggle to explain it to me.
Question. What is your best skill in software engineering? Is it building the UI, thinking and iterating on the architecture, debugging, etc…?
Or sometimes I would ask
Question. What is your favorite type of work in software engineering / Android development?
Asking this type of questions helps me understand what motivates candidates in their work. It also allows me to choose subsequent questions, based on a person’s strengths/weaknesses.
There is no right or wrong answer, of course, but what candidates will tell and how they will tell me will give me the first impression. Saying “I don’t have a preference.” or “I am good at everything” doesn’t carry any information. If you had years of experience, there should be something you are better at or something you like or hate doing in your work.
Pro Tip: Be passionate about stuff that you do and know what you are talking about.
Technical questions
After chatting about the candidate’s experience and motivations, I typically switch to technical questions. Depending on what interview round it is, it may be more focused on coding, Android framework, or architecture.
Java basics
Question. What are the methods in java.lang.Object class?
This question touches Java fundamentals and I use it to understand whether the candidate is familiar with equals/hashCode, wait()/notify() and finalize(). The conversation will often lead us to the topic of HashMap or concurrency or how memory works in JVM.
Other questions in this family:
Question. When do you need to override equals / hashCode? What can happen if I don’t override hashCode?
Question. How are objects compared in Java? What about arrays?
I still get candidates with several years of experience telling me equals compares by class fields automatically.
Kotlin basics
Kotlin has been an official programming language on Android for years, and many companies have switched their entire codebase to it. Knowing this programming language is not a requirement, because it can be learned pretty quickly. However, when a candidate tells me they write in Kotlin, I at least ask some basic questions to check their understanding of fundamentals.
Examples of such questions:
Question. What is a data class and how does it work?
Question. What is Any, Unit, and Nothing in Kotlin?
How can you use it all the time and still be unable to give a complete and correct answer about it?!
Pro Tip. Study the basics of your programming language.
Network basics
Android engineers often build apps that interact with multiple API. We have to understand the basics of networking. To check that, I typically ask what happens when you go via URL in your browser.
Question. What happens when you enter a URL in your browser and hit ENTER?
Even better:
Question. What happens when I call an API method in my Retrofit API?
I like this question because it touches on client/server communication. I especially like to ask a candidate, who mentioned REST or Retrofit in their resume. It creates many topics for starting a conversation and tests a person’s depth and breadth of knowledge.
Depending if this is a technical phone screen or an on-site round the expectations are different. On the phone screen, I’m satisfied if we just touch on the basics.
On the on-site, we usually go deeper and talk about reflection, error handling strategies, how OkHttp client works, types of APIs, serialization, HTTP and other protocols, data encryption and security, caching, DNS, and all the other networking stuff…
Pro Tip. Know what happens during client/server communication.
Programming skills
Some of my colleagues like to ask FizzBuzz to sanity check a person’s ability to think and code. I find it too common and replace it with another trivial problem.
Question. Given a 32-bit integer, return it with its digits reversed. You can use any function from the standard library.
This is a Leetcode Easy problem, with all conditions dropped. It can be solved either in a mathematical way with division by 10 or by reversing a string, both of which can be written in under 10 lines of code. Only 50% of the people I interviewed were able to write a working solution in 15 minutes.
Yes, in real work you won’t be reversing integers. However, you will be working with numbers and strings, parsing data from files and network streams. This type of problem might come up during your work. Remember, I don’t only focus on the solution itself, but also on how arrived at it, what type of questions they ask and how they write their code. Clarifying questions, thinking about edge cases, communicating well, and writing simple readable code is as important as having a working solution.
Pro Tip. Approach the problem as if it is your work project.
Final thoughts
While the listed questions are quite easy, not everyone can confidently answer them. What I often see during the interviews, is that people try to guess the answer or have some invalid assumptions in their head about how things are. As a result, they are just giving incorrect answers. It is ok to not know something, nobody is perfect. But you should be honest with your interviewer and make sure to tell them that your answer is based on an assumption or you are just trying to guess it.