I see no difference between X and Instagram in this regard whatsoever.
Think NASA, for example; it's also a government agency, and they are doing great job posting photos in Instagram, do you think anything is wrong with it?
It is just bizzare when you take a step back and remember the world 20 years ago. NASA would just post directly to their own website. Of course they would. Now imagine you go back in time 20 years ago and say "What if we took all these images you are providing for the public on their dime, compressed the hell out of them, and served them in this for profit proprietary marketing/propaganda app instead?" Engineers in 2006 would have probably looked at you like you had three heads. The question would make no sense back then.
Something to think about when we consider what is "normal" today. Not much really is normal. We've been beaten to think it is.
I feel that this is somewhat orthogonal. Yes, some questionable things have happened that made the ways how people exchange information be controlled by a handful of corporations.* But for NASA specifically, this is not relevant. They were not the ones who forced people to go to social networks; they needed to go there because this is where their audience was.
* On that note, and for the sake of the argument, I would say that the years of free uncontrolled information exchange in the Internet can probably be considered an exception. Information exchange was always controlled by governments and businesses (e.g. TV and newspapers) before, just as it is now. The fact that you or I don't like it does not change that this is how it used to be before the Internet appeared as a "free space". My generation was lucky to see how great the world with free information exchange could be, but I don't have much hope that it would stay like that for long.
I think one has historically been more text based vs image based. so for comms, i think X makes more sense. Space Force is under DoD so funding not much an issue. NASA, not so much. They have to fight for every nickle they get, so appealing to audiences via images/videos makes sense. I'm more so questioning why HE needed an account, instead of just the organization. Like Space Force posting makes more sense than him using it. I think what you're getting at is that the medium of communication has changed to social media. I get that. I just think it expands the attack surface for that org. Just have one account and post through that
It's pretty amazing to me that, if your goal is to check that the intern candidate can write plain C, the questions still look pretty reasonable to me even in 2026, maybe except for the question related to colors which will probably confuse the majority of the interns (2 bits per color? how is that possible).
For the circle drawing exercise, it just seems that the interviewer did not do a good job hinting the author. Fun fact: a person I know got this question on their Microsoft interview in around 2016. I guess, it the question works, why bother changing it!
this is probably a rhetorical question, but lemme answer anyways: By packing the colour channels into a single byte. So, for example, you'd have RRGGBBAA within a single byte, for each pixel. Giving you 64 possible colours, with 4 steps of alpha.
Or if you don't need to have alpha, you could pack it even further down to RRGGBB in a byte, which leaves 2 bits left over for the next pixel. Via that, you can pack four pixels worth of colour data into 3 bytes: RRGGBBRR|GGBBRRGG|BBRRGGBB (italics for delineting pixels, vertical bars for delineting bytes)
The latter is a tradeoff between compression and a more complex accessing pattern.
A bit of a tangent, some system used RRRGGGBB for colours, because the eyes are the least sensitive to differentiating the amount of blue, so that's another way to use up a full byte per pixel.
Oh right. Guess the " (2 bits per color? how is that possible)" is what threw me off there, because I read it as 2 bits per colour channel, rather than cga colour. Of course, "indexed" colours can get away with much fewer bits.
A modern example of odd color schemes is 18bit color which is still often used in small cheaper displays (666/18bit vs 565/16bit) keeping the maximum color space available for all colors on these displays. If you are lucky you only have 16bit bus available and also need to do 3:2 packing, but that allows you to use 24bit in code and ramming the bytes in sequence over the 16bit bus without any modification (since they ignore the extra two bits per color).
It seems the first two questions are coding ones, and the second two ("flood fill" and circle drawing) are more thinking ones.
The flood fill color detection one would be fastest with a look up table returning a bitmask of colors contained in the byte, with the Color param also as a bitmask, then the result is just lut[Pixel] & Color.
The circle drawing one only needs you to know basic trig to get from radius and angle (0-360) to (x,y) offset from origin. You could embellish the answer with symmetry and LUTs too, but the problem statement doesn't say anything about efficiency.
I don't believe you need trig for that, it actually makes it harder if you try to iterate the angle. I believe the expected solution is to start at (R, 0) which is known belongs to the circle, and go left/top, choosing the pixel closest to the circle on each step, which does not require any floating point arithmetic.
The problem is under-specified both in terms of requirements and any implementation restrictions.
Given the lack of difficulty of the other questions (and this being pre-internet, targeted for an intern), I don't think the interviewer can have been expecting too much sophistication.
The other obvious way do do it, only requiring the same minimal realization that this is about triangles (with radius as hypotenuse) is to use r^2 = x^2 + y^2 and iterate x=0..r deriving y. You could do it without sqrt if they stipulated that.
Right, iterating through pixels is better. The tricky part about iterating the angle is that you need to choose the step size correctly or else you could skip pixels. Like if you iterate in 1-degree increments, you'll plot 360 pixels total, but the size of the circle on your canvas might be more than 360 pixels wide. I'm sure there's a way to choose the angle iteration step size to guarantee not skipping pixels, but you'd often duplicate work and re-plot the same pixel twice.
So yes, start at (R, 0), increment the y-coordinate each time and possibly decrement the x-coordinate, until x=y which will be at 45°. If the circle's center is an integer on the pixel grid, you can reflect/translate each pixel in that first octant to all eight as you go. If the center is fractionally positioned, you'd have to calculate it all the way around, iterating primarily on y or x depending on the location.
> The tricky part about iterating the angle is that you need to choose the step size correctly or else you could skip pixels
Yes, although the problem statement doesn't say if they care. In this case they are only giving a draw_pixel() primitive, but if you had draw_line() then you could use that to avoid gaps.
The other thing is that this is 90's era, with a CGA display (640x200) being mentioned in the previous question, so I'm not sure there's enough resolution to draw a real circle without gaps unless you do resort to some hack to ensure there aren't any!
As the author notes, it would certainly be a massive ramping up in difficulty if they were expecting you to reinvent the midpoint algorithm on the spot.
Assuming high colour depth, yes, but wouldn’t it have been specified as part of the question that ‘this was for four-color CGA mode’? I think 2 bits per colour for 4 colours total seem pretty sensible even in 2026. :-)
Their point, I believe, is that someone (just about any younger person in 2026) who has never seen indexed color modes, or colors taking less than one byte per pixel to encode, could reasonably be confused by the notion of "two bits per pixel".
CGA was very limited, and didn't even support full per-color indexing - instead you got to choose one of two palettes (i.e. one of two different sets of 4 predetermined colors).
CGA was followed by EGA which supported 16 individually indexed colors (with a palette of 64 colors). With dithering you could display "faded polaroid" quality photos.
CGA is even more nuanced than just two palettes. You can choose from three palettes, and each can be set to low intensity or high intensity, so you can effectively choose from six. On top of that, the background colour for each palette (colour 0 which defaults to black) can be set to any colour from the full CGA 16 colour palette! I wrote a sample program for a friend recently to demonstrate this https://github.com/samizzo/cgasample
That's true, the majority of people probably install software without much thinking; but it's also true that it's always better to have at least some high level understanding how the specific piece of software works. What access the given software has, will it send something over the network or work locally; that kind of stuff.
As for Docker, I would assume everyone who ever tried to bind-mount a volume for writing from inside the container (on Linux*) then were surprised to see root-owned files in their bind-mounted directory. For me personally, that was the moment I realized that containers, by default, have root access to the filesystem. No written warning serves better than the need to chown some root-owned files.
* Not on macOS. On macOS Docker basically runs in a VM, and there's no root access to the host filesystem from what I understand.
Docker relies fundamentally on the Linux kernel. Since macOS does not have a Linux kernel, you have to run Linux in a VM first and then run Docker on top of that.
So, you may get filesystem access inside the VM. Breaking out of the VM may be a different matter.
I primarily use Incus for all container stuff, not Docker. Is problematic if I want to e.g. use a docker-compose file, but I (think) it protects against these things because incus allows me to create a vm and not a container if I really need that level of isolation.
I only grepped "vtable" in the repository so this might be not the relevant piece of code, but from the comment in [1] it seems they fallback to building a vtable if the static resolution is impossible.
I understand that implementing the TypeScript compiler is not the same thing as implementing all Node.js APIs, but still, advertising "no runtime" and then requiring JS runtime (and a full local Rust setup to compile it) for something as basic as an Express web server makes the "no runtime" claim look like a slight exaggeration. I'm not saying that it's bad, it's just that the website is too optimistic.
Edit: as discussed in the thread below, the most likely reason for that is that Express is pure JS with types from @types/express, so the TypeScript compiler bails on it. Reasonable, but still frustrating.
Overall, it seems like every time I decide to try a vibe coded compiler I get this feeling like when you see a plate with fruits on a table but, coming closer, see that they are fake plastic fruits. No, I cannot use it to build a native binary of my project without V8 as easy as shown on the front page. Maybe some other project, yes, but not a real one.
Unrelated: if a project is called Perry, should the icon be a platypus in a hat, you know?
> Perry exposes a faithful subset of Node.js’s stdlib HTTP server modules on top of hyper + rustls + tokio-tungstenite. The whole shape — handler signature, IncomingMessage / ServerResponse properties + methods, TLS opts, ALPN-negotiated HTTP/2, WebSocket upgrade dispatch — works unmodified, so unmodified Node servers (Express / Koa / Polka / hono via @hono/node-server / etc.) compile and run natively[1]
It's pretty standard for "no runtime" to mean nothing on the device you install the compiled target app.
I think iOS development still needs Ruby for Pod installation but no one says Swift apps need a Ruby runtime for example.
Well, I did indeed spend some time playing with it before writing my comment. I first tried to compile the TypeScript project I'm working on, and it happens to be an Express server. After some minor unrelated fixes required (Perry does not understand importing "fs/promises", so I fixed it to import "fs" and then taking .promises) it said it needs JS runtime, and the smallest repro I found was
$ cat index.ts
import * as express from 'express';
const app = express();
which gives
$ perry index.ts
Collecting modules...
JS module: express -> /private/tmp/ex/node_modules/express/index.js
Error: build pulled in `perry-jsruntime` (QuickJS-based eval-equivalent runtime) via the following file(s):
- /private/tmp/ex/node_modules/express/index.js [express]
`perry-jsruntime` is treated as a privileged dependency on par with adding a JIT to the binary — it re-introduces arbitrary runtime code execution and defeats Perry's structural advantage over Node. Refusing to link by default. (#499)
To enable, set `perry.allowJsRuntime: true` in the host package.json, or pass `--enable-js-runtime` on the CLI for a one-off build. (Falls under `--lockdown` deny set when that flag ships — see #496.)
Maybe it's because Express is written in JavaScript with external types from @types/express, that would explain why it might need JS runtime, but it does not make things easier for me.
It is not standard for “no runtime” to mean that. For example go has a runtime that is compiled into the binary or you can google c runtime and see a million ways the word “runtime” is used with c.
The infrastructure required to support a programming language, startup and shutdown boilerplate, all the required functionality to support standard library features including integration points between language semantics and support code.
Stuff like what code runs before and after main(), trap handlers for floating point arithmetic, handling of thread local storage, bind language heap handling primitives to library code, traps for handling stack overflow errors,....
Right, runtime is so broad that it's hard to say something has "no runtime". libgcc + your choice of crt0 is a C runtime, and the JVM is a Java runtime. That's a huge spectrum.
It's worth being charitable in your interpretation though and recognising "no runtime" probably refers to JVM-shaped or Node-shaped things, not libgcc+crt0-shaped things.
Alternatively, "runtime" is a derogatory term used by programmers who want to show superiority over others who use languages with more (built-in) features than theirs.
There's practically no difference for the overwhelming majority of software these days. Most people aren't working on embedded systems or operating systems.
I am taking this attitude to an extreme with tsz. I don't want to announce to the world that tsz is ready until I tested it really really well.
Currently tsz passes nearly 100% of TypeScript tests but that is not enough. I want it to be able to type check complex things like type-challenges solutions or complex utility type packages. I'm stress testing it with a repo with 1.5 million lines of code.
I'm constantly assigning AI agents tasks to find bugs in tsz and open issues.
I'll say this is "alpha" when it can do all those things plus matching tsc exactly in thousands of open source projects where tsc reported type errors. It's easy to find CI runs that tsc reported errors. I'll build a database of all the cases I've verified tsz with and will publish those. Hoping that can give folks confidence that tsz is robust
(I'm the founder of Perry) thanks for giving it a try and let me be upfront with you: Compiling express has been one of the hardest challenges for Perry. I'm 99% sure it still does not work out of the box just yet - which is why we pivoted to fastify more than express.
That said, the last few days we made great progress to get Perry to compile packages "lik" Express (lot's of dynamic imports) much better.
I'll retry this once our current batch of Nodejs parity issues are resolved.
Just to be clear though: No v8 runtime, we actually took out the v8 engine we had optionally included thus far because the benefits no longer outweight the disadvantages.
If you want to tag along the progres follow me on X (@proggeramlug), that's where I share the most up to date progress on Perry.
Also, it is definetely a goal to compile apps that use Express and that will happen - not commiting to a timeline but just in the last few days we got so much closer.
Don't get me wrong, I'll be totally excited to replace my card game app backend with a static binary, that's why I immediately went on trying Perry :)
Just to give you an idea what I'm trying to achieve: I'm currently hosting it on a single VPS. Node is handling the average of 30 qps, peaking up to 100 qps, just fine, with P99 latency being safely below 100ms and only occasional spikes of P99 to up to a second. The spikes are probably caused by some VPS sluggishness as I just use filesystem to periodically dump the in-memory games state.
But I expect I might eventually start seeing performance issues, so rewriting to a language that compiles to a native binary is on the table. I was considering Golang or Rust; making the current codebase compile to a binary would be a miracle saving me quite some time, even if I just vibe-code the rewrite :)
Just to chime in, i was having decent luck compiling Express apps to a binary using the experimental Node built-in executable feature--two years ago i was able to ship a single-binary Node-Express server without much headache.
Doesn't avoid the runtime, but it made deployment really easy.
To be fair, nowhere on the frontpage does it say it can build libraries that depend on node. It seems like you are just waiting in the bushes to dis AI assisted coding.
I would probably suggest switching the link to the GitHub source code and listing the actual page URL in the description; otherwise, I click the link in the article and get a location sharing request and a Send button; after a few seconds I matched that with the title, but I still had my WTF moment.
I'm thinking of some similarity between the non-technical middle manager using agents to avoid the biggest obstacle of their developers, and a person installing a wall socket at home.
It's not too difficult to install a wall socket, but many things can go wrong, so people would normally call an electrician. In some jurisdictions you are not allowed to install it without a license, or probably you can install it only for yourself but not for anyone else if you don't have a license, and you need to call an inspector and check your work when you're done. Some other jurisdictions truly don't care, you can do whatever, and all the possible damage is on you.
Electricians are somewhat fungible, because you often don't care who will do the job for you, but the profession exists and they can pay their bills.
I wonder how far we are until, at least in some jurisdictions, a person won't be legally allowed to update the website that stores customers' data or processes payments without being a licensed software developer, and how rules, should they be adopted, will change our profession.
The majority of the software development related communications are trivial enough, emotionless, and do not require calls, but there are cases where one quick call resolves ambiguity much faster than hours of typing.
While I do know a feeling of dreading the upcoming call, especially if this is a call that I know won't be useful or rewarding for me personally ("let's quickly go through this infinite list of jira tickets", "let's do a quick round table"), it's important to remember that texting, including all sorts of corporate messengers, is one of the worst media to transmit emotions. Seeing another person's face while talking to them and their reactions to your jokes or struggles is sometimes as important as the message being transmitted. Of course, the camera must be turned on for this to work.
reply