“Are pull requests the best way to do intra-company code reviews? Maybe for small features it could work, but let’s say that you are working on a 2-week sprint feature or a huge refactor”

Feature branches of such a long duration are bad news. As Martin Fowler points out, “To do Continuous Integration, everyone must commit daily to mainline”. https://twitter.com/martinfowler/status/599262448126943232

There’s almost always a way to turn what you think will be a large PR into a series of smaller PRs.

For a complex feature, you can begin with a minimal implementation, get it reviewed and merged into mainline, then incrementally enhance it in subsequent PRs. Stories can be sliced in various ways – Mike Cohn covers this well in his books.

To avoid exposing incomplete behaviour to end users you can use a Feature Toggle (http://martinfowler.com/bliki/FeatureToggle.html).

For large refactorings, sometimes it helps to allow some duplication until everything is moved over the the ‘new’ way. This means that code may become worse before it becomes better, but this is usually preferrable to having long-lived branches.

I do however agree that asking for early feedback on an incomplete PR can be useful, regardless of size.