[8_hours_ago]

I like that you do code reviews of every commit, do you have any issues with getting people to spend time reviewing? Also, it looks like you have a very broad code base (backend, frontend, mobile, machine learning...), do all of your engineers review code for all of those areas? I've found that in small teams sometimes only one person really understands a particular section of code, which can result in poor quality code reviews. I'm interested to hear if you've experienced that, or if you've managed to work around it.

FYI, the title of https://www.opendoor.com is: "Opendoorflexible-dateno-repairopen-houseonline-processfair-inspectionfast-closinghome-readycustomer-supportfair-offertransparency | Sell your home the minute you're ready.", which looks like a mistake to me. Probably need to add another test ;)

[kandalf]

I think everyone on the team understands that helping unblock other engineers is as valuable as writing some code yourself. It generally hasn't been an issue getting timely review, though we have discussed tracking the average size of the PR queue as a metric if review times did worsen.

Most of the time other engineers on your team will review your code, but often engineers will pop across teams and doing code reviews if they have the time and the context. One change we've made is moving towards tagging a few engineers who might have the right context when you submit the PR.

Thanks for the tip about the title; will take a look!

[toomuchtodo]

We've found mention bot to be helpful internally for intelligently selecting who should be performing reviews: https://github.com/facebook/mention-bot

Give it a try!

[kandalf]

Hadn't seen this before, but looks pretty cool. Thanks!