I recently had an interview where I felt that I was taking a trip back into 2018. I’ll cut to the chase and get to what caused the iterviewer to get upset with me. He asked a number of questions and I answered them correctly, none of the question really pertained to jetpack compose for example He first asked about a recycler view. I told him about implementing your adapter and layout manger and proceed to let him know that I haven’t used one in about 3 years since ive using compose and let him know I’ve only have been using lazy columns and rows. He asked me the lifecycle of a fragment and how one works.. I gave him the answers but I told him to behest I haven’t touched a fragment outside of refactoring since since 2021. He follows up with asking if I just use activities and I said no I follow the architecture of one activity to many screens. He went on to the next questions. Once he was done with his questions, he allowed for me ask mine I started by saying not to be rude but what is your position with the company I was interviewing for(I honestly ask this from a innocent point view, I’ve had tech mangers interview me before and I understand it may not always be a developer conducting the interview) He responds with I am a developer on another project. I follow up with okay, so would I be refactoring old code into new architecture and practices because based on the questions it sounds like you guys are still programing in java and xml. I guess that is what set him off. He basically yells at me and tells me that they use jetpack compose and that the way I speak of not using any fragments and one activity is impossible and how can I do that. I follow up with its possible I’ve done two projects and one is open source if you would like to see. The idea comes from handling state and events through composables and fragments are some what deprecated and before I could go any further, he cuts me off and ask if I had any other questions and before I could say anything he left the zoom conference room lol. My question is, am I wrong lmfao?

Interested in the last part, will come back to the other parts soon. Can you link your repo where you have this architecture? Do you mean you do Single activity with Composables?

No, I use a single activity and use composables in many screens and root those screens in an activity

Okay cool got it. Just what I thought.

a lot of mangers arent really hands on with their team and or may not come from mobile platform background

Yeah but that is an assumption you re making about this manager/dev. Extrapolating from some (frankly) subjective stereotype to them is not great. My guess is that this person picked up on this underlying reason you were asking that question 😕

Interesting story, this is my take on it. All companies have legacy code, which, at some point was the best code, that's why it remained in the repo. A common practice companies do, is hiring people to maintain these projects while the most experienced engineers work on new technologies. The reason is the experienced engineer knows the business logic better so it can integrate the new tech better than a new hire. On the other hand, that practice allows the new hire to get familiar with the business logic by reading and suffering with legacy. I believe in your interview, perhaps the hiring developer thought you were not interested in work/maintain old code or that you would be the type of new hire that is always complaining and criticizing existing code. And the fact that you mentioned the word "refactoring" is really scary. I believe that was what happened. So, if you are not really into maintaining old code then is ok, there was simply a mismatch between the company interest and yours, which is ok. You and them didn't waste time. My advice is that if you want to expand the range of opportunities to get hired. Let the interviewer know that you deal with any type of code , old APIs new APIs anything.

@efemoney thanks you have point

It is hard to find a team where everyone agrees on a specific solution. Usually my rule of thumb is, when joining a team or trying to join, then be the most acceptive possible. Then as you gain more insights of the team and the company, you start pushing your solutions a bit more. But at that point you already know the team, the style of coding, the developer technical strengths, so many things, and is different. But at the beginning it is all about listening to others commands, basically.

All companies have legacy code, which, at some point was the best code

That's the case for some legacy code, but in my experience, a lot of legacy code was never the best possible code.

I can't speak to the specific technical details, but your story reminded me of a hiring process where the initial interview went well, but then I had a second interview with a couple of programmers who were very proud of their horrific hash of an inheritance hierarchy. I don't remember the particulars, but I criticized it as diplomatically as I could, but it did not go well, so of course I received no offer, but, having seen their pride in their horrendous architecture, I didn't really want to. This is a bit off-point, but there was another interview where I asked how they prioritized and they said "Everything is a priority." I replied "If everything is a priority, then nothing is a priority, I don't think I want to work here." Just a few months later the company folded and everyone lost their jobs.

Interesting

Little bit lighter read.. :) The code is either hot or cold. If it is hot, keep cooking instead of lighting new wood. Keep adding wood as necessary. Don't bother about the kind of wood. Just worry if it is hot or not.