3 ms·

I've thought about this a lot too, which is why we heavily recommend using Litebulb for take-homes. Sit-down onsites on Litebulb are only good if the candidate

I've thought about this a lot too, which is why we heavily recommend using Litebulb for take-homes. Sit-down onsites on Litebulb are only good if the candidate knows the existing frameworks, if they don't it's pretty tough to figure it out on the spot. Take homes are great because the candidate either knows the specific frameworks, or doesn't but can learn them quick enough. Either way, if you complete it within the allocated time and get relatively high enough scores, we'd recommend moving forward. Actually @xiphias2 what type of interviews have you seen that were really good? Like even the in-person ones, what made them good?

xiphias2 5y ago
I really liked LeetCode style interviews at big companies, and I loved that my colleagues also understood the importance of run time of complex algorithms. I also interviewed at startups where algorithmic knowledge is more of a disadvantage, as I may optimize things too early. As an example of why for some (especially big) companies need deep algorithmic knowledge is that at Google I was working on adding new features to an ads prediction model, and even without changing the code base the new (slightly more complex) model increased the ads 99%-ile latency by 0.1ms (millions of dollars loss because of the RPC timeouts), which required director level exception there if I wanted to ramp up the experiment to total user traffic (the usual thing that people do is to optimize something else in the code base to stay in the latency budget). The small problems that LeetCode provides for interviews are great filter for people in these companies when they are faced with much more complex optimization problems. The problem is when a small company with lots of user facing features uses the same type of interview (they shouldn't).
nicoburns 5y ago
Could you set the tests up so that candidates have a choice of framework? (and the hiring company can choose which ones). We use React at work, but I'd probably be quite happy to accept solutions in Vue and Svelte (and maybe Angular 2+). Similarly for backend work we use Node.js + Postgres, but I might be willing to accept solutions in Python, Ruby, Java, C# and MySql, Sql Server for example.

xiphias2 5y ago

I really liked LeetCode style interviews at big companies, and I loved that my colleagues also understood the importance of run time of complex algorithms. I also interviewed at startups where algorithmic knowledge is more of a disadvantage, as I may optimize things too early. As an example of why for some (especially big) companies need deep algorithmic knowledge is that at Google I was working on adding new features to an ads prediction model, and even without changing the code base the new (slightly more complex) model increased the ads 99%-ile latency by 0.1ms (millions of dollars loss because of the RPC timeouts), which required director level exception there if I wanted to ramp up the experiment to total user traffic (the usual thing that people do is to optimize something else in the code base to stay in the latency budget). The small problems that LeetCode provides for interviews are great filter for people in these companies when they are faced with much more complex optimization problems. The problem is when a small company with lots of user facing features uses the same type of interview (they shouldn't).

nicoburns 5y ago

Could you set the tests up so that candidates have a choice of framework? (and the hiring company can choose which ones). We use React at work, but I'd probably be quite happy to accept solutions in Vue and Svelte (and maybe Angular 2+). Similarly for backend work we use Node.js + Postgres, but I might be willing to accept solutions in Python, Ruby, Java, C# and MySql, Sql Server for example.