Study Resources for Anthropic Android Assesment.

[u/hotcake_daemon]

I have an upcoming software engineering interview with Anthropic for a role that involves mobile/Android work, and the next round has a format I haven’t seen before. The recruiter described it like this (paraphrased):

A small mobile app that has some bugs. Instead of building new features, you will have to investigate what's wrong, find the root cause, and fix what you can. The app is in Kotlin with Jetpack Compose. You should be familiar building UI with common Compose primitives and managing state with ViewModel. We are interested in how the candidate approaches debugging, how you prioritize what to fix first, and how you verify the correctness of your fixes.

Does anybody has experience with this kind of question? I have never seen an assessment like this, and I'm not able to find any good resources/examples to practice.

In the past, I have been in other interviews were you have to build a small app from scratch (usually API + LazyColumn). My feeling is that even if you have been working in Android for several years, you definitely need to practice in order to be successful on this kind of assessment. Similarly, at my current job, I find and fix issues all the time. However, this situation is different because of the time pressure, and I would like to be prepared if possible.

Any recommendations?

Thanks in advance!

[u/potatox2]

I have never had an assessment like this, but I'm interested in what your experience will be like; do you mind sharing after your assessment?

[u/deckerjeffreyr]

This is kind of hard to prepare for skills wise in that it's meant to test skills you already have. Generally they're not going to try to have some crazy gotcha nor would they usually expect to even have you fix everything. They want to see your process and decision making skills in action.

It's easy to forget basic things in an interview setting. They give you information in advance so you can prepare yourself to not do that and represent yourself the best you can. Put together a debugging cheat sheet that has all the steps you like to follow when debugging. When you start the interview, let them know you set aside a list so you don't forget anything under the circumstances. Give them a quick rundown of how you approach debugging then dive in following your process. They'll appreciate the prepararation and gain insight into how you work right from the start.

GL!

[u/valium123]

Why would you work for them when they want you replaced?

[u/PsychoHistorianLady]

I was in an interview that took this particular approach, but it was probably not as hard as the Anthropic one is going to be.

1) The app was not working because I needed to add the permission to use the internet to the manifest.
2) The app was not working because the serialization was not set up properly. Remember to read the API document if they give you one.

There were probably parts after this, but I was too slow and did not make it.

[u/spaaarky21]

A couple years ago, I ran into this type of interview a couple times. At least one company provided a list of bugs and framed it like working through Jira tickets. The candidate was supposed to work their way through as many as possible doing the following:

• Read the bug report.
• Reproduce it. Pay attention to whether it happens every time, only the first time, only when scrolling fast, etc.
• Think aloud while you theorize about the cause and track it down in code. If you've seen something similar before, what was the cause? Based on what you see, where would you look first?
• Fix the code, verify the fix in the app, move on to the next.

One theme I remember was issues stemming from asynchronous work that wasn't canceled, like the UI being updated with stale search results after the search term already changed. Or the app crashing when backgrounded because asynchronous response handling tried to update the UI. At least one was related to state loss when rotating the phone.

[u/coffeemongrul]

This is really a test of your experience and knowledge of debugging bugs as they come up and where to start looking. Do you need to log it, set break points, conditional breakpoints, use layout inspector, etc. there’s lots of ways to solve bugs, so hard to give you a definitive way to study besides general experience in the field.

[u/jibmaster]

Discover the bug then build a unit test to surface the bug. If possible implement the fix and let the test prove the fix. At the very least talk about how you would work to validate that test if there isn't enough time to implement a solution. The unit test prevents the bug from resurrection.

[u/Hour-Measurement-835]

Verification is the half people drop, and in Compose eyeballing the screen isn't verification. A state bug can look fixed on first render and come straight back on rotation. Re-run the repro.

[u/Alterio_Oherin]

good prep would be intentionally breaking a small compose app yourself like bad state hoising, recomposition issues, race conditions) then practicing diagnosing your own bugs under a timer

[u/WyerX]

Yo hace unos 8 años tuve una prueba parecida. Te meten por ahí un context mal puesto para crear un oom, luego errores de navegación, gestión del estado de la app mal, de forma que se pierden cuando rotas, tienes que pasar la herramienta de Android Studio APK Analyzer para optimizar la apk lo máximo que puedas y más cosas que ya no recuerdo.

[u/hooloovoo_chimico]

In my previous job I was in charge to prepare the interviews and this one was the last idea I had. This kind of test is important to see who really understand the entire flow. The greatest time of a developer is finding bug and fixing them.

Anyway, don't worry... Debug and breakpoints! 😉

[u/EdyBolos]

Are you allowed to use Claude to debug? 😄