This is some serious dedication for what at first blush may sound to many to be a completely unserious, or even useless, achievement. But I say to those people: a DOOM proof is just as worthy of praise as any other academic mathematical proof, and has the advantage of being verifiable by laymen.

Congrats on this amazing achievement.

IE US English speakers always fond of telling me how they work X hours in a day, or they went N days without sleep. Which used to really impress me, until I realised "wait... do they just exaggerate as matter of course"? And then I realised - of course they do; these are people for whom every purchase is an "upgrade"; where a bicycle for commuting in a city is an "urban assault vehicle", rich creamery butter, rich creamery type systems, etc etc.

So no, I sincerely doubt they actually worked 18 hour days for a year straight. I'm sure they worked hard, but it's just the way Americans talk.

Different cultures express things differently. Overstating, understating, etc etc. If you want to understand, and be understood, it's important to know.

I don't know, when I got hyperfocused on a side-project a few years ago, I was dedicating almost all my awake time to it. 12+ hours a day, every day, including weekends, for months.

Surprisingly, I didn't burn out. I was just so interested in it, I couldn't stop, and even started neglecting other things to work more on it.

I never hit such a focus state since that time in 2017~2018.

We were already working on something for them, and on a whim, one of their VPs asked my company if we could take a look at it.

So that's how the mathematician at the company (me) ended up waking up, sitting in front of a whiteboard, and losing all concept of time until my wife got home from work at night, not eating, not sleeping, staring at decompiled assembly and stepping through line by line for weeks. (I don't want to say months because I'm sure someone will come roast my ass for taking too long, but "months" is honestly more accurate; in fairness, I was learning every technique used on the fly)

It was a prolonged, repeated flow state that I've only ever experienced during really competitive tennis as a high schooler. Losing all concept of time and space, hyper focused on one task that has completely spread to all parts of your consciousness.

1. I've also been it a hyper-focused state where I was so intent on what I was working on I would spend basically all my time on that project without burning out. Like you, I haven't hit that focus state for a long time.

2. "18+ hour days", consecutively, is almost certainly an exaggeration, and this is where I agree with the parent commenter. For some reasons Americans (I am American) love talking about how much time they work and how little sleep they get. Realistically, very few people (except a small percentage of genetic outliers) can get by on sub-6 hours of sleep for long.

Also, he forgot to credit the video itself, which has a really high production value! Kudos all around!

I personally went for 3 days without any sleep in the army as part of a sleep deprivation exercise and it was one of the most brutal things I've ever done, I fell asleep standing up whilst digging a trench, ouch.

So I know when people say "I literally haven't slept in 6 days", they very much don't mean literally, they normally mean they went to bed and had a few hours of sleep per night.

This guy is a legend now. Every developer slack channel at my company is buzzing about it

I definitely relate to this comment.

and he also says "It was a brutal year long journey of 18 hour days"

I think people are looking for those unicorn 10x devs that are like Good Will Hunting for code, but forget that there are those devs that might not get things right away but never stop until they figure things out. You'll probably find a lot more of those than the unicorns

I would spend weeks looking for the magic that would allow me to do it in hours when others would just spend the days or weeks required to actually do it.

I’m much better at making things now, and have people asking me how I manage to do that.

Props to the dev of this project though - in some ways this kind of project is one of those 'magnum opus' things - not many people might know or care about it, but it's actually something to be proud of achieving.

I fixed a long standing bug that was a companies top priority for several months and no one had been able to fix it. They were talking about re-writing an entire app to resolve it, at a cost of 100's of thousands of dollar, dragging the vendor over the coals etc.

I was relatively new and thought I'd take a look, ignoring all the mystique surrounding the problem. It turned out to be a simple one line fix, just a dumb oversight that anyone who bothered to understand and step through the code would have caught.

Things got a little weird after that haha. The director who had been responsible for that department started ignoring me, while I started to get pulled into look at all sorts of other peoples urgent issues, with zero context, often with a team of other people I didn't know on the call.

It was fun while it lasted, but man, I'm glad I'm no Doogie Howser MD, that shit would go to your head!

In most cases these issues are a result of similar kind of patching of a previous similar issue resulting in unexpected outcomes. (Probably going on for years)

From my experience management often tries to ignore the bigger refactors by using inexperienced people to patch things repeatedly, meanwhile the team suffocates under technical debt and responsibilities as a result of this mentality.

