The website has demo agents, including "Support persona" Anne, described as "calm and capable", and "Lead gen persona" Gabriel, who is "warm, sharp".
I had a good laugh when I asked them both to tell me how to sort an array in Python, and they did indeed read the whole code, with a smile and intonations.
(assuming there is no option to switch team or leave the company)
Try understanding what your manager actually needs from you. If it's a big company and you are an IC, your main goal is not directly related to your company's declared goals, but it's very simple: make your manager feel safe; and the way to achieve it is to understand what actually makes them feel safe, and help them get it.
Micromanagement often means that the manager does not feel they can trust their reports to do the work the way they want it. In many cases I saw in the corp context, some proactive reporting – that is, filing issues in the issue tracker and updating their statuses before someone pings you and asks to do it – and making sure the manager knows what you are doing helps build trust and removes the need to micromanage.
A question to ask yourself: does the manager micromanage the whole team, or only you?
> The Hippocratic License is an ethical software license created to ensure that open source software is not used for harmful purposes, aligning with human rights principles
The paragraph doesn’t really explain the rationale for forbidding WTFPL and even Public Domain and CC0? They’re all fine for commercial use, aren’t they?
It just looks like a funny slop project if you read the English readme, but reading the Russian PHILOSOPHY.md [1] (auto-translated [2] if you don't read Russian) makes you realize that there's probably something more than "let's implement a messenger using git remote as a storage", knowing how popular messenger apps are getting blocked in Russia.
>Macaroni Messenger is not a political statement.
>We are not trying to circumvent restrictions.
>We are not trying to circumvent restrictions.
>We are not trying to fight the laws.
This is talking politics without talking politics. The project literally attempts to circumvent russian censorship restrictions and their spirit. This is either a joke the file talks about or naive CYA.
Cool project nevertheless, I like idea of an utility SPA distributed as bare HTML file that doesn't even require a web server.
There is a popular view in Russia, including within the software developers communities, that "politics" is something bad and dirty; people often ban "politics" in group chats and forums.
As a result, a highly technical person might work on a very complex solution to circumvent the restrictions but will declare (and probably even truly believe) that they are not making a political statement – as opposed to, for example, attending a protest, which is definitely considered a political action, or supporting a politician.
Thanks for clarifying, that's a pretty good summary. Russian developers experienced the same "HN is not for politics" kinds of reaction on Habr (russian HN, more or less) a decade ago, until politics came for them and Habr died. Before that, "being outside of politics" was a stance some people identified with because back then Putins regime didn't repress as much and the situation was "stable". Seeing a take like that still having its followers after our autocracy matured even more is disheartening and sad.
documentation was updated in the last few days. You might want to read the section about the funny legal collision this architecture creates — not sure, but it might apply to other jurisdictions too, not just Russia. Either way, it's an interesting side effect of using generic git hosting as a message transport.
The paradox is that Macaroni Messenger is absolutely a joke project.
But once you reduce everything to Git + JSON, adding things like PGP, age, signatures, encrypted attachments, or end-to-end encryption becomes surprisingly easy.
Which makes it even funnier.
At first glance it looks like a toy.
After a few minutes you start asking:
“Wait… why does this actually make sense?”
I think the protocol is a bit underestimated. People see the joke before they see the architecture.
There are some surprisingly interesting properties hiding behind the absurdity.
Maybe it’s a hidden gem.
Or maybe I’m just rationalizing a messenger implemented as a single HTML file.
It does kinda make sense... until it doesn’t. It is a cool project from a tech standpoint, but it’s not practical when we have, well, email? (This is discussed elsewhere in the comments already, of course.)
That’s exactly what I thought after posting — so now it supports end‑to‑end encryption without a handshake. Still a single HTML file. Still no backend.
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.
Software wise, does vim and mutt count?
reply