I've found this technical interview process to work very well. This is done after the initial phone screen.
1. Show them a problem with your product along with the code. For front end developers it could be how form invalidation errors are being presented to users.
2. Ask them to figure out what why the code is doing this and observe them troubleshoot the code.
3. Tell them to fix the problem in the code and observe them apply a fix, test, and debug it.
4. Ask them to architect a better solution to the problem and to explain what makes it better. What would would be drawbacks to their solution.
The benefits of this approach is that you can evaluate directly how someone solves problems, not how well they communicate, nor how knowledgeable they are. It also helps me judge how fast they are. Sometimes I ask people to estimate how long it would take to solve this and time them. The last step helps establish how they think through their solutions and how well they can communicate their ideas.
Additionally, I get to see how quickly they might get up to speed with our codebase and I can hear other solutions to some of the technical problems we are facing which is incredibly beneficial as a small startup.
The idea of revenue churn is startup biz hype. This is how startups play with numbers to make their business seem better than its really doing. You can't make solid business decisions based on a framework of revenue churn since it hides real business issues.
The real issue with churn rate is that you have users leaving the service. If you want to better your business you want to reduce this number and get it as close to 0 as possible. Revenue churn would hide this and make it think you're doing well, when in fact you're not. You could be facing a dwindling user base with just a small number of high paying users.
1. Show them a problem with your product along with the code. For front end developers it could be how form invalidation errors are being presented to users. 2. Ask them to figure out what why the code is doing this and observe them troubleshoot the code. 3. Tell them to fix the problem in the code and observe them apply a fix, test, and debug it. 4. Ask them to architect a better solution to the problem and to explain what makes it better. What would would be drawbacks to their solution.
The benefits of this approach is that you can evaluate directly how someone solves problems, not how well they communicate, nor how knowledgeable they are. It also helps me judge how fast they are. Sometimes I ask people to estimate how long it would take to solve this and time them. The last step helps establish how they think through their solutions and how well they can communicate their ideas.
Additionally, I get to see how quickly they might get up to speed with our codebase and I can hear other solutions to some of the technical problems we are facing which is incredibly beneficial as a small startup.