I'd love to be able to dedicate more time to making RxJS better for everyone, keeping up on PRs, updating docs, establishing better relationships with contributors, working with standards bodies and browser vendors to ensure RxJS stays in-line with upcoming changes to the web. It would be practically a full time job for more than one person. It's just hard because I don't have the time, my day job is important too, and kids gotta eat ;) haha.

Oh I definitely did all the same things anyone else had to do.

Basically you do a phone screen. Then you come in for a day and you sit through 5-6 45 minute interviews, each of which involves whiteboarding through a problem. You're asked questions, most of which are probably way harder than they need to be, and you're expected to write and talk your way through it. Talking through your thought process, asking questions, and considering edge-cases is key.

If you want to study for one, I recommend going to http://www.geeksforgeeks.org/ and trying to solve some of the problems there, then looking at the REAL answer, and trying again. Just keep practicing like that until you have most of the patterns memorized. It's sort of fun anyhow.

Just remember, the person interviewing you DID NOT come up with whatever binary search or sorting algorithm you're answering with. They had to memorize it just like you. They're only as smart as you are.

SSR is something you think about to address perf issues with time-to-first-interactive. I think SSR is here to stay, but it's definitely not something that is required in all apps. Or even most apps, really.

As for compilation, any templated framework (Angular, Glimmer, etc) is going to, and should have, a build-time step to compile templates into simple functions that update DOM or write HTML. That's definitely a trend I don't see stopping anytime soon.

I was thinking more like "I want to eat a burrito, while on horseback, on the beach in St. Barts".

I think React has been a huge driver for most recent innovations.

Another thing you're going to start seeing more of is async functions and async function* (Async generators). Those are pretty powerful and intuitive.

Finally, WASM. WASM isn't quite ready yet. But it's a dark horse. Once it's ready and there's an attractive language to use on top of it, it's going to cause some serious shake-ups in web development.

OJ Kwon (fellow RxJS admin) has a library called rx-sandbox that's pretty beta, but probably worth a look. https://github.com/kwonoj/rx-sandbox

Sure... if you could go anywhere and eat anything in the world for lunch, what would it be? How would you eat it? Where would you eat it?

Sorry, it's creeping in on lunch time so my mind is on food.

Totally. A redux store in RxJS is basically just the scan operator.

However, the downside is you're going to be rolling your own architecture and forgoing any of the nice devtools that people have developed for redux.

I can help you apply. But I don't feel comfortable recommending people I don't work with or know. :)

Remote work is fun but it has it's challenges. I've spent about 2 years of my career as a remote worker in the past. The upsides are obvious: No commute, can wear pajamas, you're at home, etc.

The downsides are less obvious: You feel (and perhaps are) more expendable when you don't have face-time with your team. You're never "not at the office", so you feel more beholden to requests from managers at 8pm on a Saturday. You also get lonely sometimes as you don't really see other adults for a good chunk of the work day.

All in all, I'd do it again for sure. It's just not all a bed of roses like people think it is.

It's really me.

An assistant! 🤣 LMAO.

I drove my dented Hyundai to work, where I sit at a tiny little desk under fluorescent lights. I assure you, I'm not fancy enough for an assistant.

I'll ask for one though... just to see what happens. hahaha.

There is no "best". They're just tools to accomplish tasks. If I write a web server in Assembly or I write it in Basic, the end user doesn't care at all. They only care that the server works. If you're looking for what to use, then I'd say just choose the most common thing, there will be more jobs and better documentation.

Always bet on JavaScript.

... Until WASM matures to do more and is targeted by something amazing or widely known like C#, then bet on that.

I don't really have any solid opinions on it. I've only played with it a little, and it's been several years.

RxJS 5 and up has always had a goal of being a reference implementation for the proposal. Obviously RxJS has to change a little slower than the proposal might, but the goal is to be in-line with proposal so we can leverage native Observables when/if it lands.

The pipeline operator, if it landed, would work OOTB with the lettable/pipeable operators we have in RxJS:

import { map, filter } from 'rxjs/operators';

source$
  |> filter(x => x > 3)
  |> map(x => x + x)

I think the pipeline operator would be fantastic for libraries like RxJS and Lodash.

Thank you for your kind words, BTW! I means a lot!

Depends on your goals. Frontend? JavaScript. Backend? Probably Java. (Rust, Go, et al are really cool, but these are where the jobs are right now still)

Well, first of all, have more confidence. Or at least have the confidence to try. Most maintainers will help you get a PR through if it's something they find valuable.

Also, be very, very patient with maintainers. Most likely they're overworked, and this is their part-time job. It might take them a long time to get to your PR, and you might have to ping them several times to get them to notice. Don't pester them too much.

Well, those things are all very loosely related. Side effect management, vs push-based primitives vs Async Graph library.

So if I had to predict the future, I'd say they all win? haha. :)

Well I meant the front-end.

In the company I work for, we see redux-saga as a poor man's RxJS, and GraphQL, I've heard can sometimes replace both ... i.e., you can make data requests declarative, eliminating the need for aync management.

But in the same vein, there's still room for all three in the front-end... which leads to developer overload from having to learn three different technologies.

How to "think reactively", basically thinking in terms of sets of events and how to query/join/create them from one another.

Oh gosh, this wouldn't be fair. I've met so many amazing people in this industry and there are so many developers I admire. I mean the ones whose opinions matter the most to me are generally friends of mine like Jay Phelps, Igor Minar or Stefan Penner.

Sam Saccone, MIsko Hevery, old friends from back in the day like Tom Jelen and Chris Klein...

Oh God... see? I feel guilty for all of the amazing people I know that I've missed. 😰

TypeScript is great for adding some type-safety to JavaScript apps. I don't think it can/will ever replace JavaScript, there are some things you can do in JavaScript you just can't do in TypeScript. For example higher-kinded types aren't a thing in TypeScript, so you can't have "generic generics" that can support some of the interesting things you can do with a dynamic language like JavaScript.

TypeScript shines more in providing safety and refactorability for large apps and teams.

Well, it's hard to get into Google in general. The interview process is notoriously difficult. I don't have any ML experience, so I can't speak to that, but generally Google hires Software Engineers (SWEs) without knowing what position they will be placed in. Placement comes after they join Google. There are a few exceptions to that, but that's the general process.

Put yourself out there, blog, do OSS, start a podcast. Look at Kent C Dodds, a lot of people don't realize he only has about 5 years (?) of experience under his belt. He's really good at self-promotion, and that to me is a fantastic growth hack. He's met and learned from some great people because of how proactively he promoted himself and his brand. He's also a really nice guy so I'm sure that helps.

Snorlax. Hands down. Snorlax knows what's up. 😴