> "It was a brutal year long journey of 18 hour days" [to run doom in TypeScript types]
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.
I don't thinks statements like this are meant to be read literally in American English.
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.
> I don't thinks statements like this are meant to be read literally in American English.
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.
This happened to me once. It was like attaining enlightenment. My company worked with a F100 that had, as a core piece of their business, a piece of software they'd commissioned in the 80s that they still used in the 2010s to make billion dollar decisions. But no one knew how it made the calculations they relied on. This was before attorneys knew to include source code in procurement, the original devs at a third party code shop was long gone.
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.
Imagine if every human had the resource security to do this for a good portion of their lives. Star Trek was fiction but we could have that if a few of us humans weren’t so greedy!
Virtually everyone living in a developed country has resource security to do this. Even in America, with its relatively poor levels of social assistance, you could live off of the dole as long as your expectations on quality of life are low.
Turns out, in the real world, people like having nice things, hanging out with family and friends, travel occasionally, etc. instead of just entering flow state to solve problems! It has nothing to do with income inequality.
People have to be comfortable to be as creative as the OP comment, so while I agree in principle, I think it's going to be harder than you imagine to build amazing things when you're living below the poverty line. The anxiety and mental anguish alone could cripple a person, even someone that isn't in the worst situations.
hi! author here! it's a pipedream, I know, but it's a hope/goal of mine to, in the next video (the "why did you do this" video) to give some fuel/motivation to people that might be feeling like you describe. do you have any advice for me for what I can say in the upcoming video to someone that might not be as comfortable, as you say. I really do have a grasp for how hard what you're talking about is, and I've tried over my life (sometimes very hard, sometimes too hard) to help people I know to overcome it (sometimes successfully, sometimes not). When you're in survival mode every day, you might look at a project like this Doom one and go "yeah right! not in a million years could I do that with my current set of things weighing me down!". anyway, don't want to ramble, but if you (or anyone else reading) has any wisdom to share on how to talk about these things in a way that's effective or inspirational for people, I'd really love to learn.
I have no advice because I’m still kinda in the bad place but I think it just takes one thing you can focus on that you enjoy and sometimes you can slowly dig out of the hole. I’ve started woodworking and the joy I get finishing a project has helped to push me forward. Just talk from the heart and you’ll make a good video I’m sure.
Good luck, your project is very impressive and I hope you are able to continue to make cool stuff!
I really don’t think this is generally true. Assuming you’re single with no children, there’s effectively no cash assistance available where I live. You might be able to get public housing and food welfare (SNAP), but you would have effectively zero income. You could live on savings for a while, but that’s obviously not “the dole”
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.
That's correct. Hyperbole and dramatization of real events was entirely unknown to the world until it was invented in a rural Nebraskan town in 1854 (pre-statehood). It's been a staple of American speech ever since. Only recently has it begun to find a footing outside of the United States. It's a similar story with Comedy, as well.
I never said it was only in American speech, just that it's very, very common, to the point where a lot of what Americans said made less sense to me until I realised it.
Different cultures express things differently. Overstating, understating, etc etc. If you want to understand, and be understood, it's important to know.
So much hyperbole that I thought the entire video was a spoof on the practice of making a Doom proof until about a minute in, where I asked aloud to an empty room, "Wait, this is real?"
Also, he forgot to credit the video itself, which has a really high production value! Kudos all around!
I think you are confusing hyperbole with poetic license, and overstating the effects it has on English vernacular. I am not American, but I wouldn't go around minimizing how industrious the "great society" is.
Yeah I worked out the "N days without sleep" was mostly rubbish too.
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.
At 18 hours of work a day, your money need are relatively low! Pair that with just sleeping at the office toilet and eating used coffee grounds and everything should be good!
It's happened in the last couple of months, a clear uptick in aggressive comments. I'd hazard a guess at people using HN as an outlet for feeling angry and helpless about the US political situation.
"But I'm not one of those fancy 10x developers. Instead of a master of craftsmanship, I'm more a master of close-enough-manship"
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 love that there was a moment when I realized that all these things where I could’t understand how someone could possibly figure out a trick to create them didn’t use any trick at all. It was instead just mountains of hard work.
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.
One of the things I like to mention to younger devs, when I pull out a solution that they think is from thin air, is that I have failed far more often then they have. I just have a good memory on how to fix my mistakes.
society create the überman myth to keep the working class down, thinking they will never be the top of their game. the ones doing the hiring know that those putting in 18hrs a day are the unicorns, i.e. the best they can hope to find.
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!
People usually don't see the history of these kind of systems.
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.
I’m close to one of these types and I get taken advantage of a lot and desperately wish I could turn it off. It presents in weird ways that are hard to navigate politically - often I will end up on a team and be outputting a large majority of the work, people/egos get hurt or threatened, still inevitably make the same anyway. It's never really led to any kind of career or financial success I'd have thought it would have years ago.
You are halfway there my friend. The other half is tactful self promotion. Make sure your skip levels see what you’re doing. Do a little less for your team and a little more for other teams and make sure their leads know you’re helping. Become the legend you can and it will result in much success. Output is only half the picture.
This is something I've witnessed first hand for years, and heard for others too. I tried to be smarter politically but it's eating my brain. Wasted brain power for petty anthropological issues. I bet the solution is to be surrounded by quality people but it seems rare. Also negative people will do wonder to paint anything you do as a problem until they're able to do the same.
It can depend on your manager and the growth state of company. I don’t think I get take advantage of, but I’m very productive and have been rewarded for it.
> society create the überman myth to keep the working class down, thinking they will never be the top of their game
What? The distribution of talent and grit being what it is, ubermen do exist. Some people are naturally tall, good-looking, able to recite pi to the 50th digit, solve challenging analytical problems, put in long hours when necessary, and get along with the in-laws.
Of course, the ones doing the hiring probably know that such people won't stay in the position for long. But it's not a myth, and certainly not one to keep anyone down.
I can also relate - I'm a tech lead, and it just also happens to be I find programming to be an enjoyable puzzle. When my wife sticks on some TV, I'll usually scratch an itch with some problem I've spotted, or some improvement that can be made - most of our docker build time improvements are me trying out different things and finding what works - same with little QoL features.
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.
But is it technically untrue if the start date and the end date are more than twelve months apart and some of the days between those dates saw 18 hours of work on the project? Arguably it could be both, not technically a lie but hyperbole nonetheless ("37h split between two days a year apart").
Yeah I relate to this too. I often head into something not knowing what to do, taking the naive approach, realizing there's some patterns I can tool out and simplify, and refine my process. Basically just chewing through the problem. Frankly I've never met a project I couldn't finish. Since I'm not really that talented, it's the thing that gives me the confidence to tackle something.
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…??
(author here) pause on that screen and look at the code displayed on the right (as well as the note at the bottom!) the way to do keyboard inputs is basically exactly what people do for tool assisted speedrunners. Some people at this point in the message just went "oh cool!" and others went "you liar! that's not the same thing!". There was SO MUCH to say in 7 minutes in a short video like that, but rest assured, I'll go into depth on that in the next videos. The pong stuff that's shown is real (only the animating part was the creative liberty) and it's in the open source codebase.
I haven't checked the DOOM one, but for the Pong example, the keyboard input is prerecorded. As in the sequence of the keyboard key press are sequenced in a TS array[0].
If I had to guess, it's a file with an array of keys pressed (or unpressed) at some time interval (say 0.1 seconds). Then a VS code extension can append to the array every 0.1 second along with any key-press states at that time. The compiler updates the game state whenever this array gets updated.
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.
If I heard him correctly he stated that it takes A LOT to just render a single frame. It's not playable. It can run DOOM, but you can't actually play it.
Or more specifically, everything that is Turing complete can run DOOM, but most languages are only Turing complete under certain assumptions which are not met in practice
I got to watch Dimitri posting internal updates about his progress on this, and it has been utterly mindblowing. This is genuinely one of the most amazing things I've ever seen done with code. Absolutely legendary feat! (And also an incredible amount of persistence.)
I am at the same time both amazed and utterly unsurprised that this was possible, given all the hullaballoo about TypeScript's type system being Turing complete. Having the grit to actually go through with it though? Bravo.
Is there a mainstream language where this still holds true?
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.
both this and parent comment are right! once you have the first frame, it's probably just a few hundred more megabytes to get the second one - although I won't be the one to find out! 1 is enough for for me!
Most people would agree that Mengelberg‘s 1984 paper clearly answers that question … of course, we all know that his language is famously hard to parse!
Not only is Dimitri an amazing engineer - he's also great at building community and event/video production. Michigan Typescript meetups and videos have a level of polish that goes over and above
In the YouTube comments he stated nonetheless that he still bombed big tech interviews, specifically the technical portion, probably because of some ridiculous LeetCode problem he did not memorize beforehand. It just goes to show how these procedures do not effectively determine who is actually a good engineer or programmer. If this guy can't land a job while achieving this, then something is not quite right with the interview process.
hi! yep! this definitely happened. I do mention it in the next "why" video, but it's good feedback to know this is interesting to people because I could say a bit more about what those rejections were like - specifically the one where I failed the technical screening.
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.
I was crushed and embarrassed. Yep. Not even gonna lie.
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.
You have coding skills. Some marketing and video production skills. Self discipline and persistence. The time to spend 18hr days on a project. Why look for employment? Start your own business.
are you some kind of fortune teller!? haha. so that's so funny you say that because that, too, is a big part of the story. actually I was gearing up to do exactly that - but everything blew up in my face and this Doom project was, in many ways, my way of picking up the pieces from the rubble.
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).
Those interviews select for the type of person that believe it is worthwhile to dump tons of time into studying minutia to succeed at those types of interviews.
The purpose of a system is what it does, after all.
You're making an excellent case for using AI during the interview. If you can actually code and do the work, you're hurting no one by using tools to get past these arbitrary barriers during the live interview. The system is clearly flawed when someone demonstrably skilled gets rejected over trivia.
I actually created a tool to help myself get through the live interviews, specifically by listening to the questions and giving me real time answers to things I couldn't recall under that kind of pressure. It's not about not knowing the material, it's about the ridiculous expectation to perform perfectly on demand.
I didn't ask them outright, but I sorta think the TypeScript team might agree with you on this point! haha. At least we can all agree it's not an intended use-case, to play Doom.
Nothing will ever top this for typescript types. This is the pinnacle. An entire virtual machine and system memory with garbage collector in types.
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.
(author here) _yes I realize how ridiculous what I'm about to say is considering the project I just shared_ but I actually strongly disagree, haahah. there's this thing I learned of called "the turing tarpit". my position is that just because something could theoretically be done with infinite time and infinite resources, doesn't mean you can even approach the throne of doing it for real in a human lifetime.
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.
Of course you're right, and I should have put quotes around "just". It would be amusing to calculate how long it would take to render the Google home page via Doom via TypeScript; I'd guess much longer than the age of the universe.
Off topic, but as an obsessive debugger and experimenter with ADHD and someone who hates telling people lies about what can and can't be done your motivation speaks to my soul. But my usual rabbit holes last just few hours up to few days. And even those that go far (that avoided all obstacles) end up right before implementing the last step, when it becomes obvious to me that this thing can be done. Congrats on the sheer stamina.
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.
> 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 hope this doesn't come off wrong like but honestly - but the outcome on this project doesn't change my view one bit. it didn't make me dig in my heels either, but I strongly doubt it's possible in a human lifetime to do this with at least some of the other languages that have type systems that are considered Turing complete.
It looks like they built a WASM runtime in the TS type system. Implement some more OS calls and you should be able to get a browser running. And then WASM on WASM on TS types. Lol
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?
I don't think it's actually playing audio or loading files. The required game data (.WAD) was presumably pre-transformed into the encoding that the virtual machine uses for data and passed to the program as type-level "input".
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.
no audio - correct. technically, in a certain sense, the first frame will contain only one sample of audio, and I did consider that, but a single impulse is the definition of "juice wasn't worth the squeeze", haha.
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!
Normally you would write a program that is a game of Doom when you run it (you create a program, then compile it and run). Dmitri created a program that does nothing and he don't even run it. But while it's compiling, it does a lot of tricky things to make typescript compiler to run Doom as a side effect.
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).
TypeScript types are a kind of Prolog [1] (sort of, kind of, not entirely). Like any language they have primitives (`boolean`, `string`, `true`, 'Manchester'), functions (`type WaitWhat<T> = { yesReally: T }`), variables (`type X = number;`), and conditionals (`type Huh<T> = T extends Foo ? Bar : Baz`). You run the types program by asking `tsc` to check the types of some program - e. g. `type Foo<T extends number> = { x: T }; type Bar = Foo<string>;`. Getting output out of the type system other than via "hover over the type in VSCode" is probably a bit more involved, but it's definitely doable (I suspect some abuse of the Language Server Protocol here).
It might be helpful to look at something like Typescript Tic Tac Toe in the type system [1]. You can comment out individual lines in the GameLoop type, and then hover over `____________DISPLAY___________` to see the current game state. Illegal moves will result in type errors.
Running Doom in the type system effectively means a lot more types have been generated (effectively a C to typescript-type compiler was created if I understood this correctly), then the game was started with no inputs entered. Theoretically if the author had infinite time and compute resources, the history of control inputs up to a certain point in play could be put in a tuple, and the type system would generate the state of the game given the code and the moves which the user had input so far. This state would include what's on the screen, but also internal state variables controlling things like where the enemies were moving, whether projectiles are in air, their direction, collision detection, etc.
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!).
I wonder if there are any small changes/improvements to TS that would make this orders-of-magnitude more efficient to run? It would be fun to go implement some random TS feature with the secret sneaky goal of making it run Wasm better.
I had once built a type checker for a query language within the TypeScript type system, I thought I have reached the limits. Actually showed it to the TS team and they felt the same. This is like something my mind could never had even swallowed, let alone be able to ever build! Nice job!
Amazing work. I'm interested in the choice of WASM - presumably any target that can run DOOM could've been used? Of which there are innumerable choices I assume. Was it for symbolic reasons or genuinely the most useful target?
love this feedback - will definitely talk about it in the next 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
Ah nice! Well, hats off this is really impressive. As other commenters mentioned the extent to which it's documented and the restricted scope probably helped.
WASM is one of the easier platforms to port as the Virtual Machine is well documented and there are actual implementations in many languages that can be used for debugging and comparing the results.
But that's all CPU -- he doesn't have to emulate the rest of the computer (video card, IO systems, etc). You provide WASM with your own interface to the outside world.
(not arguing, really just want to hear your thoughts to this!) so re: video card - but I did write what I don't know what else to call other than "a graphics driver" (i.e. it takes Doom palette pixel values and converts them to something the user sees on their screen with ASCII art). what else would you call that? or are you saying video card would have to be at the level of VSCode or my operating system that actually lights up physical pixels on my screen.
If instead of WASM you decided to emulate a different DOOM target like a PC then you'd have to emulate the actual VGA graphics hardware and enough of the other PC hardware to run the game. That level of emulation is a difficult project on it's own.
got it, ok sweet. thank you so much for explaining. I don't know a ton about these programming circles, so I don't want to say the wrong thing if I can avoid it. Sounds like you're saying that no WASM runtime is, in this sense, qualifying - which makes sense!
Brilliant. The TS type system is a true marvel of modern software engineering. Its a shame that it hasn't just been developed into a proper fully fledged runtime at this point. Something like Deno is the closest we'll get it seems.
hi! author here! selfishly, it'd be really useful to me if you could take a moment to elaborate on your thinking here. it's not an altogether-too-too-uncommon viewpoint and I'd like to understand it if you have a chance.
Throughout the video and while appreciating this unbelievable feat I kept thinking "how could someone have the motivation necessary to tackle such an insurmountable undertaking" ?
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.
yes! I completely skipped over it in the video for time, but the performance benchmarking tooling I had to make to is something everyone can benefit from, and I'm excited to find someone that sees how big it'd be for the TypeScript world if we can extract some of that (I'll need help!!)
I work with a couple type-dense libraries: Elysia and Kysely. Kysely holds up remarkably well. Elysia... Well...
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:
(author here) that was one of the 1st-week "ok, but THAT'S surely a good reason this can't work..." until I dug in and (to my great surprise) found a way.
This is mind-blowing! I knew TypeScript's type system was Turing complete, but seeing it actually run DOOM is another level. The sheer creativity and engineering behind this make me wonder—what are some other extreme use cases where people have pushed TypeScript's type system to its limits?
I hope the TypeScript team at Microsoft sees this and goes: "What have we done! We have created a monster... we need to tame and simplify this beast. Or at the very least stop adding more features."
I can’t agree enough. It’s sort of like those massive paintings recreated in CSS. They are a neat achievement, yet sort of reveals a vast emptiness that exists within the author.
A Turing complete[0] language can do just about anything any other Turing complete[0] language can do, even if the language used is a language's own type system.
Mad respect for the author. This is a non-trivial achievement indeed.
it was done on an 13900k system with 128gb ram. I bet the performance would be very different on other systems. and by my calculations the next frame would only take like maybe an hour or so to render. so that means that actually, hilariously, if anyone wanted to really dig in and make the engine faster - which I suspect it can be done by multiple orders of magnitude, truly - then actually I'd say 30fps types-only-doom is possible in the next maybe year or two. the TAS-style keyboard controls will work, but one problem is definitely going to be "how do you refresh a screen" which is a problem I didn't attempt to tackle other than to say you could (with what I already built) just hover your mouse over another type that contains the information for frame 2.
Fascinating. Just for fun, comparable compute (by cpumarks) to your 13900k for 30 fps would be 39,600+ 96-core AMD EPYC 9655Ps. Bravo on the project success!
you know what's funny, I also have a threadripper rig (which is my main development rig) and it ran _slower_ than on the 13900k. Like. by a lot. and while that surprised me at first, it's makes a lot of sense because this is Node.js in the end (i.e. the TypeScript typechecker runs within Node.js) and that means it's single threaded. So single-threaded perf is all that matters.
i envy dimitri's ambition and capabilities. i want to be able to dedicate that much effort and more into something I'm passionate about. mostly personal discipline/skill issues but MAJOR props to dimitri and this awesome project.
I'm glad you said this actually, because I had a section in the "why" video where I tried to compare this project to how I've felt having kids and cut it out because it was too cheesy. maybe I'll bring it back!
I'm not diminishing them, I am in awe of their work, I'm just pointing out that sometimes people (including myself) focus on esoteric projects that might have some learning opportunities, but don't directly solve a real problem (and might just be psychological mechanisms).
hi! author here! it's taken me many years to be able to self reflect enough to produce these next few words, but the answer is I have learned about myself that I perform better under pressure. I'm more consistent, reliable, and make better decisions when it's go-time. so I guess the answer to your question _should_ be yes.
although.. I've noticed I have other flaws that have burned me many times in responding to incidents. Oh well. The one I've been working on for years is "when the system is down, check the status page of the upstream provider first because it might not be your fault". I always assume it's my fault for way longer than I should.
Apparently, this guy tried to apply to BigTech to get a job but was rejected.
> "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 ??
Honestly every time I worked on TypeScript codebase and the type definition "any" started popping out more and more often, I felt I'm starring into the abyss.
Sure, there's many other ways to type it, but none adds any kind of additional safety or strictness over Record<any, any> which was my point that `any` is the correct type in many cases, except when it widens a type.
But in my case it's not widening anything, in Record<A, B>, 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.
I know it's not equivalent, it was just an example to show what `any` does (and that it's more than "just a set of all possible types").
The `T extends Record<any, any>` on line 11 is a type parameter constraint though. Are you referring to something else when you say "constraining the type"?
'any' has always been intended as an escape hatch, so no abuse here [1]. The type representing the set of all possible values (the top type in the type lattice) is 'unknown'.
The widest possible function type is `(...args: never) => unknown`. This is because parameters are contravariant, and `never` is the bottom type. Using that type works in the author's example[0].
I've got an issue open about TypeScript's provided `ReturnType` type which is somewhat related to this[1].
That was the tipping point in transition from "we are serious and use static typing instead of lame JavaScript" into "ok we lost control over this thing".
People generally just give up after a while with the type system. I consider myself decent with TypeScript and you end up spending a good chuck of your time satisfying the compiler for something which is literally a one liner in plain JavaScript.
I'm sorry to rain on this parade, but I fail to see the merit of spending so much effort - and writing so much code, generating so much data, working 18hr days etc. - to render Doom in TypeScript type-checker.
I mean, there all sorts of feats and achievements one could choose as one's goal, which would also be impressive, but would be more useful to users and/or software developers, than this. I'm just thinking of all of those times I wanted to suggest a software tool to someone and went "ungh, if there was only some FOSS which did that" - and there wasn't, or at least, it wasn't assebled from pieces into something usable. Then I think about spending a person-year on this and I get frustrated.
hi! author here! this doesn't rain on my parade at all! actually I really appreciate what you're saying, so thanks for saying it!
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.
Think of how much joy it would bring to people if the author would work on a piece of software which would be consistently useful beyond the one-time novelty.
Of course, it's a matter of proportion - I'm not saying that only things of utility and no "fun" stuff need ever be produced; but this is a rather extreme case.
Oh haha well now I feel dumb. Of course it is! The high pitched sounds are similar to the Batman Beyond intro. I can hear the djenty riffs better now though. Sick video!
>> @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.
He's also one of the principal organizers of SquiggleConf, a conference focused on devtools that takes place in Boston: https://2024.squiggleconf.com/about
What I'm saying is, if he still happens to be looking for a job, any employer reading this should be falling over themselves to recruit this man.
There is more to hiring than technical competence. I'm not seeing any red flags in his videos, but just saying, ability to work in a team is not obvious from such posts.
strong agree! so much of it boils down to "do you treat people good and stuff". then there's "do you treat yourself good and stuff", and then a tiny little fraction that's "can you work hard to get to an answer" and finally, least of all, "what do you know"
I think what's more important is a company's / team's ability to onboard new hires to their way of working (so what you should be testing is humility and open-mindedness). Ability to work in a team is such a vague measurement when different teams have different ways of working with each other.
By now there is more than one story how some open source developer wasn't hired because their skills with the project they created was not sufficient for the job.
The "invert a binary tree" thing is a reference to a tweet by Max Howell [1] where he complains that he didn't get hired by Google even though he wrote Homebrew, which he estimates 90% of their engineers use.
Howell describes himself as a "dick" [2], hadn't been involved with the Homebrew project for years, and has since gone on to write the NFT-based package manager Tea [3] and pkgx [4], which is an "everything app"-style CLI tool with lots of fever-dream AI art and RCE as a feature.
It's possible that Google just didn't hire him because he wasn't a good candidate.
This wasn't the only story like that. I at least remember similar stories about some kind of database / library maintainer and yet another javascript framework.
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.
Conversely, a story from the opposite end of the extreme: Fresh out of college I got an interview at a company that made games. It was exactly what I wanted to do and I made it miraculously far given the fact that I had zero real world experience. I made it to round three but ultimately got rejected. Who did they hire instead? A friend who works at the company later told me that it was down to two candidates. It was me vs the guy who wrote the game engine they make all their games in.
I do think shipping a product that has real users (and everything it entails, like writing the docs) is 100x more important than having leetcode and common interview tactics fresh on your mind.
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.
Never mind that a lot of the jobs that ask you to do this will mostly involve the conversion of database data to JSON or HTML with a few steps of business logic in between.
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.
> I do think shipping a product that has real users (and everything it entails, like writing the docs) is 100x more important than having leetcode and common interview tactics fresh on your mind.
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!"
It would be interesting to get a perspective of how many developers are in these types of roles if you are closer to them than most? My experience definitely aligns with interviews with leet code questions being unrelated to the daily work. From this perspective, it seems that those dealing with these core projects like Go or Chrome have an outweighed impact on others. Eg, it only takes a few people solving those problems to help everyone. Where as from my perspective, loads of businesses need web apps, fairly simple backends, mobile apps etc for their very specific use case where they want to control the whole user experience.
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.
> 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.
If it's a failure to demonstrate a basic skill that are relevant to the job, then yes, that's entitled. However what was described is much closer to irrelevant trivia. I don't think it's entitled to resent such things being the deciding factor.
> 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.
> 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.
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 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.
Yeah absolutely. I worked at a startup awhile ago with a really incredible designer. She insisted that everyone in the company sit in on one or two user interview sessions she had organised with our potential users. It was an incredibly eye-opening experience, and I can't recommend it highly enough.
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.
Well my comment wasn’t really on usability or UX per se, just noting that the narrative of needing race car drivers is inaccurate. You don’t need to reverse B-trees to program normal software.
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.
leetcode seems to agree with your definition [0]. the meme isn't to say that inverting a binary tree is particularly difficult - anyone familiar with coding challenges and trees could trivially produce a solution. the meme is more pointing out how ludicrous it is that senior/staff/principal interviews can hinge on these types of problems, despite the engineer proving their proficiency by doing something like running DOOM in typescript types or writing homebrew [1].
I think those challenges (especially leetcode) are heavily misused.
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.
I agree with this. I got to experience both sides when I interviewed at FB/Meta. I practiced the leetcode and Cracking the Code Interview stuff of course and one of my interviewers asked something like that. I guess it was insulting and pointless but whatever - I just did it.
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.
Our technical questions typically stay within the realm of the position we are hiring for, so technical usually revolves around “would you use X or Y in this scenario? Why?”
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.
> If you aren't evaluating based on conditions like those, I don't really see the value of coding questions.
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.
This is absolutely the way. My interviews are conversations with someone that I want to work closely with, and while leet code might be an interesting lunch conversation it’s not going to be part of any of our day to day work (c/c++/swift/obj-c)
Maybe the catch was in saying that left right labels are arbitrary, could be called node1 and node2 as well, inverting is not necessary per se, just visit it in node2, node1 order if needs to be flipped - ie. no physical rearrangement is necessary.
Also the best answer to "how do you reverse an array". You don't. You just read it in the opposite order. Especially in any iterator-based language it should be trivial.
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".
I can't remember the last time I reversed an array. Honestly it's at least a code smell. Why can't your code just read it in the other direction? Or have it in the correct order in the first place (e.g., sort it correctly instead of sorting it backwards and then reversing it). It's not that hard, even in a C-style for loop language.
Because usually the code to handle it is not mine and it expects to go through the list in forward order. Nobody makes APIs that take a list of, idk, files to delete and lets you pass in a parameter that is “please actually run your for loop over this in reverse”. They expect you to flip your array before you hand it in.
Depends on how you look at it, I guess. A binary tree has a couple of properties. Usually there is some ordering on the type. Something like: the element on the left is smaller than the element on the right. (e_L < e_R). Invert would be than turning the ordering into e_R > e_L. I guess this is the left and right branches exchange answer.
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.
That's what it means, and people use it as an example not because it's like, some sort of super difficult unreasonable challenge, but because it's completely unrelated to the work you'd be doing on the job like 99.99% of the time. It's like interviewing for a line cook and asking them to make a spatula.
I’m 100% sure that if he was being considered for a domain expert role in some domain related to this (e.g. TypeScript) his score in a typical whiteboard interview wouldn’t have been a deciding factor whatsoever. This is a standard hiring track even in big tech. Sometimes you’ll even be exempt from these interviews altogether.
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?
As someone who has been on the hiring manager side, I'll state the obvious: because it demonstrates insanely good problem-solving skills that would transfer to nearly any challenge.
Unfortunately I feel like recruiters at larger companies are squinting at CVs and think like: "Open source? Entrepreneur? Eh, oh. Smell of despair and discarded pizza boxes.".
Of course unless your passion project is very successful one, but majority of them are not.
While I agree with the sentiment you are delivering, I think successful is probably the wrong word here.
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.
The justification is that it's almost impossible to get "good employee" signal any other way. If you tell people upfront that you're testing them on leetcode you at least get some signal that 1) they're willing to put in time and follow through on studying for something 2) they have some base level of programming skill and intelligence
Companies optimize hiring for avoiding false positives (bad hire) over false negatives (bad rejection), especially in this job market.
Given his skills, he'll be able to pass the usual coding interviews with some preparation. In most companies, the bar isn't that high, they're just there to ensure that candidates have some minimal (usually undergraduate) algorithmic knowledge, and is able to interact with the interviewer (communicate their ideas, act on hints and so on...).
I suspect the technical interview devolves into an act of shunting the blame of potential bad hires away at some places. Elite credentials and leetcode shibboleths serve the same purpose: this person has checked the boxes we've agreed upon as important in the hiring process, regardless of the job duties. If they turn out to be a bad hire, who could've known, esp. with that Ivy League bachelor's degree?
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.
>shibboleth
Fantastic word right there, had to look it up.
That's exactly how I'd describe the hiring process these days. Relevant expertise seems like its only seen as a bonus. That or I'm interviewing at some terrible companies.
The role of such standardized coding interviews is to ensure consistency when hiring at very large scale. Some big tech companies hire thousands of people a year, and interview ten times that.
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.
I think, nowadays, I can get a generative AI to tell anyone how the process of inverting a binary tree works, and perhaps even give sample code for it.
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.
> "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."
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.
> 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."
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.
> 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.
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.
Yeah that’s obvious and probably good. You’re trying to make a machine that reliably adds employees to your company in a way that minimizes nepotism or corruption.
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.
I hope he learned something useful while doing it and it seems like he did, because, although regarding all the comments here I'll likely be alone in my assessment, I just see a massive waste of time & effort? He described it as "a brutal year-long journey of 18 hour days" and he didn't bootstrap a company, he wrote Doom in Typescript types...?! The "epic" doom music underlying his story just makes it seem even more comical to me.
Maybe it's just me, don't want to crash the party. Carry on
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.
It's just you. It's extremely impressive. He likely set himself up for life with this + learned an unbelievable amount. And this is, in and of itself, a business. He has merch, a conference, a social media presence, etc.
I guess you have to ask yourself, what truely gives value in life? The answer is that value is subjective, and this person is wasting his time no less or more than you or I.
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.
imagine how amazing it would be if every major browser tomorrow suddenly dropped support for JS entirely and said that they only run typescript now. It will be a hard but absolutely mind blowing transition
What would be the point? Why waste time parsing and ignoring types? Types are for static analysis during comp time, they have nothing to do with the runtime and they don't provide "type hints" to the runtime about types, and code isn't optimized based on static typing analysis. Or should the browser do that? In that case which version of TypeScript? And by version I actually mean which tsconfig? Sorry for being picky but can't image why we would want something like that. If all we wanted was a compiled runtime like flash/actionscript was then I wonder why we killed flash
it would get rid of babel immediately and the billions of hours of transpile time spent across the planet by people converting ts into js. You ll be able to run ts natively without transpilation across every major browser
Typescript is for me one of the most overengineered programming languages. Why did JS not follow the way python and php did? Integrate types in the main language but make it optional.
When typescript came out, you were seen as weird for wanting such a thing. I once had a VP of engineering dm me to tell me to stop discussing typescript in the company dev channel around 2015 (if you're reading this, that was a dick move). Nowadays you're kinda odd man out if you don't want types. So the idea of adding types even optional ones probably wouldn't have gone down well. The closest we ever came was es4 which of course never landed: https://evertpot.com/ecmascript-4-the-missing-version/
I wonder if there will come a time when the HN audience will stop being amazed that some system is Turing complete, or that any Turing-complete system can run Doom (barring resource constraints). Maybe I’ve just seen it too often. The fact that TypeScript’s type system is Turing-complete was shown back in 2017 [0], and then of course you can run Doom on it.
There’s a difference between a _system_ being Turing complete and something actually _using_ that Turing-completeness to make something arbitrary run on it. You can’t deny this is an impressive effort.
It’s a considerable amount of work for sure, but that alone doesn’t make it impressive. Maybe there were particularly difficult hurdles to overcome that were solved in novel ways? But I don’t see such noteworthy aspects being mentioned in this thread, and it’s not evident at all that there should be any.
Is this your reaction when someone climbs a mountain? "Bipedal locomotion was shown sufficient for climbing mountains centuries ago, given reasonable assumptions about the terrain, why should I be impressed?"
Doing things can be difficult and admirable, even if it was confidently believed possible beforehand.
> Is this your reaction when someone climbs a mountain?
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.
We know that humans are capable of writing amazing symphonies or running a 2h marathon, so there’s no point in doing it?
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.
To be fair, this is graphical, but it's not real-time, not performant, and while it technically takes input, it'll be a while before you see it reflected in the output.
> "It was a brutal year long journey of 18 hour days" [to run doom in TypeScript types]
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.
I don't thinks statements like this are meant to be read literally in American English.
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.
> I don't thinks statements like this are meant to be read literally in American English.
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.
This happened to me once. It was like attaining enlightenment. My company worked with a F100 that had, as a core piece of their business, a piece of software they'd commissioned in the 80s that they still used in the 2010s to make billion dollar decisions. But no one knew how it made the calculations they relied on. This was before attorneys knew to include source code in procurement, the original devs at a third party code shop was long gone.
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.
Imagine if every human had the resource security to do this for a good portion of their lives. Star Trek was fiction but we could have that if a few of us humans weren’t so greedy!
Virtually everyone living in a developed country has resource security to do this. Even in America, with its relatively poor levels of social assistance, you could live off of the dole as long as your expectations on quality of life are low.
Turns out, in the real world, people like having nice things, hanging out with family and friends, travel occasionally, etc. instead of just entering flow state to solve problems! It has nothing to do with income inequality.
People have to be comfortable to be as creative as the OP comment, so while I agree in principle, I think it's going to be harder than you imagine to build amazing things when you're living below the poverty line. The anxiety and mental anguish alone could cripple a person, even someone that isn't in the worst situations.
hi! author here! it's a pipedream, I know, but it's a hope/goal of mine to, in the next video (the "why did you do this" video) to give some fuel/motivation to people that might be feeling like you describe. do you have any advice for me for what I can say in the upcoming video to someone that might not be as comfortable, as you say. I really do have a grasp for how hard what you're talking about is, and I've tried over my life (sometimes very hard, sometimes too hard) to help people I know to overcome it (sometimes successfully, sometimes not). When you're in survival mode every day, you might look at a project like this Doom one and go "yeah right! not in a million years could I do that with my current set of things weighing me down!". anyway, don't want to ramble, but if you (or anyone else reading) has any wisdom to share on how to talk about these things in a way that's effective or inspirational for people, I'd really love to learn.
I have no advice because I’m still kinda in the bad place but I think it just takes one thing you can focus on that you enjoy and sometimes you can slowly dig out of the hole. I’ve started woodworking and the joy I get finishing a project has helped to push me forward. Just talk from the heart and you’ll make a good video I’m sure.
Good luck, your project is very impressive and I hope you are able to continue to make cool stuff!
thanks! actually the "why" video is going to talk at some length about my woodworking business, so you might enjoy that part! best of luck to you!
I really don’t think this is generally true. Assuming you’re single with no children, there’s effectively no cash assistance available where I live. You might be able to get public housing and food welfare (SNAP), but you would have effectively zero income. You could live on savings for a while, but that’s obviously not “the dole”
I think both of you are correct:
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.
That's correct. Hyperbole and dramatization of real events was entirely unknown to the world until it was invented in a rural Nebraskan town in 1854 (pre-statehood). It's been a staple of American speech ever since. Only recently has it begun to find a footing outside of the United States. It's a similar story with Comedy, as well.
I never said it was only in American speech, just that it's very, very common, to the point where a lot of what Americans said made less sense to me until I realised it.
Different cultures express things differently. Overstating, understating, etc etc. If you want to understand, and be understood, it's important to know.
The does video starts off with some serious hyperbole (noted for anyone reading this comment before watching the video)
So much hyperbole that I thought the entire video was a spoof on the practice of making a Doom proof until about a minute in, where I asked aloud to an empty room, "Wait, this is real?"
Also, he forgot to credit the video itself, which has a really high production value! Kudos all around!
I work with Americans and never experienced this from any of them - are you sure you're not... exaggerating?
I think you are confusing hyperbole with poetic license, and overstating the effects it has on English vernacular. I am not American, but I wouldn't go around minimizing how industrious the "great society" is.
Yeah I worked out the "N days without sleep" was mostly rubbish too.
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.
From experience, be careful if you ever called them out, just let them be.
> year long journey of 18 hour days
I couldn't do it, even if I had the talent. I have to work to get money!
At 18 hours of work a day, your money need are relatively low! Pair that with just sleeping at the office toilet and eating used coffee grounds and everything should be good!
Living is cheap if you don't live.
Not to detract from the achievement, that's amazing. Mostly useless, but amazing nonetheless.
the low(er) cost of living here in Michigan is absolutely a factor of the story! haha.
You are a bad trader
We already new that TS types are Turing complete so it's more of demonstration than a proof.
He wasn't being serious.
[flagged]
what's with hn being filled with assholes lately?
The amount of “why would somebody waste their time with this” comments is pretty surprising.
This guy is a legend now. Every developer slack channel at my company is buzzing about it
It's happened in the last couple of months, a clear uptick in aggressive comments. I'd hazard a guess at people using HN as an outlet for feeling angry and helpless about the US political situation.
It's obviously for the person who did it.
The video will probably do pretty well, giving him some personal traction for his channel or reputation. Also because hackers gonna hack.
He wanted to do it. Didn't hurt anyone. Why criticize?
Pushing the frontier is an end unto itself. The pure excess of this endeavor is a huge feat, and I for one am happy to enjoy just witnessing it.
"But I'm not one of those fancy 10x developers. Instead of a master of craftsmanship, I'm more a master of close-enough-manship"
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 love that there was a moment when I realized that all these things where I could’t understand how someone could possibly figure out a trick to create them didn’t use any trick at all. It was instead just mountains of hard work.
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.
One of the things I like to mention to younger devs, when I pull out a solution that they think is from thin air, is that I have failed far more often then they have. I just have a good memory on how to fix my mistakes.
Those are the unicorns
society create the überman myth to keep the working class down, thinking they will never be the top of their game. the ones doing the hiring know that those putting in 18hrs a day are the unicorns, i.e. the best they can hope to find.
I was accidentally one of these once.
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!
People usually don't see the history of these kind of systems.
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.
I’m close to one of these types and I get taken advantage of a lot and desperately wish I could turn it off. It presents in weird ways that are hard to navigate politically - often I will end up on a team and be outputting a large majority of the work, people/egos get hurt or threatened, still inevitably make the same anyway. It's never really led to any kind of career or financial success I'd have thought it would have years ago.
You are halfway there my friend. The other half is tactful self promotion. Make sure your skip levels see what you’re doing. Do a little less for your team and a little more for other teams and make sure their leads know you’re helping. Become the legend you can and it will result in much success. Output is only half the picture.
This is something I've witnessed first hand for years, and heard for others too. I tried to be smarter politically but it's eating my brain. Wasted brain power for petty anthropological issues. I bet the solution is to be surrounded by quality people but it seems rare. Also negative people will do wonder to paint anything you do as a problem until they're able to do the same.
It can depend on your manager and the growth state of company. I don’t think I get take advantage of, but I’m very productive and have been rewarded for it.
> society create the überman myth to keep the working class down, thinking they will never be the top of their game
What? The distribution of talent and grit being what it is, ubermen do exist. Some people are naturally tall, good-looking, able to recite pi to the 50th digit, solve challenging analytical problems, put in long hours when necessary, and get along with the in-laws.
Of course, the ones doing the hiring probably know that such people won't stay in the position for long. But it's not a myth, and certainly not one to keep anyone down.
I can also relate - I'm a tech lead, and it just also happens to be I find programming to be an enjoyable puzzle. When my wife sticks on some TV, I'll usually scratch an itch with some problem I've spotted, or some improvement that can be made - most of our docker build time improvements are me trying out different things and finding what works - same with little QoL features.
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.
Surely it’s a balance but I feel like relentless drive and focus might even be a little more important than raw intellectual ability.
> and he also says "It was a brutal year long journey of 18 hour days"
Which is likely an hyperbole.
But is it technically untrue if the start date and the end date are more than twelve months apart and some of the days between those dates saw 18 hours of work on the project? Arguably it could be both, not technically a lie but hyperbole nonetheless ("37h split between two days a year apart").
I agree with you, and with the comment but.. Come on, this guy is not THAT type of guy
Yeah I relate to this too. I often head into something not knowing what to do, taking the naive approach, realizing there's some patterns I can tool out and simplify, and refine my process. Basically just chewing through the problem. Frankly I've never met a project I couldn't finish. Since I'm not really that talented, it's the thing that gives me the confidence to tackle something.
[dead]
A WASM runtime in TypeScript types is impressive in its own right, but I think I can dimly see how it could work with a lot of effort. https://github.com/MichiganTypeScript/typescript-types-only-...
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…??
(author here) pause on that screen and look at the code displayed on the right (as well as the note at the bottom!) the way to do keyboard inputs is basically exactly what people do for tool assisted speedrunners. Some people at this point in the message just went "oh cool!" and others went "you liar! that's not the same thing!". There was SO MUCH to say in 7 minutes in a short video like that, but rest assured, I'll go into depth on that in the next videos. The pong stuff that's shown is real (only the animating part was the creative liberty) and it's in the open source codebase.
I haven't checked the DOOM one, but for the Pong example, the keyboard input is prerecorded. As in the sequence of the keyboard key press are sequenced in a TS array[0].
[0]: https://github.com/MichiganTypeScript/typescript-types-only-...
yep! exactly this! like how a tool assisted speedrunner works
That's also how the Doom demos worked right? :D
If I had to guess, it's a file with an array of keys pressed (or unpressed) at some time interval (say 0.1 seconds). Then a VS code extension can append to the array every 0.1 second along with any key-press states at that time. The compiler updates the game state whenever this array gets updated.
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.
If I heard him correctly he stated that it takes A LOT to just render a single frame. It's not playable. It can run DOOM, but you can't actually play it.
"A lot" is an understatement, rendering the screen at ~320p took 12 days.
Blew my mind! Dimitri talks about it in the video but I love the mention of how this project came to be[0]:
> This engine was built to service a project that aimed to demonstrate why Doom can't run in TypeScript types. Well. The funny thing is.. It can.
[0]: https://github.com/MichiganTypeScript/typescript-types-only-...
What was the argument for why it couldn't?
Because we lack an infinite tape and infinite time, not everything that is Turing complete can run DOOM
Or more specifically, everything that is Turing complete can run DOOM, but most languages are only Turing complete under certain assumptions which are not met in practice
> not everything that is Turing complete can run DOOM
Beware with such blanket statements, you might inspire someone to do 18-hour days for a year to prove you wrong.
Not having infinite tape is true for all computers though. And probably also not infinite time as well.
He tried and tried and tried to find one and accidentally proved instead that it could.
I got to watch Dimitri posting internal updates about his progress on this, and it has been utterly mindblowing. This is genuinely one of the most amazing things I've ever seen done with code. Absolutely legendary feat! (And also an incredible amount of persistence.)
Where can we see these updates?
the #doom channel is where Mark is referring to. it's all there!
Michigan Typescript has an active discord: https://discord.com/invite/DHtwNDTwrR
I am at the same time both amazed and utterly unsurprised that this was possible, given all the hullaballoo about TypeScript's type system being Turing complete. Having the grit to actually go through with it though? Bravo.
I have seen papers saying at least Java and Python type systems are turing complete. I wouldn't surprised if all type systems are turing complete
No, good language designers take care that their type system is not Turing complete.
Is there a mainstream language where this still holds true?
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.
pretty sure the C type system is not turing complete, but that doesn't necessarily make it superior
If there's one top story HN deserves today, it has to be this. Absolutely insane and incredibly inspirational.
My literal LOL of the month. Love the types scale graphics/animation. :mind-blown:
Doom compiled to just 177 TB (terabytes) of TypeScript types. Amazing on many levels.
This must be the quintessential example of a Turing tarpit.
In TypeScript types, everything is possible, but nothing of interest is easy.
Amazingly inefficient. But I would not be able to reproduce this feat so hats off.
I mean it’s a very efficient implementation of the inefficiency.
For the first frame...
I think that 177 TB is for the whole shebang, it's just that it took 12 days to render the first frame.
both this and parent comment are right! once you have the first frame, it's probably just a few hundred more megabytes to get the second one - although I won't be the one to find out! 1 is enough for for me!
At this point the easiest way to know if a system is Turing complete is to check if someone has ported DOOM to it haha
Very impressive!
Only if the church-turing-carmack thesis holds, which I personally doubt
Alternatively if The Romero Hypothesis is proven to map the distribution of Mancubus numbers ... >_<
If it holds does that confirm that I’m his bitch?
HN Pedantism never fails to elicit a chuckle from me
Most people would agree that Mengelberg‘s 1984 paper clearly answers that question … of course, we all know that his language is famously hard to parse!
https://github.com/desi-ivanov/ts-lambda-calc
Not only is Dimitri an amazing engineer - he's also great at building community and event/video production. Michigan Typescript meetups and videos have a level of polish that goes over and above
In the YouTube comments he stated nonetheless that he still bombed big tech interviews, specifically the technical portion, probably because of some ridiculous LeetCode problem he did not memorize beforehand. It just goes to show how these procedures do not effectively determine who is actually a good engineer or programmer. If this guy can't land a job while achieving this, then something is not quite right with the interview process.
hi! yep! this definitely happened. I do mention it in the next "why" video, but it's good feedback to know this is interesting to people because I could say a bit more about what those rejections were like - specifically the one where I failed the technical screening.
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.
What you've accomplished demonstrates a very important skill you have, persistence. Kudos and don't give up.
About those rejections, did they effect your confidence in yourself and your skills? How did they make you feel?
I was crushed and embarrassed. Yep. Not even gonna lie.
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.
You have coding skills. Some marketing and video production skills. Self discipline and persistence. The time to spend 18hr days on a project. Why look for employment? Start your own business.
are you some kind of fortune teller!? haha. so that's so funny you say that because that, too, is a big part of the story. actually I was gearing up to do exactly that - but everything blew up in my face and this Doom project was, in many ways, my way of picking up the pieces from the rubble.
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).
[dead]
Those interviews select for the type of person that believe it is worthwhile to dump tons of time into studying minutia to succeed at those types of interviews.
The purpose of a system is what it does, after all.
You're making an excellent case for using AI during the interview. If you can actually code and do the work, you're hurting no one by using tools to get past these arbitrary barriers during the live interview. The system is clearly flawed when someone demonstrably skilled gets rejected over trivia.
I actually created a tool to help myself get through the live interviews, specifically by listening to the questions and giving me real time answers to things I couldn't recall under that kind of pressure. It's not about not knowing the material, it's about the ridiculous expectation to perform perfectly on demand.
[dead]
OTOH he points out that he learnt an enormous amount during this project specifically, so probably much more employable now.
That's pretty insane Dimitri. If you like stuff like this I really recommend Dimitri's TypeScript challenges series: https://www.youtube.com/playlist?list=PLOlZuxYbPik180vcJfsAM...
This shouldn’t be possible.. Typescript devs have lost their collective minds and I’m totally here for it.
Edit : TS not front end
I didn't ask them outright, but I sorta think the TypeScript team might agree with you on this point! haha. At least we can all agree it's not an intended use-case, to play Doom.
Counterpoint, it absolutely should be (barring the pedanticness of modding it a bit): https://news.ycombinator.com/item?id=37555651
Nothing will ever top this for typescript types. This is the pinnacle. An entire virtual machine and system memory with garbage collector in types.
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.
Well we haven't implemented a web browser capable of running javascript in the typescript type system yet.
Quick, someone tell this author it's not possible.
Doom is Turing complete (https://calabi-yau.space/blog/doom.html), so it's just a matter of building the appropriate map.
(author here) _yes I realize how ridiculous what I'm about to say is considering the project I just shared_ but I actually strongly disagree, haahah. there's this thing I learned of called "the turing tarpit". my position is that just because something could theoretically be done with infinite time and infinite resources, doesn't mean you can even approach the throne of doing it for real in a human lifetime.
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.
Of course you're right, and I should have put quotes around "just". It would be amusing to calculate how long it would take to render the Google home page via Doom via TypeScript; I'd guess much longer than the age of the universe.
Off topic, but as an obsessive debugger and experimenter with ADHD and someone who hates telling people lies about what can and can't be done your motivation speaks to my soul. But my usual rabbit holes last just few hours up to few days. And even those that go far (that avoided all obstacles) end up right before implementing the last step, when it becomes obvious to me that this thing can be done. Congrats on the sheer stamina.
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.
> 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 hope this doesn't come off wrong like but honestly - but the outcome on this project doesn't change my view one bit. it didn't make me dig in my heels either, but I strongly doubt it's possible in a human lifetime to do this with at least some of the other languages that have type systems that are considered Turing complete.
That's not really relevant. Turing complete languages are used to build Doom and Pong, but one is more impressive than the other.
Pong was (originally) built using transistor-transistor logic on a circuit board. AFAIK it did not involve any software at all.
It looks like they built a WASM runtime in the TS type system. Implement some more OS calls and you should be able to get a browser running. And then WASM on WASM on TS types. Lol
I for one would like to see TypeScript's type inference be self-hosted
You're in luck! https://github.com/ronami/HypeScript
Not unless someone ports typescript to typescript types. That would be some next-level self-hosting haha
The first compiler that can play it on real time will be deemed the pinnacle for TS compilers.
Wow.
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?
I don't think it's actually playing audio or loading files. The required game data (.WAD) was presumably pre-transformed into the encoding that the virtual machine uses for data and passed to the program as type-level "input".
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.
no audio - correct. technically, in a certain sense, the first frame will contain only one sample of audio, and I did consider that, but a single impulse is the definition of "juice wasn't worth the squeeze", haha.
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!
At 17TB, trillions of types, and a year of 18h days my guess is he got very creative.
*177TB, according to the video.
Generative Programming[0] FTW!
0 - https://en.wikipedia.org/wiki/Automatic_programming#Generati...
A WASM VM is just “some calculations,” really.
Can someone help direct me toward an understanding of what it means for something to be "run in/by TypeScript types"?
A short explanation or link to a resource would really be helpful. :)
Normally you would write a program that is a game of Doom when you run it (you create a program, then compile it and run). Dmitri created a program that does nothing and he don't even run it. But while it's compiling, it does a lot of tricky things to make typescript compiler to run Doom as a side effect.
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).
TypeScript types are a kind of Prolog [1] (sort of, kind of, not entirely). Like any language they have primitives (`boolean`, `string`, `true`, 'Manchester'), functions (`type WaitWhat<T> = { yesReally: T }`), variables (`type X = number;`), and conditionals (`type Huh<T> = T extends Foo ? Bar : Baz`). You run the types program by asking `tsc` to check the types of some program - e. g. `type Foo<T extends number> = { x: T }; type Bar = Foo<string>;`. Getting output out of the type system other than via "hover over the type in VSCode" is probably a bit more involved, but it's definitely doable (I suspect some abuse of the Language Server Protocol here).
[1]: https://en.wikipedia.org/wiki/Prolog
It might be helpful to look at something like Typescript Tic Tac Toe in the type system [1]. You can comment out individual lines in the GameLoop type, and then hover over `____________DISPLAY___________` to see the current game state. Illegal moves will result in type errors.
Running Doom in the type system effectively means a lot more types have been generated (effectively a C to typescript-type compiler was created if I understood this correctly), then the game was started with no inputs entered. Theoretically if the author had infinite time and compute resources, the history of control inputs up to a certain point in play could be put in a tuple, and the type system would generate the state of the game given the code and the moves which the user had input so far. This state would include what's on the screen, but also internal state variables controlling things like where the enemies were moving, whether projectiles are in air, their direction, collision detection, etc.
[1]: https://tsplay.dev/wE95vw
Hats off to the creator big way.
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)
WOW that's quite kind of you to say!
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!).
I wonder if there are any small changes/improvements to TS that would make this orders-of-magnitude more efficient to run? It would be fun to go implement some random TS feature with the secret sneaky goal of making it run Wasm better.
Arithmetics were apparently integrated into TypeScript types for that exact reason:
https://note89.github.io/typescript-typelevel-tic-tac-toe/
I wonder if with 177TB you could implement DOOM in a regex ... (plz don't try unless you want to be on top page of hackernews in a year!)
Typescript's type system is Turing Complete (at least it was for 2.2) [0].
Regexes fundamentally can't do that [1].
[0] https://github.com/Microsoft/TypeScript/issues/14833
[1] https://en.wikipedia.org/wiki/Turing_completeness
A strict theoretical regex yes, but a lot of regex implementations in practice are not strict NFA/DFAs and may indeed be turing complete
I think GP meant PCREs when they said regex. Ar at least the subset of them that doesn't embed perl code.
To be clear, it's running in TypeScript types only -- not JavaScript. Absolutely insane
I had once built a type checker for a query language within the TypeScript type system, I thought I have reached the limits. Actually showed it to the TS team and they felt the same. This is like something my mind could never had even swallowed, let alone be able to ever build! Nice job!
Your only miss is that you should be selling that "Types" Doom themed shirt.
Here you are: https://shop.squiggle.tools/
Ty!
Amazing work. I'm interested in the choice of WASM - presumably any target that can run DOOM could've been used? Of which there are innumerable choices I assume. Was it for symbolic reasons or genuinely the most useful target?
love this feedback - will definitely talk about it in the next 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
Ah nice! Well, hats off this is really impressive. As other commenters mentioned the extent to which it's documented and the restricted scope probably helped.
exactly! knowing what I know now, actually WebAssembly was probably just about the best thing I could have accidentally picked!
WASM is one of the easier platforms to port as the Virtual Machine is well documented and there are actual implementations in many languages that can be used for debugging and comparing the results.
even in pure JS: https://github.com/evanw/polywasm
WASM is the easiest target because you don't have to emulate an entire computer.
But in this case he kind of did anyway (at least the video makes reference to "L1 Instructions Cache").
But that's all CPU -- he doesn't have to emulate the rest of the computer (video card, IO systems, etc). You provide WASM with your own interface to the outside world.
(not arguing, really just want to hear your thoughts to this!) so re: video card - but I did write what I don't know what else to call other than "a graphics driver" (i.e. it takes Doom palette pixel values and converts them to something the user sees on their screen with ASCII art). what else would you call that? or are you saying video card would have to be at the level of VSCode or my operating system that actually lights up physical pixels on my screen.
If instead of WASM you decided to emulate a different DOOM target like a PC then you'd have to emulate the actual VGA graphics hardware and enough of the other PC hardware to run the game. That level of emulation is a difficult project on it's own.
got it, ok sweet. thank you so much for explaining. I don't know a ton about these programming circles, so I don't want to say the wrong thing if I can avoid it. Sounds like you're saying that no WASM runtime is, in this sense, qualifying - which makes sense!
Brilliant. The TS type system is a true marvel of modern software engineering. Its a shame that it hasn't just been developed into a proper fully fledged runtime at this point. Something like Deno is the closest we'll get it seems.
It is not a mark of quality, quite the opposite.
hi! author here! selfishly, it'd be really useful to me if you could take a moment to elaborate on your thinking here. it's not an altogether-too-too-uncommon viewpoint and I'd like to understand it if you have a chance.
Throughout the video and while appreciating this unbelievable feat I kept thinking "how could someone have the motivation necessary to tackle such an insurmountable undertaking" ?
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.
Out of curiosity, could the learnings/toolings from this project have real improvements to more "practical" TypeScript?
yes! I completely skipped over it in the video for time, but the performance benchmarking tooling I had to make to is something everyone can benefit from, and I'm excited to find someone that sees how big it'd be for the TypeScript world if we can extract some of that (I'll need help!!)
I work with a couple type-dense libraries: Elysia and Kysely. Kysely holds up remarkably well. Elysia... Well...
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
Microsoft Solitaire is apparently the most installed program.
Doom must be the most ported.
Try to fit that in a context window! Absolutely amazing.
(author here) that was one of the 1st-week "ok, but THAT'S surely a good reason this can't work..." until I dug in and (to my great surprise) found a way.
Plus three months of recording/cutting/editing the video. Well done.
The video is very impressive by itself. This guy is a perfectionist
This is mind-blowing! I knew TypeScript's type system was Turing complete, but seeing it actually run DOOM is another level. The sheer creativity and engineering behind this make me wonder—what are some other extreme use cases where people have pushed TypeScript's type system to its limits?
It should have been obvious this was achievable once you realize that a monad is merely a monoid in the category of endofunctors!
The next challenge could be making TypeScript types run an LLM. I wonder how their performance would compare to that of Excel sheets.
I wish tsc didn't take eternity to run though.
now we have a benchmark
The subtle Devin Townsend references in the video were a super nice touch, Dimitri is literally a Power Nerd.
I don't have any tattoos, but if I did, it would most definitely be of the world's ultimate cup of coffee!
Bad Apple time!
Bad Apple would probably be trivial considering the work he did.
What the FUCK
Related: MichiganTypeScript: A WebAssembly runtime implemented in TypeScript types - https://github.com/MichiganTypeScript/typescript-types-only-...
(via https://news.ycombinator.com/item?id=43185174, but we merged that thread hither)
I hope the TypeScript team at Microsoft sees this and goes: "What have we done! We have created a monster... we need to tame and simplify this beast. Or at the very least stop adding more features."
This is top bloat and reminds me of the fever-dreams as a child with walls and walls of senseless work… impressive but also sad somehow.
I can’t agree enough. It’s sort of like those massive paintings recreated in CSS. They are a neat achievement, yet sort of reveals a vast emptiness that exists within the author.
There is no real indication of a "vast emptiness", he's just a plain old hard worker
About time some good news!
Incredibly good video editing, unbridled insantiy, cheers!
conservatively 200 hours dropped into that 7 minute video - so you can imagine how happy I am to hear people are enjoying it!
A Turing complete[0] language can do just about anything any other Turing complete[0] language can do, even if the language used is a language's own type system.
Mad respect for the author. This is a non-trivial achievement indeed.
Bravo!
0 - https://en.wikipedia.org/wiki/Turing_completeness
As someone that's unfamiliar with typescript, can someone explain exactly what was accomplished here?
What are the minimum system requirements in order to run this at 30fps?
it was done on an 13900k system with 128gb ram. I bet the performance would be very different on other systems. and by my calculations the next frame would only take like maybe an hour or so to render. so that means that actually, hilariously, if anyone wanted to really dig in and make the engine faster - which I suspect it can be done by multiple orders of magnitude, truly - then actually I'd say 30fps types-only-doom is possible in the next maybe year or two. the TAS-style keyboard controls will work, but one problem is definitely going to be "how do you refresh a screen" which is a problem I didn't attempt to tackle other than to say you could (with what I already built) just hover your mouse over another type that contains the information for frame 2.
Fascinating. Just for fun, comparable compute (by cpumarks) to your 13900k for 30 fps would be 39,600+ 96-core AMD EPYC 9655Ps. Bravo on the project success!
you know what's funny, I also have a threadripper rig (which is my main development rig) and it ran _slower_ than on the 13900k. Like. by a lot. and while that surprised me at first, it's makes a lot of sense because this is Node.js in the end (i.e. the TypeScript typechecker runs within Node.js) and that means it's single threaded. So single-threaded perf is all that matters.
i envy dimitri's ambition and capabilities. i want to be able to dedicate that much effort and more into something I'm passionate about. mostly personal discipline/skill issues but MAJOR props to dimitri and this awesome project.
If you decide to have kids that’s a great long term project.
I'm glad you said this actually, because I had a section in the "why" video where I tried to compare this project to how I've felt having kids and cut it out because it was too cheesy. maybe I'll bring it back!
Please do.
I'm crying of laughter, it's magnificent
The big question is, would the author lose interest if they were working on something mission critical?
Is that really the big question? Why is it necessary to find another dimension along which to diminish the author?
I'm not diminishing them, I am in awe of their work, I'm just pointing out that sometimes people (including myself) focus on esoteric projects that might have some learning opportunities, but don't directly solve a real problem (and might just be psychological mechanisms).
hi! author here! it's taken me many years to be able to self reflect enough to produce these next few words, but the answer is I have learned about myself that I perform better under pressure. I'm more consistent, reliable, and make better decisions when it's go-time. so I guess the answer to your question _should_ be yes.
although.. I've noticed I have other flaws that have burned me many times in responding to incidents. Oh well. The one I've been working on for years is "when the system is down, check the status page of the upstream provider first because it might not be your fault". I always assume it's my fault for way longer than I should.
Stop this madness!
This was the best thing I saw all day
Apparently, this guy tried to apply to BigTech to get a job but was rejected.
> "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 ??
This is amazing!
"Man demonstrates Turing completeness of TypeScript in the most extreme manner possible."
Insane.
Honestly every time I worked on TypeScript codebase and the type definition "any" started popping out more and more often, I felt I'm starring into the abyss.
There are valid use cases for any (such as type constraints).
Playground with example here: https://tinyurl.com/5ahs366a
Seems to also work without any:
Sure, there's many other ways to type it, but none adds any kind of additional safety or strictness over Record<any, any> which was my point that `any` is the correct type in many cases, except when it widens a type.
But in my case it's not widening anything, in Record<A, B>, 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.
> it's just a set of all possible types
`unknown` is the set of all possible types (it's the top type[0]). `any` goes beyond that—it basically turns off the type checker[1][2].
[0]: https://en.wikipedia.org/wiki/Top_type
[1]: https://tsplay.dev/mA9vXm
[2]: https://www.typescriptlang.org/docs/handbook/2/everyday-type...
It's a "null" and "undefined" discussion all over, but now with transpiler.
Your 1 isn't equivalent to my example, line 11 is not constraining the type.
I know it's not equivalent, it was just an example to show what `any` does (and that it's more than "just a set of all possible types").
The `T extends Record<any, any>` on line 11 is a type parameter constraint though. Are you referring to something else when you say "constraining the type"?
It works differently based on where those anys are and what that Record<any, any> refers to due to type variance.
'any' has always been intended as an escape hatch, so no abuse here [1]. The type representing the set of all possible values (the top type in the type lattice) is 'unknown'.
[1] https://www.typescriptlang.org/docs/handbook/2/everyday-type...
[2] https://www.typescriptlang.org/docs/handbook/release-notes/t...
unknown is not equivalent to any as a type constraint: doesn't work.
https://www.totaltypescript.com/any-considered-harmful#type-...
The widest possible function type is `(...args: never) => unknown`. This is because parameters are contravariant, and `never` is the bottom type. Using that type works in the author's example[0].
I've got an issue open about TypeScript's provided `ReturnType` type which is somewhat related to this[1].
[0]: https://tsplay.dev/Wy0Ogm
[1]: https://github.com/microsoft/TypeScript/issues/55667
Note, the type `PropertyKey` is shorthand for `string | number | symbol` in Typescript
That was the tipping point in transition from "we are serious and use static typing instead of lame JavaScript" into "ok we lost control over this thing".
What do you mean?
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.
In your example, I'd use Record<PropertyKey, unknown> instead
People generally just give up after a while with the type system. I consider myself decent with TypeScript and you end up spending a good chuck of your time satisfying the compiler for something which is literally a one liner in plain JavaScript.
And yet it's still not possible to type tagged template literals...
https://github.com/microsoft/TypeScript/pull/49552#issuecomm...
Insane achievement nonetheless!
idk why ppl do this to themselves, likes?
I'm sorry to rain on this parade, but I fail to see the merit of spending so much effort - and writing so much code, generating so much data, working 18hr days etc. - to render Doom in TypeScript type-checker.
I mean, there all sorts of feats and achievements one could choose as one's goal, which would also be impressive, but would be more useful to users and/or software developers, than this. I'm just thinking of all of those times I wanted to suggest a software tool to someone and went "ungh, if there was only some FOSS which did that" - and there wasn't, or at least, it wasn't assebled from pieces into something usable. Then I think about spending a person-year on this and I get frustrated.
Sorry, but those are my 2 cents.
hi! author here! this doesn't rain on my parade at all! actually I really appreciate what you're saying, so thanks for saying it!
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.
Yes, but think of how much joy it brings to so many people.
Think of how much joy it would bring to people if the author would work on a piece of software which would be consistently useful beyond the one-time novelty.
Of course, it's a matter of proportion - I'm not saying that only things of utility and no "fun" stuff need ever be produced; but this is a rather extreme case.
Probably less.
mad respect! you are a legend.
it is so beautiful
The big lesson from 1936 Turing:
Anything can run DOOM...
...as long as it's Turing complete.
Is the background music the music from Batman Beyond? lol
"the only thing they fear is you" but the incredible, honest, humble, hard hard-working, Mick Gordon.
Oh haha well now I feel dumb. Of course it is! The high pitched sounds are similar to the Batman Beyond intro. I can hear the djenty riffs better now though. Sick video!
thanks!
These typescript fanatics never fail to make me feel disgusted by what they've done...
People who downvote me clearly lack any sense of humour.
it's just so hard to tell sometimes - but thank you for clarifying that you meant it in a jokey way!
Yeah of course it can it's just j...
Jesus christ.
From YT comment section:
>> @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.
He's also one of the principal organizers of SquiggleConf, a conference focused on devtools that takes place in Boston: https://2024.squiggleconf.com/about
What I'm saying is, if he still happens to be looking for a job, any employer reading this should be falling over themselves to recruit this man.
There is more to hiring than technical competence. I'm not seeing any red flags in his videos, but just saying, ability to work in a team is not obvious from such posts.
strong agree! so much of it boils down to "do you treat people good and stuff". then there's "do you treat yourself good and stuff", and then a tiny little fraction that's "can you work hard to get to an answer" and finally, least of all, "what do you know"
I think what's more important is a company's / team's ability to onboard new hires to their way of working (so what you should be testing is humility and open-mindedness). Ability to work in a team is such a vague measurement when different teams have different ways of working with each other.
[dead]
[dead]
One of the top comments in the video:
> 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."
By now there is more than one story how some open source developer wasn't hired because their skills with the project they created was not sufficient for the job.
The "invert a binary tree" thing is a reference to a tweet by Max Howell [1] where he complains that he didn't get hired by Google even though he wrote Homebrew, which he estimates 90% of their engineers use.
Howell describes himself as a "dick" [2], hadn't been involved with the Homebrew project for years, and has since gone on to write the NFT-based package manager Tea [3] and pkgx [4], which is an "everything app"-style CLI tool with lots of fever-dream AI art and RCE as a feature.
It's possible that Google just didn't hire him because he wasn't a good candidate.
[1]: https://x.com/mxcl/status/608682016205344768
[2]: https://www.quora.com/Whats-the-logic-behind-Google-rejectin...
[3]: https://tea.xyz/
[4]: https://pkgx.dev/
This wasn't the only story like that. I at least remember similar stories about some kind of database / library maintainer and yet another javascript framework.
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.
Conversely, a story from the opposite end of the extreme: Fresh out of college I got an interview at a company that made games. It was exactly what I wanted to do and I made it miraculously far given the fact that I had zero real world experience. I made it to round three but ultimately got rejected. Who did they hire instead? A friend who works at the company later told me that it was down to two candidates. It was me vs the guy who wrote the game engine they make all their games in.
Did he tell the interviewer that? Or did he just expect him to have known?
I have had maybe two interviewers ever mention anything on my GitHub, which I usually include on my application/resume.
I do think shipping a product that has real users (and everything it entails, like writing the docs) is 100x more important than having leetcode and common interview tactics fresh on your mind.
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.
Never mind that a lot of the jobs that ask you to do this will mostly involve the conversion of database data to JSON or HTML with a few steps of business logic in between.
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.
Your last bullet is a good point.
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.
> I do think shipping a product that has real users (and everything it entails, like writing the docs) is 100x more important than having leetcode and common interview tactics fresh on your mind.
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!"
It would be interesting to get a perspective of how many developers are in these types of roles if you are closer to them than most? My experience definitely aligns with interviews with leet code questions being unrelated to the daily work. From this perspective, it seems that those dealing with these core projects like Go or Chrome have an outweighed impact on others. Eg, it only takes a few people solving those problems to help everyone. Where as from my perspective, loads of businesses need web apps, fairly simple backends, mobile apps etc for their very specific use case where they want to control the whole user experience.
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.
> 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.
If it's a failure to demonstrate a basic skill that are relevant to the job, then yes, that's entitled. However what was described is much closer to irrelevant trivia. I don't think it's entitled to resent such things being the deciding factor.
Googles issue is a good part of their hiring is generic and the interviewers random
No one knows what your going to be working on
Well, that ended on a weird, combative note. Are you sure that's what I was saying there?
I go back and forth on my opinion for this one. You wouldn’t necessarily want a mechanic or engineer to drive a race car, for example.
Yes, but having a mechanic or engineer who's worked on the racecar your driver is in would be very helpful on your team.
And we're also not driving race cars, we're the pit crew... So you kinda do want mechanics...
Like, literally, we build and fix the thing you're selling. We do not USE the thing we're building by and large.
> 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.
> 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.
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 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.
It's so rare, as a developer to actually get to sit in on user testing, and every time it is just incredibly valuable to see what people actually do.
Yeah absolutely. I worked at a startup awhile ago with a really incredible designer. She insisted that everyone in the company sit in on one or two user interview sessions she had organised with our potential users. It was an incredibly eye-opening experience, and I can't recommend it highly enough.
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.
Well my comment wasn’t really on usability or UX per se, just noting that the narrative of needing race car drivers is inaccurate. You don’t need to reverse B-trees to program normal software.
Also usability concerns have nothing to do with reversing B-trees.
> You wouldn’t necessarily want a mechanic or engineer to drive a race car, for example.
GM does. Their engineers have set multiple track records[1] and vehicle-specific lap records[2].
[1] https://gmauthority.com/blog/2025/02/c8-corvette-zr1-sets-fi...
[2] https://www.roadandtrack.com/new-cars/a10206481/the-chevrole...
Event better is his response to the comment.
> 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.
Has anybody ever figured out what "invert a binary tree" means? That came from Max Howell, and nobody else seems to have ever received that question.
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?
leetcode seems to agree with your definition [0]. the meme isn't to say that inverting a binary tree is particularly difficult - anyone familiar with coding challenges and trees could trivially produce a solution. the meme is more pointing out how ludicrous it is that senior/staff/principal interviews can hinge on these types of problems, despite the engineer proving their proficiency by doing something like running DOOM in typescript types or writing homebrew [1].
[0] https://leetcode.com/problems/invert-binary-tree/description...
[1] https://x.com/mxcl/status/608682016205344768
I think those challenges (especially leetcode) are heavily misused.
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.
I agree with this. I got to experience both sides when I interviewed at FB/Meta. I practiced the leetcode and Cracking the Code Interview stuff of course and one of my interviewers asked something like that. I guess it was insulting and pointless but whatever - I just did it.
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.
Our technical questions typically stay within the realm of the position we are hiring for, so technical usually revolves around “would you use X or Y in this scenario? Why?”
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.
> If you aren't evaluating based on conditions like those, I don't really see the value of coding questions.
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.
This is absolutely the way. My interviews are conversations with someone that I want to work closely with, and while leet code might be an interesting lunch conversation it’s not going to be part of any of our day to day work (c/c++/swift/obj-c)
I think brew's author point holds even if you replace "invert binary tree" with any other LC problem.
In terms of the problem itself, a binary tree can be expressed something like:
Given a root, you can invert it recursively with some code like this: Or using an explicit stack: I think without prep would be harder to come up with the non-recursive version.Maybe the catch was in saying that left right labels are arbitrary, could be called node1 and node2 as well, inverting is not necessary per se, just visit it in node2, node1 order if needs to be flipped - ie. no physical rearrangement is necessary.
Also the best answer to "how do you reverse an array". You don't. You just read it in the opposite order. Especially in any iterator-based language it should be trivial.
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".
Right, but sometimes you actually do have to reverse the array.
I can't remember the last time I reversed an array. Honestly it's at least a code smell. Why can't your code just read it in the other direction? Or have it in the correct order in the first place (e.g., sort it correctly instead of sorting it backwards and then reversing it). It's not that hard, even in a C-style for loop language.
Because usually the code to handle it is not mine and it expects to go through the list in forward order. Nobody makes APIs that take a list of, idk, files to delete and lets you pass in a parameter that is “please actually run your for loop over this in reverse”. They expect you to flip your array before you hand it in.
Depends on how you look at it, I guess. A binary tree has a couple of properties. Usually there is some ordering on the type. Something like: the element on the left is smaller than the element on the right. (e_L < e_R). Invert would be than turning the ordering into e_R > e_L. I guess this is the left and right branches exchange answer.
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.
That's what it means, and people use it as an example not because it's like, some sort of super difficult unreasonable challenge, but because it's completely unrelated to the work you'd be doing on the job like 99.99% of the time. It's like interviewing for a line cook and asking them to make a spatula.
I’m 100% sure that if he was being considered for a domain expert role in some domain related to this (e.g. TypeScript) his score in a typical whiteboard interview wouldn’t have been a deciding factor whatsoever. This is a standard hiring track even in big tech. Sometimes you’ll even be exempt from these interviews altogether.
But if he was being considered for a mid level generalist role, yeah, none of this would’ve mattered. And why should it?
Seriously lol. Someone who can figure this out can figure anything else out.
Would he have made it past your recruiter screen though?
A lot of people who have a gap between jobs for 1-2 years because they worked on their insane projects certainly wouldn't.
People are allowed to not work when they please, and you should avoid any employer who perceives self-indulgence and self-sufficiency as a red flag.
Unfortunately I feel like recruiters at larger companies are squinting at CVs and think like: "Open source? Entrepreneur? Eh, oh. Smell of despair and discarded pizza boxes.".
Of course unless your passion project is very successful one, but majority of them are not.
While I agree with the sentiment you are delivering, I think successful is probably the wrong word here.
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.
And would he have even bothered to apply, given the boring-sounding, narrowly worded JDs that get posted?
The justification is that it's almost impossible to get "good employee" signal any other way. If you tell people upfront that you're testing them on leetcode you at least get some signal that 1) they're willing to put in time and follow through on studying for something 2) they have some base level of programming skill and intelligence
Companies optimize hiring for avoiding false positives (bad hire) over false negatives (bad rejection), especially in this job market.
Given his skills, he'll be able to pass the usual coding interviews with some preparation. In most companies, the bar isn't that high, they're just there to ensure that candidates have some minimal (usually undergraduate) algorithmic knowledge, and is able to interact with the interviewer (communicate their ideas, act on hints and so on...).
Why do you think person capable of making doom run in such an environment is incapable of basic tree operations?
I suspect the technical interview devolves into an act of shunting the blame of potential bad hires away at some places. Elite credentials and leetcode shibboleths serve the same purpose: this person has checked the boxes we've agreed upon as important in the hiring process, regardless of the job duties. If they turn out to be a bad hire, who could've known, esp. with that Ivy League bachelor's degree?
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.
>shibboleth Fantastic word right there, had to look it up. That's exactly how I'd describe the hiring process these days. Relevant expertise seems like its only seen as a bonus. That or I'm interviewing at some terrible companies.
The role of such standardized coding interviews is to ensure consistency when hiring at very large scale. Some big tech companies hire thousands of people a year, and interview ten times that.
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.
Its a meme, Batman
I think, nowadays, I can get a generative AI to tell anyone how the process of inverting a binary tree works, and perhaps even give sample code for it.
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.
> "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."
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.
The problem is that eventually they outsource key parts of the codebase to a cheap consulting agency where all this reasoning goes to waste anyway.
> 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."
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
> 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.
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.
Reminds me of https://aphyr.com/posts/342-typing-the-technical-interview
Yeah that’s obvious and probably good. You’re trying to make a machine that reliably adds employees to your company in a way that minimizes nepotism or corruption.
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.
[dead]
[dead]
[dead]
[dead]
[flagged]
I hope he learned something useful while doing it and it seems like he did, because, although regarding all the comments here I'll likely be alone in my assessment, I just see a massive waste of time & effort? He described it as "a brutal year-long journey of 18 hour days" and he didn't bootstrap a company, he wrote Doom in Typescript types...?! The "epic" doom music underlying his story just makes it seem even more comical to me.
Maybe it's just me, don't want to crash the party. Carry on
> don't want to crash the party
> 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.
It's just you. It's extremely impressive. He likely set himself up for life with this + learned an unbelievable amount. And this is, in and of itself, a business. He has merch, a conference, a social media presence, etc.
I guess you have to ask yourself, what truely gives value in life? The answer is that value is subjective, and this person is wasting his time no less or more than you or I.
It's just you. I would rather hang out with this guy than anyone who has ever started a company.
This reads to me like "After running the marathon he just went from point A to Point B, and that effort could have been better spent elsewhere"
It is just you, I think.
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.
You could say the same about art. Artists put lots of time and effort into creating unuseful things to inspire others. Just like here!
Uh, I think he learned what _universe level scale_ really means.
Can anyone explain to me what is "TypeScript types“?
imagine how amazing it would be if every major browser tomorrow suddenly dropped support for JS entirely and said that they only run typescript now. It will be a hard but absolutely mind blowing transition
What would be the point? Why waste time parsing and ignoring types? Types are for static analysis during comp time, they have nothing to do with the runtime and they don't provide "type hints" to the runtime about types, and code isn't optimized based on static typing analysis. Or should the browser do that? In that case which version of TypeScript? And by version I actually mean which tsconfig? Sorry for being picky but can't image why we would want something like that. If all we wanted was a compiled runtime like flash/actionscript was then I wonder why we killed flash
it would get rid of babel immediately and the billions of hours of transpile time spent across the planet by people converting ts into js. You ll be able to run ts natively without transpilation across every major browser
I think that would be a big loss for TypeScript and a very unfortunate thing for the whole ecosystem.
Not to be a grouch, but I feel like this could be way more optimized
It's a bit that it is oversold, but it's a cute little VM.
https://github.com/MichiganTypeScript/typescript-types-only-...
Though the fact that the actual converter that converts from WASM to TypeScript types is in Rust makes it lose a bit of charm, but still.
Like Flappy Bird in TypeScript types did: https://zackoverflow.dev/writing/flappy-bird-in-type-level-t...
It is open-source, you are of course more than welcome to take a crack at it.
I know the following comment is discouraged from hackernews but these are extenuating circumstances:
Yoooo WTAF
Typescript is for me one of the most overengineered programming languages. Why did JS not follow the way python and php did? Integrate types in the main language but make it optional.
When typescript came out, you were seen as weird for wanting such a thing. I once had a VP of engineering dm me to tell me to stop discussing typescript in the company dev channel around 2015 (if you're reading this, that was a dick move). Nowadays you're kinda odd man out if you don't want types. So the idea of adding types even optional ones probably wouldn't have gone down well. The closest we ever came was es4 which of course never landed: https://evertpot.com/ecmascript-4-the-missing-version/
Thank god they didn't follow the way Python did.
Python keeps the types at runtime, that's why no TypeScript framework will have a developer experience anywhere near something like FastAPI.
It's doable if you really want to: https://docs.nestjs.com/openapi/cli-plugin#overview
(Also doable without a compiler step, but since it's TS one more compiler step isn't the end of the world: https://docs.nestjs.com/techniques/validation#auto-validatio...)
I do use this. It's not as seamless as using FastAPI. Also not as type-safe as FastAPI.
You can simply type a class variable as an int while the validation decorator works on a completely different type. It's an illusion of type safety.
First party runtime types would be nice, but zod has become pretty much the standard answer for projects that need it. Not complicated.
Tell me how to have automatic documentation and validation like FastAPI using anything in Node.js and I will use it immediately.
Note: NestJS isn't it.
Do OpenAPI Swagger docs count? That seems to be the route a ton of the ecosystem takes.
trpc, ts-rest, and express-zod-api all explicitly build on zod and can do validation + Swagger UI generation.
hono looks like it doesn't do that by default, but single-source-of-truth validation + Swagger UI are available as middleware via `@hono/zod-openapi`.
Typescript does support it. You can do everything ts can in js with just jsdoc style comments. I actually prefer it.
I wonder if there will come a time when the HN audience will stop being amazed that some system is Turing complete, or that any Turing-complete system can run Doom (barring resource constraints). Maybe I’ve just seen it too often. The fact that TypeScript’s type system is Turing-complete was shown back in 2017 [0], and then of course you can run Doom on it.
[0] https://github.com/microsoft/TypeScript/issues/14833
There’s a difference between a _system_ being Turing complete and something actually _using_ that Turing-completeness to make something arbitrary run on it. You can’t deny this is an impressive effort.
It’s a considerable amount of work for sure, but that alone doesn’t make it impressive. Maybe there were particularly difficult hurdles to overcome that were solved in novel ways? But I don’t see such noteworthy aspects being mentioned in this thread, and it’s not evident at all that there should be any.
Is this your reaction when someone climbs a mountain? "Bipedal locomotion was shown sufficient for climbing mountains centuries ago, given reasonable assumptions about the terrain, why should I be impressed?"
Doing things can be difficult and admirable, even if it was confidently believed possible beforehand.
> Is this your reaction when someone climbs a mountain?
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.
It’s still impressive if your manager does it. Or your date. Or your mom.
Oh come on, are you seriously being blasé about this? What could ever impress you?
A time-travel machine would be really impressive, I would give all my money for that, and even upvote the thread.
> I wonder if there will come a time when the HN audience will stop being amazed that some system is Turing complete
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
We know that humans are capable of writing amazing symphonies or running a 2h marathon, so there’s no point in doing it?
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.
There is a big gap between "Turing complete"-able and "real-time, interactive, graphical and performant"-thing.
To be fair, this is graphical, but it's not real-time, not performant, and while it technically takes input, it'll be a while before you see it reflected in the output.
Ah yes, the Underpants Gnomes theory of Doom execution:
Step 2 is, of course, always trivial, and no amount of effort or technical nous that goes into actually getting to step 3 can possibly be relevant.I think you missed the part about how much effort they put into it.