I recently had an interview where I felt that I wa...
# android
m
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?
not kotlin but kotlin colored 5
😂 5
e
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?
m
No, I use a single activity and use composables in many screens and root those screens in an activity
e
Okay cool got it. Just what I thought.
Now, to actually address your question, first:
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)
What does this mean 🤔? especially the last part, what difference would it make if it was a manager or a dev? As to whether you were wrong, I mean there are no wrong questions but the sequence of your questions couldve seemed to be pointing to some assumption you were making about the interviewer or the company and thats what I believe they were reacting to. I think the interviewer however overreacted in this case and they shouldve probably acted differently
m
a lot of mangers arent really hands on with their team and or may not come from mobile platform background
e
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 😕
p
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.
The attitude he showed when you told him about the compose without Fragments thing, is not right on his side either. It makes him look like the type of developers that is really closed to accepting any solution other than what they think is right. Which is a bad thing too, he should have listened to your proposal. Then, saying something like, well you are right, but we have adopted the Fragment based approach and is used heavily company wide. I would explore the idea of removing the Fragments in new projects. However, is to heavy to refactor old modules, let's explore your idea only in new modules. But perhaps they are not modular yet, so in the case they are monolithic then tell you that your approach is good but unfortunately they went down the Fragment road. At that point me as an interviewer would reverse the question for you and say, are you willing to work only the Fragment solution because we decided is the best approach, and if you answer yes/no, then at this point is clear the company interest match. In general, what happened to you is that you didn't match that team. I wouldn't use the word disqualified but mismatched.
m
@efemoney thanks you have point
@Pablichjenkov i agree, if this was happening while on a team i assume the architect or manger would be the final voice when looking at these type of approaches.but thanks i will treat this as a learning experience and try to take your approach if this ever happened again.
👍 1
p
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.
👍 3
c
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.
👍 1
b
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.
p
Interesting
a
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.
👍 2