How can I answer what was challenging about my last role without ruining my chances? [duplicate]

Question

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.

I learned a lot of ReactJS, JavaScript, code styling standards, code quality standards but that's about it and I was bored to tears after 6 months. It wasn't a good fit. I was not allowed to make hardly any independent decisions, or if I did I would most likely have to redo it at a later time, or face criticism about how I did it. But if I tried to talk about it at the time it came up some people would get annoyed that I could not make a choice or I would have to wait for new specs and switch gears. It was really draining. I never felt that my suggestions were taken seriously.

What I found challenging:

1. I didn't have any domain knowledge. This made is difficult to offer suggestions or improvements to the UI.
2. I didn't know any of the technologies needed. I didn't know JavaScript, ReactJS, SASS, Gulp, Webpack or any of the modern JS ecosystem. I was thrown into the deep end and had to learn. I learned quickly and went onto program many widgets.
3. 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.
4. 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:

• validation
• 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?

Answer 1

You can interpret "challenging" in two ways: one is to list things you found difficult and hope you won't have in the new job, and the other is to list things you got better at over the course of the job. I don't recommend mixing and matching these two possible definitions. Instead, pick one, tell the interviewer the definition of challenging you're using, and then list a few, one sentence each.

If you go the first way:

Several things in my current job are frustrating, and that's one of the reasons I'm looking for a new one. One pattern that occurred a lot was being asked to start before all the decisions were made, and having to redo work later when the specs were fully understood. Another was finding performance problems but not being able to participate in implementing the corrections. I hope in this position that teams share information and [whatever else you wish is different with this job.]

If you go the second way:

When I started I didn't know much ReactJS, JavaScript, code styling standards, or code quality standards, so I learned a tremendous amount over the time I was in that position. I feel now that I [strong statement about knowing a lot or being solid in the tech the new job is asking for.]

Notice how in each case:

• you don't say "a challenge was" since that's ambiguous: you clarify what you're about to describe
• you keep the complaining, or the list of what you didn't know or couldn't do, nice and short
• you close with a strong transition that either says "I want this job to have X" or "I am really good at Y." Pretty much every question you are asked in an interview should get across one of these two statements, every time.

Answer 2

The emphasis in answering this should be in how you overcame that challenge. Pick whatever challenge lets you do that.

I'd stick with either #1 or #2. Assuming, of course, that you actually acquired the domain knowledge and learned JavaScript and the other technologies, you'll probably want to talk about how you did that; if you go with #2, stick with "I was thrown in the deep end - and I was able to swim."

Do not say something like "I didn't have any domain knowledge, so I couldn't make UI suggestions" - only bring this up if you did, in fact, overcome that challenge (i.e. you learned the domain knowledge).

I'd strongly recommend avoiding #3 and #4 because it makes it sound like you're bad-mouthing your old employer, which is usually considered unprofessional and tends to be a big turn-off (because they'll then wonder what you'll say about them when you eventually leave, plus you can come across as a whiner).