Question: Describe a time when someone on your team challenged you to think differently about a problem.
Answer: One of the projects at my current company is an Angular migration. First started: Angular 1, looking to switch to Angular 2. The initiative was there, but it came down to the implementation. I spent some time to learn about the project and implemented something. A month later, I felt that it was getting too complicated. The project involves a form. Inside that form, input fields depend on communication with each other (e.g., disabled state). We were managing that on the controller. Replicate that on the form, that process became expensive. The wiring had to be manually done. It grew unmaintainable and ugly.

Q: Were you involved in the first version of the project?
A: Yes. Someone in another team suggested Redux. I didn’t know about it before. It gave me a new perspective on data-driven development. I was uncertain at first. It changed the whole paradigm for the project. It would take some time to adapt. I felt hesitant because Redux was new to me, and I didn’t understand it yet. I spent some time listening to explanations. Later decided to go with Redux. I implemented some features using it. It was a challenge.

Q: How did you learn more about Redux when you realized you needed to know more to make a decision?
A: First of all, the teammate who proposed it called a meeting to present how Redux could solve the issues they had. The introductory session was to explain Redux and offer a path forward. I was researching the Redux documentation. I took a relatively small task, implemented a reducer and some action subscribers. I took part in designing the store.

Q: What was the outcome? How did it work? Was it good, ultimately?
A: Yeah, it was good. Redux has a few advantages. It’s a single source of information. If the state changes, anything interested in the state can subscribe and get updates. You don’t have to do the manual wiring process. You just need to put it in the right place. The one downside: sometimes, a change is triggered for no meaningful change. It probably has to do with store design or something. The store changes, but not the content. Components still react to the change even though the content is the same.

Q: Knowing what you know about Redux, what in the store design could cause this to happen?
A: For example, if I have some data in there, it’s basically a JavaScript object. Somewhere deep in the object, we have some tiny fields being modified. A change there will propagate. That might be necessary because the parent might not care about the particular child. What I’ve done right now, if it’s not a change we’re interested in, discard it. It could be the store design, or it might just be Redux.

Q: So right now, components have to discard these changes they don’t care about manually?
A: Subscribe to some of the states that a subscriber will be interested in. There, we implemented a no-op branch in case the state change.

Q: Alright, as a thought exercise, what could you do to restructure your store to avoid this? You know, since you have this nested object with child changes?
A: We could flatten it out. That might not be desirable, though.

Analysis

Competency asserted: Learn and Be Curious

Vote: 👎

The candidate shared a story about his team’s work on migrating from Angular 1 to Angular 2. During this migration, the team recognized issues caused by the patterns they had used before, e.g., the tight coupling of state changes to several different components.

A teammate organized a presentation to encourage the team to adopt Redux to manage this state. After this presentation, the candidate took some more time to learn about Redux by reading the documentation and taking a small task that involved implementing a reducer. This wasn’t really an example of this LP, so I asked him more about the issues the team ran into.

For example, he noted that all components would update even if they didn’t care about a specific state change. I dug for possible solutions on the hope that he had dive deep into Redux. Still, he struggled to identify any and could only identify a possible solution (i.e. a flatter Redux store) after I hinted at it.

The candidate has Angular knowledge but has not translated this into a deep knowledge of the underlying web technology. This is a concern for a frontend engineer because he would be expected to deliver on projects that don’t just use Angular.

Lesson

While the candidate was able to talk about a problem he faced at a high level, he could not give more details about the issue or expose potential solutions.

Don’t assume behavioral questions can’t be technical. It is a conversation, after all. That can go in any direction, depending on what you, as a candidate, bring to the table. You should be able to talk about your stories in-depth and be very specifics.

Leave a Reply