How would you answer this behavioral interview question?
Let’s say you put in a 700 line pull request, and your coworker says “this will work, but it’s not the most optimal solution so we should scrap this.” What would you do?
Tell him “Well sleeping with your mom wasn’t the most optimal solution but it still got the deed done”
First things first. I will start by asking his TC or GTFO
I guess it depends on how non-optimal it is. I'm not even sure what that means. Poorly written? Slow? Buggy? Doesn't work well? Causes errors?
I think it just infers there is a better solution.
Ask to define what is optimal in the case and to describe what I could change to fit the optimal.
1. Re-look over the pr. Did you overlook something simple, or does it reek of bad code smell now that you're looking at it like that? 2. Ask them what they think the optimal approach is. Maybe you considered it but it wasn't feasible and you know better. Maybe they will convince you. 3. Explain your approach if you disagree with theirs, compare pro and con. 4. Consider asking product owner to see what's better: a sub optimal solution right now that might be to be replaced, or something optimal that is delayed. 4 alternate. Ask others. If everyone agrees it's a bad solution that needs to be changed, you're probably wrong, and you'll only lose influence by fighting for it more. It's better to say I told you so months later than be ignored on everything in the future
If things still aren't solved with all of these, you are probably the problem, or they are the problem. And when that happens it's a lot more case by case than can be answered here
Alteratively if you get here, no one but you and the other guy give a shit, just get approval and say features in prod are better than optimal code never released
If it’s behavioral question it’s probably directed towards your collaboration skills and a sense of urgency. So I would say: 1) What’s the deadline? 2) Not optimal how? And then you need to settle it in the best possible way for the company, but staying collaborative and respectful to your coworker.
This is exactly why you never submit huge ass PRs and instead break it down into smaller commits.
700 line pr is the problem. Break it up. First pr is a skeleton that clearly lays out the design.
Ask what they are optimising for, execution speed, implementation speed, etc.
ask him what he thinks an optimal solution is