NickLarsen

It's definitely hard. There was certainly no clear cut solution to any of the problems I included on the card in the picture. We evaluated 8 or 10 different solutions for out of the box stuff, found things we liked and didn't like about all of them and eventually decided it was best to build our own. At each step there was a lot of debate because we knew this would probably be used beyond just the Careers project and be used in the Q&A project as well (separate at the time), so it wasn't just worrying about my team's concerns, but everyone's. We won some debates, we lost some debates, it was very hard.

The localization project I use as an example here was definitely one of my top 3 hardest projects of all time (and that was years ago). It was not a particularly difficult technical challenge, it was difficult because it touched every single aspect of the codebase. The project took me and a coworker 3 months to build out the infrastructure for, then another 3 months of actually rewriting everything to use it, and explaining to every single other developer about why we made the decisions we made in order to teach them the different ways they were going to have to write code from now on. Social challenges of the workplace are hard; we're not always looking for technical difficulty.

Thanks for posting this. One thing I didn't write about is the objectiveness of interviews (felt like a different topic). Just about any question can be okay as long as it follows a few simple rules. 1) if you ask a question, you should have an expectation of what you're looking for as a result in some quantifiable way and 2) how does that result affect your decision to hire or not. The worst interviewers usually don't have an answer for #1 there and they probably decided to hire you or not very soon after you opened your mouth for the first time. This article fails to state why each of these questions is valuable and what you should be looking for as a result of asking any of them. With the addition of that, it would be a much better article.

I'm familiar with the LLVM direct to wasm tool, but I was unable to get it working using the steps from the emscripten docs. The binaryen toolchain is pretty easy to digest, but I've been using the emsdk almost exclusively for the convenience. Once you have to rework part of it from source, I just don't know enough about it to debug it yet.

Thanks for the info on where to find outstanding proposals.

Sounds like a processor to me, let's just call them kernels.

Initially my thought was to compare it to the first compiler, back in the days when punch cards were the interface, but I decided against any history lessons that go that far back. In that analogy, the byte code is the machine, and now we all need to be writing compilers for it. This is why so many languages compile to javascript, it's the assembly of the web (not my trademark), in the browser world at least. If you want this code to run in that browser, you gotta pay the penalty of cross compilation inefficiency.

I actually think being browser agnostic is more important; it is sort of the reason we're even looking at wasm replacing asm.js in the first place. asm.js is still javascript, even though it gets handled differently under the covers. Having a second option of language supported by all major browsers is a huge deal, especially one with static typing.

As for the naming thing, a little bit of bikeshedding is healthy from time to time.

We (at Stack Overflow) have a new documentation product coming down the pipe with an emphasis on examples and I thought it would be awesome if we could expand our stack snippets feature to languages beyond javascript. A reproducible example right there on the webpage. In researching existing solutions, nothing was satisfying, and then I had the idea to just use asm.js and write an MSIL interpreter. I spoke with some people familiar with asm.js and decided that it wasn't particularly difficult, but it had a ton of limitations from js file sizes to ways to get all of the libraries people ask about uploaded, and of course regular breaking changes in the browser. Wasm seemed like it could help with some of the issues being a formal web specification with representatives from multiple browsers.

Other than that, I can see a lot of uses for it, from small neural nets in the browser to high performance applications like photo editing, and of course gaming. It might not be for all applications, but it certainly has a spot.

That's fair. Originally asm.js was named capsule.js but that was taken and didn't really mean what it was. We could also call it modules but there is another very related spec out there for that as well. What would you call it instead?

I had the exact same problem when I first started. Someone once told me "what we can throw away to solve this problem", so I kept removing parts until I got here which I think is currently the easiest way to get started.

The last 10 minutes where you ask questions is a bad time to waste asking someone to judge your 3 year plan when they just met you. Most of these questions are better asked when you fail an interview and request feedback as to why.

I specifically state when I perform interviews that I will not answer the question "How well would you say I did in this interview?" The interview isn't over yet, and that's impossible to answer.

You should really spend this time to see how much you would want to work at the company. Ask about their processes, the things that would absolutely turn you off to a company or the things that would absolutely turn you on to a company and make you forget about all their other bullshit. Ask about the problems they are trying to solve. Ask about how smart the other people are who you'll be working with.

Don't waste time in the interview checking if you passed. You'll know very soon anyway and there is always the chance to get this feedback afterward.