4 ms·
Hahaha that's smart way of filtering out bad candidates. Maybe during the interview process we should make sure the candidates fully understand the callback st
by emilsedgh 6y ago
Hahaha that's smart way of filtering out bad candidates.
Maybe during the interview process we should make sure the candidates fully understand the callback style and Javascript's async model.
We also have a big project. we started during callback days, skipped promises (I never thought promises alone were an improvement over callbacks and async.auto). But as soon as async/await was in, we allowed them in the codebase.
So now the codebase is a mess, with some functions being callback style and some others promises, stiched together we promisify functions. Im hoping in a 2-3 years time frame all our callback style functions will be eventually phased out during small refactors and rewrites.
This migration plan is the only method i found that enables projects to move from A -> B without spending massive times rewriting the whole project and yet keeping up to date with technologies so they wouldn't need a rewrite every 10 years.
- forty 6y ago> Maybe during the interview process we should make sure the candidates fully understand the callback style and Javascript's async model. I used to ask candidates to implement async.map and I used to be baffled that the majority of JS devs are unable to do it. There are those who would say "I'm not used to callbacks, I use promises". I would then allow them to use promises (no Promise.all allowed, that's what we are trying to implement ^^). I have never seen one of those "promise only candidate" manage to do the exercise. If you want to push it to the next level, ask them to implement async.mapLimit. You wouldn't believe how few people that are looking time professional JS devs, are actually able to do it properly (I actually used to ask that one, before realizing that it was too much to ask... )
- emilsedgh 6y agoThese are actually pretty awesome questions to ask in an interview. Thanks!