Here’s how we did interviews at the startup I used to work for.
Phase 1: 30min non-technical phone screen. Usually we would have three people on our side of the call, but only one of us would do most of the talking. The goals were simply to describe the company and role to the candidate, gauge the candidate’s interest and ability to communicate, and allow the candidate to ask basic questions. We would discuss and decide whether to advance the candidate immediately afterward and usually notify the candidate on the same day.
Phase 2: in-person code review, typically 1hr. We’d give the candidate the option of providing us with a (working) code sample from something the candidate had written previously, or of coding up a solution to a problem faced by our actual product. While I was there we had a good mix of candidates picking each option. The “homework” problems were always drawn from the product, so they were real, but we also kept them small, so that an average candidate could have a working solution in an hour or two. And we’d give the candidate a week with no other constraints. Candidates could use any language, could research solutions however they liked, and could email us any clarifying questions they had. Whichever option the candidate picked, the goal was just to get our eyes on a dozen sample the candidate had written and could be expected to understand. At the on-site, we’d have the candidate explain the problem in the candidate’s own words, then walk us through the solution. The goals were to determine how well the candidate understood the problem and how comfortable the candidate was with explaining technical decisions. It didn't matter to us if the code ran or even attempted an optimal solution; we advanced some candidates whose code samples did neither, but who were able to talk us through what they had tried to do and explain why it didn't work.
Phase 3: working interview. We hired candidates for a day, paying $1,200–$1,600 for the day, depending on the role. The candidate would pair with a member of the team and work on some aspect of the product. The task was selected to be representative of the work the role required, but also simple enough that could be completed in a single day. At the end of the interview, the candidate got to ship the code to production (for which purpose we had a big, important-looking, physical red button). The goals were to determine how well the candidate functions in a working environment, how readily the candidate asks for help or conducts research, how the candidate responds to frustration, and how interesting and engaging the candidate finds the work.
It was quite a time consuming process on our end, but it was extremely effective at finding excellent candidates. We never made a bad hire the whole time I was there.