Ukrainian guys. I talked to Max on zoom for an hour. Seems like a nice guy and apparently he was serious about writing a new kind of forum software.
They said remote is possible.
I’d do it if I was ready to quit my job.
Why not just do both?
Sound easy enough that someone good could do it in their sleep.
Not and try to finish my book at the same time.
I forgot about that. If no book, you think you could pull it off without too much difficulty?
what sort of backend programming do they need? (i’m not an FE guy obv)
Apparently .NET.
donotwantdoge.gif
Definitely learned some new stuff there.
Crushed it somehow 
3 Likes
lol this career. I got 2 “hard” questions, flatten an array of arrays and isPalindrome. First is the easiest recursion answer ever, 2nd is either 2 pointers/sliding window or just skip comparison of the middle one using floor(array.length / 2) which is what I did, guy was so impressed he saved the code 
. Both of which are for sure leetcode easy. And this is for like a B tier tech company. IDK.
I’d assume I’ll get an offer and take it because yeah first staff role. Or just go do this same interview at other B tier places.
Never in doubt
Seems like you need to move up to where you respect their coding questions.
But seriously though, would it be wrong to consider this an indication that you need to be setting your sights even higher.
I’m very confused and am not sure what’s going on there. But if you want to make async calls in parallel, use Promise.all([foo(), bar()]). async/await doesn’t work for parallel calls.
Also FYI nothing is “starting” until you use await. You can have a function that returns a promise. But it’s not actually executed (like say making an HTTP call) until you call await. So you’re not really starting anything at the top of the function. The actual work will always kick off and finish within the await statement, then move on to the next line.
I believe the part of an async function up to the first await is equivalent to the body of a promise, which means it runs synchronously. So you would need to handle any errors that could arise when you call it.
Yeah I was confused. I didn’t know what asyncFoo() and asyncBar() looked like. So I was thinking maybe they return another async function to be executed later. But I guess then your second statement would have to be await foo() not await foo.
If you don’t return a promise, like you’re doing here, JS implicitly wraps the returned value in a promise. So you’re instantly getting a promise back for the async function, and then trying to await it later in the code. I’ve never seen that done, and I don’t know how it will behave.
But what you want is Promise.all([one(), two()]). Or maybe Promise.allSettled().
This might be what’s happening to you:
More on the subject:
Unhandled rejections are a Bad Thing™ (so much so that soon, Node.js will abort the process on truly unhandled rejections, just like unhandled exceptions — because that’s what they are), so best to avoid the “get the promise then
awaitit” pattern in your question.
This is a bad practice. Never use multiple await for two or more async parallel tasks because you will not be able to seriously handle errors. It works only for positive scenario but in negative scenario (async tasks rejection) you will always end with unhandled errors although you use try/catch. You must always use Promise.all for async parallel tasks. See my answer here : stackoverflow.com/a/54291660/3826175 If you need to handle errors globally and separately use this:
try { let [val1, val2] = await Promise.all([ task1().catch(e => ...), task2().catch(e => ...) ]); } catch(e) { }
1 Like
Promise.all isn’t quite right because it will wait for bar even if you don’t need it. You can roll your own combinator like this:
function firstSuccess(fn1, fn2) {
const wrapSuccess = result => { return {success: true, result} };
const wrapRejection = result => { return {success: false, result} };
const wrappedFn2 = fn2().then(wrapSuccess).catch(wrapRejection);
return new Promise((resolve, reject) => {
fn1()
.then(wrapSuccess)
.catch(() => wrappedFn2)
.then(({success, result}) => {
success ? resolve(result) : reject(result)
})
})
}
The basic idea is that you wrap the second function to hold the error until you need it. Then you just call the first function, replace it with the promise from the second function if it fails, and have a final then block to decide whether the promise as a whole succeeded or not. The key point is that the returned promise will resolve immediately if foo succeeds, and will only wait for bar if it needs to.
EDIT: My JS hot take is that async/await is actually kind of insidious, because it doesn’t really abstract the complexity of asynchronous programming away, it just hides it so it’s not obvious what’s going on. When it works like expected, that’s great because it makes the code easy to read, but when stuff goes wrong, it’s hard to understand why. Promises are a lot more principled about only hiding the implementation details that are actually abstracted away, so it’s a good idea to drop down to writing (or at least thinking) in terms of promises if async code isn’t working as expected.
yeah I never use async await I mean lets make something really complicated even more complicated. Just use promises (and promise.all) or gasp callbacks.
I like async/await because 95% of the time I want sequential, and I usually don’t care about catching the rejection in node lambdas. I just let it barf.