Sometimes its better to stick with the dev team for long term goals instead of becoming a "management puppet" for short term wins.

What I don't understand is how this thing does keyboard input.

At 3:42, the video simply says, "And, yes, there's a way to do keyboard input," without elaborating on how. What sorcery is that? There must be something outside the type system translating keyboard input into TypeScript types…??

However, I'm guessing this is why we see a demo of pong and not doom. Doom probably just can't keep up with this.

No idea if I'm remotely on the right track here though.

Beware with such blanket statements, you might inspire someone to do 18-hour days for a year to prove you wrong.

From what I've seen most languages don't want to have a Turing complete type system, but end up with one anyway. It doesn't take much, so it's easy to end up with it accidentally and/or by adding conveniences that don't seem programmable, e.g. associated types and type equality.

Very impressive!

I'm actually really excited to share that part of the story because I hope it can be a small thing in the back of people's mind to help them if it happens to them. It can happen to anyone. Interviews are SUCH a lossy process and most engineers I know don't have any training on how to do interviews at all - yet we just assume they know how to evaluate people's skillsets.

About those rejections, did they effect your confidence in yourself and your skills? How did they make you feel?

I used to work on Insomnia at Kong, which is literally a frontend for cURL. But some of the questions I couldn't answer were like "how do you get headers with cURL". I DON'T FRIGGIN KNOW. THAT'S WHY I WORKED ON A GUI FOR CURL. I CAN'T STAND USING THE CLI. lol. But to them, it was a question they were supposed to ask, and I got it wrong. Same story for questions about the git CLI DX (I'm a GitKraken fanatic lol), and more like that.

I would rate my confidence overall as being quite low. Well. I donno how to explain what I'm trying to say. It's not that it's low or high, it's that I don't factor it in a lot in what I decide to do. Where I've noticed some people dip their toe in, I find it easy to just cannon-ball into the frozen lake without needing a lot of justification. That's what I meant in the video about "close-enough-manship". I'm a sort of personality that spends a lot of time just failing miserably over and over again in the least efficient way possible until I get what I'm looking for - and I usually quickly move on before I learn what I could have done better, lol. I've been told that my comfort in the face of non-stop-failures is what confidence is, but I donno if that sounds right.

Getting a job these days is really tough on the psyche.

there's another reason, which is that I really get a lot of energy from working with other people. it makes me really happy. and right now especially I really love the people I work with. I learned this lesson the hard way in my stint contracting - because the inter-personal relationships are very different when you're there one day and gone the next (as a contractor).

The purpose of a system is what it does, after all.

Edit : TS not front end

Turing Completeness is one level, but being able to run Doom is the real test of whether a programming environment is complete and robust. Absolutely stunning to see TypeScript's type system get there.

Quick, someone tell this author it's not possible.

And if I'm just totally wrong on this, then you have your answer on why I never gave up on this project. I never once, ever, at any point, lost hope that it wouldn't work (HOW COULD IT?!).... right up until the very instant when I couldn't deny it anymore and it was on the screen in front of me.

Has this experience changed your way of thinking at all? It sounds like the thing people thought was possible actually was possible, and that Turing completeness really did mean what people thought it did.

I might use lesson you provided in my future to actually achieve something. I just need to doubt the feasibility of even the last step.

I still don't quite understand what it means to run Doom in the type system. I can sort of get how you might trick it into doing some calculations and generating some ASCII art. But how do you get tsc to access the audio system or load files etc?

Edit: Playing music isn't really relevant here anyway given that it took 17 days to load the level and display the first frame, and that's as far as the author took it. He says that subsequent frames would likely have "only" taken an hour or so each - giving about 0.0003 fps.

re the .WAD - the types-only-wasm-engine doesn't know anything at all about Doom (it only knows about what to do with WebAssembly) so actually the .wad is embedded in the WebAssembly exactly like you see in any regular WebAssembly Doom project (e.g. https://diekmann.github.io/wasm-fizzbuzz/doom). There's more to say about what "the WAD" means in this case, because it's a very minimal WAD - but it's all open source and I'll be explaining that in great depth soon!

A short explanation or link to a resource would really be helpful. :)

It's extremely hacky because Typescript is not even a runtime, it's not meant to run any code at all. Typescript is a thing that takes .ts file and produces .js file (which you then run using different program - a javascript runtime).

[1]: https://en.wikipedia.org/wiki/Prolog

