Typically "20% savings" would mean that you save 20% of the initial value. 20% x $600 = $120, not $100. I.e., you should multiply by (1-0.2), not divide by (1+0.2).
Edit: That has the undesirable property that common English sentences don't cancel out like you'd expect -- if you lower the price by 20% then raise it by 20% you don't end up where you started. Unfortunately, that problem doesn't go away whether "increasing/decreasing by x%" always refers to the former or the latter price; you'd require that it target's the former price in one direction and the latter price in the other, which IMO is even less intuitive than the status quo.
Nice tool at a fraction of the price of others in this space, but to be honest I'm not sure how it is a "better tool" - it's a code pad for coding interviews, but there are no rich features or any ways it distinguishes itself from others.
There are many gaps in the way code interviews are done, and especially with remote now I think there's a lot of ways you could have a tool which really differentiates itself in features and functionality. Good start though!
Thanks for the encouraging words! Agreed that there are many areas to explore.
One aspect we're exploring is how to establish clear rubrics, and even share it with candidates ahead of time.
Any areas that you think would be interesting to look into?
This doesn't solve any of the problems I hear a lot about with technical interviews so I don't see how it's better. Everyone (interviewers and interviewees) complains about writing code and using a white board; this just enables those hated un-proven interview techniques.
great idea although option C is really all you need. i graduated years ago in CS and had several projects already that i could show, upon graduation. if you have none you can show or talk about, your CS program is broken.