I went through some interviews and met some classmates.
Being asked by an interviewer about pins and needles on the scalp can leave candidates red-faced.
Once resented the question to be difficult and mean, also suspected to ask off topic.
After experiencing the role of attack and defense, sink down and review the past, can not help but sigh. If I have to make an analogy of a job interview, I would like to compare it to a blind date.
The analogy comes from the fact that seemingly objective technical interviews are riddled with subjective judgments. “How good a candidate is for the interviewer” may be a little more important than “how good a candidate is.”
The world is so big, and Android knowledge is so vast, that I doubt myself from time to time, especially when I pass a candidate. “Is there a limit to my knowledge?” “And” What I think is critical, is it really that critical?”
With this doubt in mind, I’ve made a summary of my interview preferences, and I welcome your advice.
Ps: This post will focus on Android application layer development interviews.
Octagonal questions
- How many launch modes does an Activity have? What are the characteristics of each?
- How many types of services are there? What are the application scenarios?
- How many ways are there to register for broadcast? What’s the difference?
- What life cycle callbacks do activities have?
- What are the extension functions in Kotlin?
- What is the JVM memory model like?
- GC collection algorithm?
- How many reference types are there in Java?
The characteristic of this kind of question is “just need Baidu to get the answer immediately”. Candidates who have done enough preparation and brushed the questions can recite them backwards. But these questions are also valuable as a quick indicator of whether a candidate understands the basic concepts of Android.
Number six and seven, I don’t like to ask. The reason is “What are the visible benefits of mastering this problem for application layer development?”
Computer complexity is high, layering is a common method to reduce complexity, layer between layer formed barriers, but also improve the efficiency of the layer. Understanding the complexity of a single layer can take a lifetime. It is not to deny the value of digging deep at the bottom, learning can certainly get through several layers, but as an Android application layer interview, the focus is still on the technical details of the application layer. (My personal opinion, welcome to clap bricks ~)
However, if the interview is full of eight-part essay questions, it is not fair, too favoritism to the rote memorization, and may pass the candidate who has strong ability, but is not well prepared for the basic questions.
Primal problem
This type of question is intended to test the candidate’s technical depth, in terms of the technology they know how to use, why they use it, and how it works. Such as:
- How does Android messaging work?
- How are Android touch events passed?
- How are Android views drawn?
- How does Android communicate between different components? (Across processes, across threads)
- The Activity startup process?
- AMS, PMS, WMS creation process?
- Handwritten message into MessageQueue algorithm.
- RecyclerView cache mechanism?
The original question can also be baidu out, but may have to read a few blogs to digest, and finally use their own language to organize, in order to answer in the interview.
This kind of question is different from the eight-part essay in that it not only examines the technical depth, but also examines the ability of understanding, analysis and summary expression. It is also a kind of ability to express the original rational things in simple and concise language and make people understand.
I don’t like to ask questions like # 5 and # 6, but for the same reason I mentioned earlier, “What tangible benefit does answering these questions have on application layer development?” . If you’re interviewing for an Android development project, it’s worth asking.
The seventh question will be the combination of reason and algorithm, not to write algorithm, but in the understanding of the principle of the algorithm based on the ability to achieve. If you memorize principles, you usually can’t write them down.
Project experience questions
These questions are designed to assess the candidate’s project experience and technology stack. You can also ask about the rationale behind a used technology stack.
These are the most demanding questions for an interviewer, and it’s hard to ask good questions about a candidate’s tech stack without a certain breadth and depth of skills.
Scenario questions
Scenario problems are designed to be solved by candidates on the spot.
All the previous questions can be prepared in advance, if the preparation is sufficient, all won is not a problem. You can’t prepare for the scenario.
- As shown: Press and hold the View, move it outside the View boundary and release it. What touch events are passed during this process, and how are they passed?
- To do a 1MB x 10 frame animation, what is the best way to optimize memory?
- How do I prevent the search box from making requests too frequently?
- How to implement barrage?
- How to design the broadcast room gift queue?
- What aspects should be paid attention to when designing an image asynchronous loading component?
Question 1 scenarioizes the primordial questions and is unfriendly to rote memorization.
These questions are all technical problems that may be encountered during application layer development. Scenario questions are open and have no unique solution. Candidates’ ideas, skills accumulation and comprehensive application ability, and even ability to work under pressure are examined.
However, situational questions also have a fatal drawback. They are limited by the knowledge and experience of the interviewer, so they can ask as many questions as they have seen the world. If the interviewer’s experience happens to overlap with the candidate’s, the two may be happy. So this kind of question is not fair, just like blind date, a honey b arsenic is likely to appear.
Problems in demand disassembly and estimation
A real iterative requirement is presented to the candidate, the business requirement is broken down into technical steps, and the time of each step is accurately estimated.
Do not look down upon “demand disassembly”, first of all, we have to deeply understand the requirements, can the product want to express the understanding in place? , can you express what the product wants to express? During the actual iteration process, it is not uncommon for the product and the R&D to have a different understanding of the requirements. Will the candidate become good friends with the product?
Can you break down the business story into technical steps based on a deep understanding of the requirements? Evaluate the candidate’s technology stack and comprehensive application ability, technology selection and implementation plan are reasonable? Are scalability or performance optimizations taken into account?
“Estimate time” shows the candidate’s proficiency in technical implementation details. Assuming that “implement paging framework with ViewPager + Fragment” estimate time is 1 day, it indicates that they know what technology to switch to, but have not practiced it. But this estimate is ideal because it doesn’t take into account the current state of the application’s code.
These are the real issues that candidates encounter in each iteration after they are hired. It is not easy to “disassemble properly and estimate accurately”, but it requires a deep understanding of requirements, extensive stack experience, and a thorough understanding of the existing code framework, which is a sign of mature development.
You can’t find a more pragmatic interview question than a demand breakdown question. If at first you feel insecure, try dating once.
conclusion
My preference for interviews is listed in ascending order, but my level is limited and my experience is limited, and the Android application layer interview can only stay at this stage. Still hope the gold digger god to enlighten ~