This question already has an answer here:
I'm trying to find a decent answer to this interview question: 'what was most challenging about my last role?'
I was basically a UI widget monkey for over a year at the company with very little learned other than ReactJS. I was on a team of 4 devs. We were hired to fix a totally broken, mess, of a bad outsourcing project.
What I found challenging:
- I didn't have any domain knowledge. This made is difficult to offer suggestions or improvements to the UI.
- I often found myself in this situation: I would start working on a feature, only to find 2/3 of the way through that the edge cases were not spec'd out and I had to stop, talk to the project manager, wait for their new specs, and then start a new feature. Constantly switching gears was exhausting since I would have to gain an understanding of what I was doing before diving into the next task. It was hard to be efficient and write the highest quality code in these situations. It was hard to invest so much time into a feature and then have to drop it and switch gears that very day.
- I often found myself in this situation: I would find a design pattern issue/performance issue and discuss it with the senior devs. We would chat about it but then at a later time I found out that they went ahead and implemented it so I never got the chance to participate in anything like that at a meaningful level.
Some challenging things that I worked on but didn't get the chance to do alone:
- performance issues
Things I did alone but didn't think were the most challenging parts of the application:
- user preferences (complicated specs with many permutations)
- permissions (complicated specs with many permutations)
- order form (complicated specs with many permutations)
Performance vs Design Pattern vs Maintainability Since we had many nested ReactJS widgets, sometimes the parent components only passed down data to the child components. If you use this method along with shouldComponentUpdate, the code can become un-maintainable even though it's probably the best performance way to deal with the issue. The solution was to use context or make other UI views as 'data providers'. I didn't come up with the final solution but I identified the problem and discussed with the senior devs.
The senior devs told me that the permissions were the most complicated part of the phase 1 of the project but I didn't find it to be challenging. It was just mostly a bit of thinking about some complicated specs and then grunt work.
What's an answer I can give?