Interview questions were typical for this role. They included amazing technical questions such as "Can you run a coroutine asynchronously in Unity?" It turns out that you can (I didn't know this before the interview, I discovered it with my own experimenting after the interview), but it requires some hacky tricks, and you lose the benefits of being in a coroutine in the first place. I was also asked vague behavioral questions like "If you and another engineer have fundamentally different opinions on how to complete a task, what do you do?" This question is vague in my opinion because each situation is different, and depending on what the task is and how central it is to the overall project, I can have completely different responses. I'm not a petty person (he says as he writes a scathing interview review on Glassdoor, lol), so if the task has a low impact on future tasks, I would simply learn from what the other engineer had submitted and move on with my life. However, if the task is central to the entire project, I would spend more time with the other engineer to get to understand their perspective. They probably see something that I don't, and there's a strong possibility that we can find a common solution together that has more benefits and less drawbacks. If I still find that my idea for an implementation is far better, I would bring in more people to discuss the situation and make sure that we're taking the right approach. Finally, if I have discussed my concerns and the rest of the team agrees to take the other engineer's solution, then I agree to move forward with that solution and support it. At the end of the day, we're still a team, and it serves no one for one engineer to insist on their implementation be used at the cost of the rest of the team.
