I think people miss the wait part of await and hence forget they can separate the creation and consumption of a promise. Should have been called waitFor!
Growth Mindset might be a bit of a wooly term but that tends to be what I look for. I want people who continually get better. There are lots of resources on specific things you can discuss for this. For me, I think simply asking "what was a recent new thing you had to learn" opens up a good conversation.
For ascertaining whether someone meets a technical bar -- the gold standard has to be facilitating some way where they can do some actual work with you. That might be v difficult depending on nature of stack, tech debt, etc. But the closer you can make that sort of process to what would really be happening, the better. Coding exercises really only prove someone is good at coding exercises -- that may or may not have any relevancy to what you do I think.
Thanks for sharing - and that article is really interesting.
Being "good at hiring" -- and hence having better people -- is such an advantage for an organisation, it always surprises me that too often we fall back on seemingly default hiring processes, and we don't look at the sorts of optimisations we could do to help surface the best candidates for a role.
Thank you. Sleeping on it, and writing this post, has definitely bought things back into perspective: we can all have off days.
It had been a while since I'd had this sort of negative experience, and what I would say is it's re-reminded me to make sure my hiring in the future caters for this sort of thing. Particularly for less experienced devs.
This was really interesting — can anyone offer a recommendation for a book on the history of these types of schemes? I imagine there’s all sorts of entertaining stories.
await-ing that promise is often what you want to do but there are other ways to do work once the promise has resolved.