Really amazing stuff, and impressive dedication. To the author: if you would like to work on challenges of similar caliber, ping me (I'm Syrus, from Wasmer)

As luck would have it I happen to be the happiest at my current job than I've ever been ever (and by a lot) buttttttt if it's interesting to you one of the express goals of SquiggleConf is to get WebAssembly to be a "oh I know how to use it" tool in the everyday dev's mind. So I'll definitely ping you some time soon to see what you think (and I hope you can tell I'm not sponsor shopping! even if you have people building wasm tools web devs should know about and you can point them towards our CFP that would be huge! we really want great wasm coverage to widen the playing field for everyone).

Also -> actually Wasmer does have a small part in this whole story with Doom, too, which is sorta neat (will come up in the next few videos!).

you're gonna laugh.. but the answer is "ignorance". I had no idea what I was doing and had literally never touched WebAssembly before but thought it'd be a good place to start. Then it just stuck.

Hilariously, later a friend explained to me "Dimitri, this would have been a LOT easier if you had just targeted ASSEMBLY. IT WAS RIGHT THERE IN THE NAME". haha. oh well! ignorance is bliss

Elysia is a backend framework like express. As you construct your routes — annotating the input structure and return types, it constructs a HUGE MEGA TYPE, that you can then use with a thin query client:

https://elysiajs.com/eden/overview

If I recall, the query client uses proxies. I did something similar before, this one is a much smaller codebase:

https://github.com/boehs/ajar

But as you can imagine, typescript does begin to lag when your routes enter the hundreds

> "I was looking for a job during working on this and absolutely got some disappointing rejections, and one was because of my lack of skillset on things like this in a big tech company's interview. I literally failed the technical screening. Oh well."

I mean... I don't have words...how f*cked up is the interview process ??

And then he said it: "All I wanted was the specific reason DOOM can't run in a type system but every time I hit a roadblock I always came up with some ridiculous workaround. I clung to that belief that it couldn't work and that doubt fuelled me the whole time."

Beautiful. I wonder if I can trick myself to one time attempt the impossible.

But in my case it's not widening anything, in Record, B can already be `any`thing.

People tend to see it as an unsafe escape hatch (which is how it is abused), but it's just a set of all possible types.

The `T extends Record` on line 11 is a type parameter constraint though. Are you referring to something else when you say "constraining the type"?

This is perfectly sound and valid from both a practical and theoretical pov.

Which is why I was pointing out that there are scenarios like constraints where any not only makes sense but is the correct type.

until yesterday, I did this whole thing in isolation (aside from a few of my close friends in a then-private-now-public discord channel patting me on the back every few days when I'd get stuck with no idea how to get unstuck). I realize that what I'm going to say next will be alarming to some people, but as nice as it is to hear all these wonderful just super heartwarming things from people over the last day (thank you!!) I have a kind of brain that would have been roughly equally satisfied if after completing it, I closed VS Code and never mentioned it to anyone again. For a different example, I used to spend most of my time making music and being in many bands and whatnot and I have, not exaggerating, like 200 hours of unreleased finished music - some even with album art (back when we had CDs haha). Probably 50 hours no one but me has ever heard and 50 hours only my wife has heard in the background while I worked on it and the rest just close friends. But when my close friends urge me to just release it... I just.... why? I do really really love to share, and I have (all the MiTS music https://soundcloud.com/michigan-typescript is open source with the BitWig sets available https://github.com/michigantypescript/music), but it honestly doesn't bring me a lot of satisfaction. Creating though... just simply creating and learning how to do new things brings me just a tsunami of satisfaction. I don't know how else to explain it. I'm just wired this way. I can't help it. It's like breathing. If I am lucky enough to grow old, I'm gonna be the grandpa in his basement with all the oscilloscopes trying to fix a Ham radio, even though I have no purpose for fixing it. I can tell you already.

That said, I'm relived to say that when it comes to this Doom project I learned SO SO SO many things that have been VERY VERY directly applicable to my career as a software engineer. In that way, ALONE, it was worth the effort. It's like multiple times per week that I'm able to help or contribute to something at my company with my team that was a skill I picked up on this project.

I've contributed quite a lot over my career to FOSS and I can tell you that many of the most useful contributions really started in really strange places with strange motivations. What's beautiful is that none of that matters to the user - they see functions and functionality and never know what's behind the curtain for why someone was motivated enough to really make it happen.

So to cap it off, I'd say, that actually what you're seeing in this Doom project is literally the best possible path to get what you say you want. There's nothing commercial about this, but if it gets people excited and gives people energy and capabilities to contribute to FOSS (even if it's just me, the author) - then now yer' cookin with gas.

>> @TimMattison >> If this guy goes for a big tech interview they're still going to ask him how to invert a binary tree

> @MichiganTypeScript > So actually in the "why" video, you're going to hear about exactly that! I was looking for a job during working on this and absolutely got some disappointing rejections, and one was because of my lack of skillset on things like this in a big tech company's interview. I literally failed the technical screening. Oh well.

> If this guy goes for a big tech interview they're still going to ask him how to invert a binary tree

The industry's hiring process is so messed up that this is completely believable.

"We've decided to prioritize other candidates, as you are strong in the fundamentals but lack the kind of experience in Vue that we're looking for."

Dont have enough time to find them now, but it's kind a obvious people would like to apply to places that already use their open source code. I would at least try, but no one use open source game-clone engines so no way on earth anyone will use what I worked on.

I have had maybe two interviewers ever mention anything on my GitHub, which I usually include on my application/resume.

Without context, I suppose I can see the Homebrew guy's case possibly signaling a sort of hubris since it was just a fizzbuzzy-level question.

In his defense, I would find it ridiculous if we just had a technical convo about how I built Homebrew and then they gave me leetcode question.

At least an easy leetcode question is insulting in a bearable way, like inverting a binary tree. But a medium+ question risks me not even being able to solve like, like having to use dynamic programming. And that's just humiliating.

And the harder computational challenges you’d likely learn as you need it. In which case, simply knowing what a binary tree is means you’ll know it’s available to you, even if you can’t invert one from the top of your head.

And even then, start going for staff or principal and your leadership, communication and architecture skills should be more of a focus than algorithmic puzzle solving.

When you gain experience and responsibility as a software developer and take on broader roles, the main values you've accumulated are higher level skills, like the ability to bring a project to completion (and everything that entails).

There's always a place for algorithmic hacking. But it feels like the easiest thing to hire for when you need it because it's so concrete. That's prob why it's so dominant in hiring practices: it's the only easy thing to measure.

It depends on the job! At a small product company, absolutely. Shipping useful features to customers is what you're hired to do. Hardcore CS knowledge is less useful than understanding how to talk to customers and shipping. Interviews should reflect that.

But that isn't all jobs, or all software. For a lot of problems - particularly in systems software or places where performance matters, understanding data structures and algorithms is essential. For example, video game engines, operating systems, databases, LLM inference and training, etc.

I get it - most product engineers don't make use of "leetcode" skills. But absolutely relevant at a place like google. If you don't understand how to reverse a binary tree, I wouldn't hire you to work on Google Chrome or the Go compiler either.

> But a medium+ question risks me not even being able to solve like, like having to use dynamic programming. And that's just humiliating.

What an incredibly entitled thing to say. "Those horrible interviewers asked me to solve a problem that was too hard for me! How humiliating! I failed the interview and its all their fault!"

The frustration of being asked a very specific question looking for a very specific solution under unusual time and pressure constraints I think is quite understandable. Not coming from a place of entitlement, but rather frustration that they know with high certainty that they could do well in the position, the question has nothing to do with daily work expected of them, yet its become this arbitrary pass/fail process due to people copying companies that are screening for positions working on Go or Chrome, when they just want a web app. I've been in several interviews, including on the employer side, where another technical interviewer asks these questions as a power trip. It's not helpful, and doesn't even get better candidates. Hence the frustration people are expressing.

Oh I get it. Again, if those skills aren't relevant for the job, stop asking them. At best you're wasting everyone's time. And at worst, you're going to make bad hiring decisions. In one chapter of Thinking Fast And Slow he says people have a habit of taking a hard question - like "Is this person a good candidate?" Instead of answering the question, we subconsciously replace it with an easier question - "Did the person find the solution to my puzzle?". Then, when you've answered the easy question you think you've answered the hard question! But you haven't - they're different questions. Puzzle interviews are a clear example of this cognitive trap.

Generally, nobody is born knowing how to give a good technical interview. But most people are thrown in the deep end anyway, with no training or no guidance on how to do a good job of it. So, as you say, they just cargo cult bad questions that they themselves were asked or go on little power trips. Very stupid and frustrating!

Which is all to say, I hear you and I agree that this is a problem. There's a lot of bad interviewers out there doing lazy interviews.

But.

I also think there are a lot of jobs where deep computer science knowledge is relevant and important. If you don't have those skills, you will (obviously) spend your whole career kept away from those jobs. So you wouldn't even know about them! But they're absolutely out there. React. Chrome. Linux. Sqlite. ChatGPT. NodeJS. HTTP2. LLVM. All of this stuff is made by other engineers. Usually, by engineers who know how to reverse a binary tree. CS questions might be overused in product engineering interviews. But CS skills are still relevant in a lot of very important jobs. Just, maybe, jobs that a lot of people might not be qualified for.

Like, literally, we build and fix the thing you're selling. We do not USE the thing we're building by and large.

Yes, thankyou, that's quite obvious judging by the quality of most software.

It really is amazing how bad most software made for non-developers is. Like, as software engineers, we understand how essential version control is. We made git and github for ourselves. But nobody has bothered building that functionality for people who edit word documents all day. Or people who edit video, or animators, or 3d modellers, or 100 different jobs. Word and google docs have track changes. But they don't let you bounce between branches or make pull requests. You usually can't time travel, or bisect, or git blame, or any of the other things we take for granted. My partner works in a CMS all day at work. Every change she makes is pushed directly to production. There's no review process. No staging. No testing. No change control or rollback. If anyone messes something up, they get blamed for "taking down the app". As a software engineer, I look on in horror.

I believe the more cognitive distance there is between 20-something silicon valley tech bros and your particular use case, the worse your software is going to be. If you're a manchild living in san francisco who can't be bothered driving, doing your laundry or shopping for groceries, you're in good hands. There is a startup that will solve your problem! But the further from that "ideal" you get, the worse. Here in Melbourne, I can't use my iphone to pay for public transit. Google maps couldn't really handle roundabouts (traffic circles) for a decade and change. (I guess they don't have those in California). Unicode support was only added recently because of Emoji. Until then, a huge amount of software butchered non-english text. I shudder to think how badly most software probably handles right to left languages. And the list goes on and on.

Fwiw that just sounds like an immature CMS - I've seen review/approval workflows, branches, preview environments etc in more than one CMS. I take your overall point but maybe your partner doesn't have to live this way.

I agree - but if a review system exists in the product, she's never seen it. They don't even have a staging system for testing changes. Its wild.

And for context, she works at a large organisation that's a household name here in Australia. This is a large organisation thats been around for well over 50 years. They have an engineering team and thousands of employees.

I don't know if the software is bad or if its misconfigured. But the status quo outside of our industry is jaw-droppingly terrible.

I highly recommended doing the same if you can swing it. Its equal parts insightful and motivating. And the clients generally love it - since it shows your team really cares about their problems and use case.

Also usability concerns have nothing to do with reversing B-trees.

> I was looking for a job during working on this and absolutely got some disappointing rejections, and one was because of my lack of skillset on things like this in a big tech company's interview. I literally failed the technical screening. Oh well.

The best anyone can figure out is that it's reversing the left and right branches, which seems like it's ten lines of code, at most?

When my team conducts technical interviews, we are asking for a couple simple programming solutions - but we're asking because we want to hear the candidate talk through it and see what their problem solving process is like.

If you aren't evaluating based on conditions like those, I don't really see the value of coding questions.

Another interviewer asked a much more interesting question: you are writing an IM client. How do you build the client-server communication?

That was a great conversation I enjoyed on its own without regard for the interview. Asking questions: do we have online/offline status? (yes) What are the target devices? (mobile).

IIRC I said I'd want to optimize for bandwidth and latency. Cellular networks can be spotty at times and stall out in really annoying ways. I'd design the protocol to use an efficient encoding with a pre-shared dictionary (the list of friends doesn't change that much after all and lots of the same words/emoji are used frequently). I also said I'd make a flexible format that would let things like online/offline status or you have a new message from X ride along with an actual message in the current conversation and explore options like QUIC or other UDP-based eventually-consistent options given how a cellular dead band can put you in TCP retransmit jail for minutes at times.

For closure I was offered a position but went to a different company.

Understanding how someone thinks is more core to evaluating candidates, so questions like “let’s say you own a window washing company and you’ve been hired to wash every window on every skyscraper in New York City - how do you do it?” provide a much better insight into how someone goes about approaching a challenge.

A coworker has a simple diagram they use outlining a tech stack: backend, cache, frontend, and they give a brief overview of the “application.” Then they explain that there’s a big report that “customer says X isn’t working - how would approach fixing this?” It’s less technical on details and more about again how they would approach finding the issue.

The way I think about it, you're really trying to evaluate a candidate on about 10 different metrics all at once. Metrics like programming skill (writing & debugging), communication skills (listening and explaining), capacity to learn, domain knowledge (eg if you're hiring a react dev, do they know HTML & react?), likeability, and so on.

A good interview gives the candidate the chance to show their worth in all of those different areas. But time is limited - so you want some different challenges which will show many capabilities at once.

Asking a candidate to talk through how they'd solve a "leetcode problem" sort of does that - you can see their CS knowledge and their communication skills. But if thats all you ask, you end up overemphasising the candidate's CS knowledge. Most people aren't very good at thinking and talking at the same time. And you don't learn about other stuff. How good are they at debugging? At reading code? Do they have domain knowledge? Can they talk to clients? Are they good at design? Its also quite easy for the interviewer to be distracted by the question of whether or not the candidate solved the problem you gave them. - Which isn't really what anyone is there for.

As part of a larger interview, and especially for systems engineering roles, I think they're still fine questions to ask. But if thats the entire job interview, its a bad interview - because it won't let you evaluate a candidate properly. Especially in product roles where CS knowledge isn't very relevant anyway.

In terms of the problem itself, a binary tree can be expressed something like:

    type Node = { value: T, left?: Node, right?: Node }

    function invertTree(root) {
      if (!root) return null;

      // Swap!
      const tmp = root.left;
      root.left = invertTree(root.right);
      root.right = invertTree(tmp);

      return root;
    };

    function invertTree(root) {
      const stack = [root];
      while (stack.length > 0) {
        const node = stack.pop(); if (!node) continue;

        // Swap!
        const tmp = node.right;
        node.right = node.left;
        node.left = tmp;

        stack.push(node.left);
        stack.push(node.right);
      }
      return root;
    }

If you see a binary tree T e as some kind of function, it can test whether an element exists, a typical set operation. So f : e -> {0,1}, where (e,1) means the element is in the binary tree. (e,0) means it is not in the binary tree. All those (e,0) creates some sort of complement tree, which might also be seen as inverting it.

What would be really weird is seeing it as a directed acyclic graph and invert the direction of every edge.

In a pure ASCII world, this doubles as "how do you reverse a string". In a Unicode world, the answer to "how do you reverse a string" is "you should never want to do that".

But if he was being considered for a mid level generalist role, yeah, none of this would’ve mattered. And why should it?

  > But if he was being considered for a mid level generalist role, yeah, none of this would’ve mattered. And why should it?

Of course unless your passion project is very successful one, but majority of them are not.

I worked on a repo for several years with many tens of thousands of lines of code and attempted to promote it heavily with little success. At some point I chopped out about 2,500 lines of code from that repo and packaged just one feature as a standalone product.

Years later the child repo has thousands of users and the parent has barely any. While I consider both projects to be successful by definition, if I'm going to briefly showcase one over the other I'll showcase the smaller project that received more engagement. Because the engagement metrics do indeed matter. It lends credence and legitimacy to a project.

It's less the tree operations themselves and more that this candidate just didn't know the shibboleth, so they shouldn't be allowed in. Cue the vague feeling of disgust on the interviewer's part that the interviewee didn't know something "so simple" in a tense environment with lopsided power dynamics.

Candidates have a very diverse set of backgrounds, age, experience, culture, education, interests, experience. The coding interview is a common denominator: undergrad algorithmic knowledge, being able to solve problems which are application of classic algorithms. This is something that a decent coder should be able to prepare for within a few months of regular practice. In my case, I can tell that these months of practice were the best investment in my life. And honestly, I feel I'm a better programmer after this preparation.

> Cue the vague feeling of disgust on the interviewer's part that the interviewee didn't know something "so simple" in a tense environment with lopsided power dynamics.

This is your interpretation of the situation. As an interviewer, I want the interviewee to succeed, I understand it's stressful for them as I've been in their shoes before.

Ultimately, there are more candidates than positions, so whatever the interview is, people will complain about it. I think leetcode is a decent interview technique. I wish we would give more time to candidates though.

So that's not interesting to me at all as a person hiring engineers.

What I want to know is "how have you solved bigger design problems" or "what's your approach to keeping code maintainable and reducing cost of ownership"

I've also hired people who 3 other managers have passed on and those people have gone on to amazing things at the company in which I work.

So the process is horribly broken... it doesn't successfully weed out anyone, and we've also hired really toxic individuals also with the same processes.

I have a nuanced view of your particular example. I've been in this industry for almost 30 years. I cut my teeth writing C/C++, had an interest in language theory and frameworks and was brought up to care about portability. I always wanted to be able to easily transition from one language to another, or one framework to another.

And I always assumed this was the case for other engineers in our field as well.

However, I have worked for startups that like to move really fast, and hired talented developers who passed our technical screenings (read: "had the fundamentals down") under a "framework agnostic" hiring policy ... only to see them display stunning degrees of incompetence trying to learn our tooling.

The problems that compound this are:

- When you enter a new company with a large codebase that you have to ramp up on, you're not only required to learn the language or 3rd party frameworks and libraries that they use ... you need to ramp up on THEIR "framework." Depending on the complexity of the system, there is a lot of domain specific knowledge and custom supporting code that will have been written. Try to learn the ins and outs of Angular change detection, for example, while also ramping up on a massive codebase that does things in weird ways for legacy and historic reasons.

- Every business, but some more so than others, has time pressure. You need to be able to write functional, easy to maintain code but also get it shipped yesterday. If you come into a company unfamiliar with the languages and tools that they use, you are essentially coming in handicapped. Expectations that you can deliver are very high, despite the time that you need to ramp up. Maybe you're one of those 10x'ers who can learn all the ins and outs of a new tool in a week or two before starting your position and then apply that knowledge at the level of someone whose been working with the tool for years and has learned all of the hidden footguns ... but if so, you are a rare specimen indeed. The industry can save itself a ton of inefficiency if it takes a "better not take a chance" attitude.

- All problems are people problems. It's not that the company needs people who know how to code in the language or tool ... they need someone who has worked on enough different projects with that tool that they can navigate the completely fucked up ways that THIS company uses it. Because THIS company will for sure have years of active development behind it by developers of all sorts of different experience levels ... and some of those developers did it the right way while others found creative solutions and did things weird. The company doesn't need someone who can write the Hello World tutorial in the language or framework, they need someone who can evaluate the good decisions vs the bad ones in an existing codebase.

I think you could turn the responsibility the other way around quite as easily, and I think you're mistaken grown complexity, one that is inherent in a company's system (accidental or not), when you outline what you mean as "framework" here.

Frameworks are documented building blocks, so are programming languages and libraries - those things are meant to be used as foundations and are designed with the thought that anyone could ramp up with progress easily. If they wouldn't be documented in a somewhat usable form, then there is a high chance that they wouldn't be used as building blocks in the first place. Companies are nothing like that(!), be it because their inherent system has not been designed as useful tool (that's the focus of their products after all), be it because their projects haven't been created out of passion and just need to bring in some money, or be it because of multiple other reasons I could mention.

In every company I've had the pleasure to be joining so far, I've always encountered that something (even sometimes more) gets written from scratch and will just stay undocumented (even untested). If a company is anything but a hobby project there is always this overload on tooling, because someone wanted to dabble in domain A but didn't want to learn building block A, so they just put building block B also into domain A, or even introduced their new interest: building block C - NIH[0] is also a real thing. We humans have a very short attention span and are surprisingly overconfident when it comes to the design of complex systems. It's also significant harder to read code than it is to write code yourself, and if you had the luxury to grow with the codebase of a company, then you'll also show a natural tendency to just overlook some of its inherent complexity. And those are just the technical aspects of it all, mind you. There are social, cultural and economic changes in each company that affects its complexity just as well (going from MVP to sustainable product, CRMs, outsourcing etc.).

> Every business, but some more so than others, has time pressure. [...] If you come into a company unfamiliar with the languages and tools that they use, you are essentially coming in handicapped.

The true capital of a company is its people. If you have the chance to bring someone in that you'll trust wholeheartedly, then that's a huge gain for the whole team and even outlives any visionary business prospects of any kind.

> All problems are people problems.

Agree!

> It's not that the company needs people who know how to code in the language or tool ... they need someone who has worked on enough different projects with that tool that they can navigate the completely fucked up ways that THIS company uses it.

Here's the interesting bit: If this candidate would have already learned that their tool of choice is used in a fucked up way in THAT company, then what incentive would the candidate have to join THAT company in the first place? Is that company even fully aware of its fucked up usage of that tool?

Tools need to be learned for problems to be solved. This hypothetical candidate might have learned enough already and would like to focus on the problem at hand, but now has to deal with the annoyances of "making the fucked up state visible" instead. Or, considering the fucked up state is already well recognized, now just needs to do what feels like chores before it gets interesting again, but doesn't want to live with the fucked up usage in THAT company.

> The company doesn't need someone who can write the Hello World tutorial in the language or framework, they need someone who can evaluate the good decisions vs the bad ones in an existing codebase.

Agree, and that somehow contradicts everything you wrote previously.

[0]: https://en.wikipedia.org/wiki/Not_invented_here

No I'm not. I'm not reading the rest of your reply because you completely misunderstood me here and then proceeded to give me an insulting definition of what a framework means while completely ignoring the broader point I was trying to make.

In fact, I did the following to add clarity:

1. I put the word "framework" in quotes to make it clear that I was using the term colloquially

2. I elaborated that I was talking about custom supporting code and other tooling that was developed by the company in order to solve domain-specific problems.

I have built frameworks. I continue to build frameworks for my employer on a Platform team. We work with 3rd party frameworks and we need to build on our own. This is just normal encapsulation, building higher level APIs on top of lower level ones.

So when I say "the company's framework" I'm referring to the stuff that was buit in house in order order to develop highly domain specific functionality with a higher level API than what the 3rd party frameworks are providing out of the box.

A framework's super-power is that it applies the Holly Principle: don't call us, we'll call you. That's what distinguishes a framework from a library. Libraries sit there passively waiting for you to consume them. But in our industry, like the word "hacker" and "troll"... people start using the term colloquially. And in this case we're talking about the specific APIs that the company has developed which you need to ramp up on even if you are highly experienced in the specific 3rd party frameworks that they use.

And even if we take the word framework absolutely literally as you did in your comment, companies still build "literal frameworks" internally in order to try and simplify. But you gotta ramp up on those.

At my existing employer, we have even taken 3rd party frameworks and libraries, and forked them and developed our existing custom tooling with them because our domain specific requirements brought us to that level. So now you're coming in to our shop not only needing to ramp up on those 3rd party frameworks, but you gotta learn and understand how we changed them too for our purposes.

Companies optimize hiring for avoiding false positives (bad hire) over false negatives (bad rejection), especially in this job market.

Faced with the immutable fact that the chief executive cannot watch everything, that there will be pockets within the organization where people will sell access to a $300k job, and where others will hire from their family, their tribe, or so on: you make a system that is meant to prove some minimum standard while constraining your interviewers.

One thing that is not immediately obvious is that the Big Tech hiring process is to constrain your hiring team in who they bring on.

Startup executives are close to the road so they can tell if the rubber’s good much more easily.

The hiring process is designed around the constraint of executive attention. As are most things in firms.

Maybe it's just me, don't want to crash the party. Carry on

> I just see a massive waste of time & effort

Kinda seems like you do wanna "crash the party". I disagree that this is a "waste of time" of course, the value I see here is manyfold:

1. Learning how to do self-directed learning, managing time, etc

2. Learning, at an expert level, about dozens of complicated (not to mention in-demand) CS subdomains

3. Doing something that nobody has attempted, and few people could realistically accomplish

4. Having fun on the journey of taking a ridiculous idea from conception through to a truly functional implementation

5. Sharing something you've built with the world

It is, of course, not everyone's cup of tea, but if someone wants to spend a not insignificant fraction of their life building something unique (and beautiful, in its own way) and sharing it with the world, to the detriment of quite literally nobody else, I support them in their adventure.

Recreating the WASM runtime makes you learn a crap ton of useful stuff no matter what you use as your host compiler. In this case, the host being the typescript compiler happens to also add a wow-factor.

Doing things can be difficult and admirable, even if it was confidently believed possible beforehand.

My reaction then isn’t “wow, this blows my mind that it’s possible”. The first time someone climbing Mount Everest 72 years ago was impressive and possibly astounding. Nowadays, not really that much.

The time is now, but if you had said

> I wonder if there will come a time when the HN audience will stop being amazed that some system can run Doom

The answer is never, and particularly not when its this insane to even try

Just because we know something is possible in theory doesn’t mean it’s not impressive to see it done in practice. There was a lot of effort and creativity involved here.

    1) Show that a system is Turing complete
    2) ???
    3) Run Doom on it.