Questions for them
- Can you describe the team I’ll be working with and their roles?
- What is the feedback process like here?
- How does the company support internal mobility and career growth?
- How does the company promote work-life balance?
Common Questions
On Taking Feedback
My manager asked me instead of just linking to the issue, to write out a short description to of the changes. Nowadays, I really try to curate my PR to provide a good reading experience. I’ve even taken to amending commit messages in my branch, if I think something is distracting.
On Conflict Resolution
One scenario where conflicts are common is in PRs. When I’m in someone else’s area of ownership, I’ll try to make my case for my approach with logic. If that doesn’t work, I’m happy to concede and side with the reviewer. If I think its a worth while change, we can discuss this again over voice in private rather than a public comment section.
On Failure
At my last org, there was a time a teammate and I were both working on a similar area of the codebase, they deployed first but instead of double checking for conflicts, I trusted Github too much (out of laziness) and let it auto-merge. 30minutes later when the CI pipeline finished, I realized I had to revert. I went ahead and alerted other devs who merged after me, that their CI will fail and not to worry since it was my change and likely not theirs.
On Production Incident
On making a technical Decision
Last year I worked for a very early stage startup. Their prototype was build with Firebase. I initially decided to keep Firebase and get their prototype done. Once the prototype got finished, we ran into some issues due to Firebase not supporting complex queries. I decided that’d be best to pivot to a SQL database that had better support for queries and this ended up speeding up our load times by 6x. Now, the rollout of this could have been done better. Instead of making our app unusable until the migration was over we could have reached for an adapter pattern and support both data-sources. This way, our non-devs could see work being done and other features could be rolled out. Luckily, our team was small enough where this didn’t matter as much, but on a larger team this could have been an issue.
My Core Principles
- Simplicity (manifesto)
- Simplicity allows us to “Fail Fast, Move On” aka fast iteration (among other things)