How to describe promises (for interviews)

I was just talking to a friend and i described a promise as: Asynchronous code that allows you to wait for the completion of some query (like a database) before executing other tasks.

My friend wanted to emphasize that i should not say ‘wait’ in my description in a job interview.

Why is it incorrect to use the verb ‘wait’ in my description of a promise? In my understanding, its code that is waiting to be fulfilled, no?

I think i understand why saying ‘wait’ would be assumed wrong in the context of single threaded events…and this is the annoying part of coding for me, is having to use the proper ‘vernacular’… But i suppose if i say ‘wait’ i could be implying that the code stops all together? But i never say the phrase ’ the code stops all together ’ so is that more the assumption of the interviewer and something i shouldn’t be worried about?

p.s. are there other topics you’ve had a similar experience with? Your description sabotages your ability to sound like you know what you’re talking about? someone once asked me to tell them the advantage of using === instead of == and i ignorantly replied ‘its just more consistent’, but he really wanted me to explicitly mention type coercion. now that i know that, i always say type coercion …but im unsure how to prepare for interviews in this context, as it seems i only learn these lessons of how to ‘talk about programming intelligently’ when i’m literally having the experience of someone else not being pleased with my description.

I’m a huge fan of MDN Web Docs, and their description of a promise does it for me. Then again, I’m not a super-deep thinker :frowning:

A Promise is a proxy for a value not necessarily known when the promise is created. It allows you to associate handlers with an asynchronous action’s eventual success value or failure reason. This lets asynchronous methods return values like synchronous methods: instead of immediately returning the final value, the asynchronous method returns a promise to supply the value at some point in the future.

Heh, yup, this is a pain in programming. Most stuff takes time to learn, and in that interim period you often don’t know that you don’t know things. It’s a bit disheartening when someone just flat out tells you what you thought was correct isn’t :confused:. All I can really say is don’t assume stuff: there is the luxury in programming that there is a technical reason and a right answer for most things.

re Promises: Nothing really “waits” in JS, everything always happens straightaway in the order it’s described in the code — JS has only a single thread, so it cannot ever really wait to do things in the sense you’re thinking of. As you say, waiting implies you stop everything. In a language with threads, you can actually wait, because you can send the async work to another thread, which will get blocked until the work completes, but it won’t block the whole system, just that thread. In JS you can’t do that so the options are you block everything (which, yes, is waiting) but that’s not very useful most of the time. The quote @willjw3 pulled out of MDN covers it - when you eventually get a value back then do {thing}, in the meantime you have an object returned strightaway (a Promise) that represents something that could be unwrapped to be a value at some point. You can do exactly the same thing as promises with just callbacks, but the code can get a bit hard to follow: instead of the syntactic sugar that Promises provide of doAsyncThing.then(doSomething).then(doSomethingElse) it’s more like doAsyncThing(thenDoSomething(thenDoSomethingElse))

Waiting for an operation to complete is how synchronous code already works: it blocks before you can do anything else. Asynchronous code lets you do work in the background, then execute an action on completion. JS’s async/await means you can wait for trigger code on completion at some later point in your code, whereas a promise (usually) bundles the continuation as a callback at the site right after the promise is defined, specifically in the .then method. (edit: forgot to mention, await is implemented with Promise under the covers and thus never blocks either. Once you start making Promises, you can never go back on them :grin:)

If you really want to spin their heads around, demonstrate how promises are monads (if you ignore the .fail method, anyway) :wink:

Try this on interview:
“Promise in JS is pretty much the same as promise in real life, if you resolve your Promise to hire me, I’ll resolve my Promise to work hard and you shall be ready to resolve your next Promise to pay me well, I’ll await for that!”

1 Like