Mobile Architectural Interview Done Wrong
Introduction
I am an iOS developer with more than a decade of experience and, at the same time, a Flutter enthusiast. I conducted 200+ interviews and mentored more than 20 people during my career.
About my experience, you may read through my articles, and about interviews, I have one already
About mentoring, you can find some inspirations here
Recently, I had a bunch of interviews with different companies. Today, I’d like to share my experience with one of the interviews where the assessment was around architectural approaches in the mobile world based on the example of a news feed.
NB! I’ve never been involved in a public library development. Thus, everything I say relates to end applications only.
Preparation
When I work around an idea, I prefer using either a physical whiteboard or some virtual equivalents — Miro, OpenBoard, Canva. I think handwriting is the quickest way to express ideas with several boxes and arrow connectors around them. If something goes wrong, the same way — it is the fastest way to erase a thing there. I even have a graphics tablet for such purposes because I cannot draw efficiently with a mouse or touchpad.
Once the first iteration is done, I switch to a more formal design. I express rough mockups and rough relations among UI components; the same goes for the back-end part. And all that is done using simple boxes and arrows but in a diagram world. This way, I can erase the whiteboard without fearing to forget something. I never put implementation details into diagrams as I do not know in what direction the project will go.
Then I do a little brainstorming around the entities I need, and then, upon them, the logic is born. The logic is described in the code, and if shared among different platforms, it is a use case diagram or sequence diagram. I never use class diagrams as they are supposed to change a lot and would have the same value as comments in the code. If you want to know why I am not a fan of that, ask me in the comments, please — the more applause the question get, the more chances I’ll write about that.
Cold Shower
The interview began. After a short introduction, they shared a task orally. I quickly wrote down everything on my whiteboard, which was shared with the interviewers. I started modeling with a couple of boxes, their names, and connections. Soon, I was stopped.
Interviewer: “Please use draw.io and UML class diagrams for modeling.”
They insisted.
Me: “I’m not experienced with draw.io, and I usually don’t use UML class diagrams, so that might take me some more time.”
Interviewer: “That’s OK.”
During my flow of thought, I was constantly interrupted, but I took it as an additional stress resistance challenge.
Interviewer: “Have you considered asynchronicity in your design?”
Me: “Yes, I have.”
Interviewer: “Can you depict asynchronicity on the class diagram?”
Me: “There’s no standard way to represent that in UML, except maybe using custom annotations. I’ll add the async keyword as a marker.”
For me, as an experienced developer, the question was naive, but I did not exclude the fact that I could miss some details, so I followed and added a simple async keyword just to mark the fact of asynchronicity.
Get Kirill Chuyanov’s stories in your inbox
Join Medium for free to get updates from this writer.
Oh, they did not stop on that. They saw that as a Swift keyword and asked me about async/await in Swift, which barely relates to architecture modeling.
Interviewer: “Why have you chosen async/await?”
Me: “It’s just a marker; we could use completions or any reactive library, like Combine or RxSwift, but it is not really critical during design.”
They dropped a bomb on me almost immediately.
Interviewer: “Explain how you would use a class’ method with Combine.”
Me: “I haven’t worked with Combine specifically, but I can explain the principles of reactivity that apply across similar frameworks.”
How is that related to architectural modeling? — I thought. Yet, I took the initiative and explained the basics.
Eventually, I completed the “architectural design,” which looked like a simple MVVM + abstraction over the back-end, nothing sophisticated. It turned out that I depicted 1-in-1 what approach they use daily. I thought I won Bingo if I’d only known how wrong I was.
Pagination
They did not stop challenging me. The next task was to implement the pagination on the dataset we had — the news feed.
Interviewer: “Let’s move on to pagination. How would you implement pagination for the news feed?”
Me: “Although I haven’t had to implement pagination directly in previous projects, I’m familiar with the basic approaches, including page numbers or cursor-based pagination.”
In the end, they are very similar from the mobile point of view. But they asked further.
Interviewer: “What if the feed changes constantly? How would you handle that?”
Me: “Constant changes to the feed cause a challenge to UI/UX consistency.”
Interviewer: “Let’s not take that into account for now.”
Me: “OK, we could use web sockets to listen for changes, though it might increase traffic usage.”
At that point, I was confused and lost. I did not understand what they wanted from me, so I just threw the idea of using sockets. I could’ve continued the brainstorming, but the interview exceeded the time limit.
Aftermath
When the interview finished, I got a reluctant collaboration concern, let’s say. It was evident that we won’t find common ground. My concerns were confirmed in the letter with feedback:
- Tool Familiarity and Efficiency. Demonstrated a lack of familiarity with UML initially. Improved proficiency with tools like UML could streamline workflow and task completion.
- Depth in Communication of Complex Concepts. While able to articulate ideas, explanations regarding advanced topics such as reactive programming lacked depth.
It still resonates with me. The first point is super frustrating. They set up their own turf and expected me to be efficient and familiar with their tools. This could be simply called Knows the tools we work with, and it has nothing to do with architectural solutions, in my opinion.
The second point still is not relevant to architecting a system. Reactivity is an implementation detail, and I do not understand how I am not familiar if I described a simple idea behind any reactive framework — Observer pattern.
Conclusion
The whole process in this company was pretty long, and even on the very first stage, I set the expectations and, as an interviewer, was curious about other stages, so I kept the process. Here, I do not want to challenge their decision; that would be only a waste of time, mine and theirs as well. Instead, others might benefit from my story; you might prepare better for your next interview, e.g., learn a tool that would help you write diagrams or learn a library that you use in more depth.
But I would love to hear your feedback and your thoughts on the architectural stage and this example in particular.
After that stage, there was a behavioral one with some contradictional aspects, but I will cover it later.
