5 ms·

I appreciate that some people prefer this kind of interviewing, but instead of memorizing some algorithms, it all comes down to whether the dev knows the same s

I appreciate that some people prefer this kind of interviewing, but instead of memorizing some algorithms, it all comes down to whether the dev knows the same specific framework or not in this case. I'm not saying one is better than the other, just different, and I think both are valid ways of interviewing.

garyjlin 5y ago
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.
mrkurt 5y ago
We hire with projects derived from the specific frameworks we use. It's the best way to give them a taste of actual work. We also give people time to learn the framework we're using as part of the hiring process. And we encourage them to do that if they want! People with a tremendous amount of experience in our framework-of-choice have an advantage. But they're also more likely to be immediately valuable. It's imperfect, but it works well for us. And you'd be surprised how many people float right through the technical assessment learning as they go.
- xiphias2 5y ago
  ,, Tech interviews suck. Engineers grind LeetCode for months just so they can write the optimal quicksort solution in 15 minutes, but on the job you just import it from some library like you're supposed to.’’ I was responding to this negative part of the introduction. Actually all of the mentioned frameworks are disallowed at Google (where leet code style interviews were introduced), because they are not fit for serving billions of people in the latency budget in the search/ads stack. If you would rephrase it that for most companies leet code style interviews don’t make sense (and probably are your customers), I would agree, but the few where it makes sense are really important companies.
  - garyjlin 5y ago
    I think you make a good point here, you're right, because leet code style interviews don't work for most companies, but they do work for some companies with specific needs. I recently spoke to a prospective client where they mentioned they need a quick way to filter through hundreds of candidates pre-funnel and they only want to know if they can write basic code. If you can write basic code, you pass and your resume gets a look. They specifically didn't want anything too deep or difficult. I actually recommended that they use a tool like HackerRank or LeetCode instead of us because it made more sense for their use case.

garyjlin 5y ago

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.

mrkurt 5y ago

We hire with projects derived from the specific frameworks we use. It's the best way to give them a taste of actual work. We also give people time to learn the framework we're using as part of the hiring process. And we encourage them to do that if they want! People with a tremendous amount of experience in our framework-of-choice have an advantage. But they're also more likely to be immediately valuable. It's imperfect, but it works well for us. And you'd be surprised how many people float right through the technical assessment learning as they go.

xiphias2 5y ago
,, Tech interviews suck. Engineers grind LeetCode for months just so they can write the optimal quicksort solution in 15 minutes, but on the job you just import it from some library like you're supposed to.’’ I was responding to this negative part of the introduction. Actually all of the mentioned frameworks are disallowed at Google (where leet code style interviews were introduced), because they are not fit for serving billions of people in the latency budget in the search/ads stack. If you would rephrase it that for most companies leet code style interviews don’t make sense (and probably are your customers), I would agree, but the few where it makes sense are really important companies.
- garyjlin 5y ago
  I think you make a good point here, you're right, because leet code style interviews don't work for most companies, but they do work for some companies with specific needs. I recently spoke to a prospective client where they mentioned they need a quick way to filter through hundreds of candidates pre-funnel and they only want to know if they can write basic code. If you can write basic code, you pass and your resume gets a look. They specifically didn't want anything too deep or difficult. I actually recommended that they use a tool like HackerRank or LeetCode instead of us because it made more sense for their use case.