The author’s memory is remarkable. I hardly remember my own name that far back, LOL. Back then, I knew I would always struggle with those types of interviews, so I always carried a floppy disk with me to them. The disk contained a few programs I had written, and I would simply tell the interviewers, “Don’t give me a quiz. I’m terrible at it, so if you do, I’m out.” However, if they were willing to look at my capabilities, I would share a few of my programs. That approach actually worked most of the time and got me the jobs. The good old days!
The circle outlining one seems interesting to me. I definitely didn't read the algorithm ahead of time, and I'm probably not as smart as a revolutionary genius computer scientist, but I thought of 2 basic algorithms in a few minutes.
You could iterate over the degrees 0 to 360, use trig functions to figure out where the point at that angle is, and plot the closest point. Might need to be a bit tricky about the step size, but I bet you could compute a decent guess from the radius using more trig functions. Of course that probably doesn't work if you don't have floating point and trig functions.
You could also split it into four quadrants. Plot each of the top, bottom, right, and left points by direct computation of adding/subtracting the radius, then for each quadrant, you start from the computed point, check 3 specific points in the appropriate direction for which way you're going in that quadrant, plot whichever one is closest to the radius away from the center, then repeat from that plotted point until you reach the computed point for the next quadrant. It would be tedious and repetitive, but should be doable. You could probably also avoid computing square roots by comparing the squares instead. So I guess you'd want something based on that idea to do it fast on 90s hardware.
An optimal algorithm is shockingly simple
This is a fun article. As a current Principal at MSFT I've never seen these type of questions being asked in interviews. I don't think it's fair or accurate to say "If you’re an experienced programmer, you already know how to do all of them". So many of the SWEs and candidates at Microsoft are just studying leetcode using python, joining the company and writing managed C# code.
I would far prefer getting managed C# over the Electron garbage that constitutes much of Windows nowadays.
The second one is absolutely trivial if you've ever read K&R (even if you're not allowed to just call strcpy()), while the fourth one is also very straightforward if you know about https://news.ycombinator.com/item?id=15266331 ; but 32 years ago, knowledge definitely did not propagate as quickly as it does today.
Additionally, I was allowed to store Color however I wanted — so if I needed some precomputation, I was allowed to bake it in there.
I believe it can be done in three operations, not including the precomputation.
> The second one is absolutely trivial if you've ever read K&R (even if you're not allowed to just call strcpy())
The naive approach’s assumes you can iterate over the first string until it terminates.
It’s a bit trickier if you do not assume the memory regions cannot overlap.
See memcpy vs memmove: https://man7.org/linux/man-pages/man3/memmove.3.html
Just tried the:
y -= x >> 4;
x += y >> 4;
Certainly works, and seems to require 100 iterations to get a full circle.
Are there other approximations, taking smaller angular steps, to get a better circle?
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!
> (2 bits per color? how is that possible).
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.
So, first of all, of course, a rhetorical question. Modern interns will probably assume at least 4 bytes per pixel (R, G, B, and A).
But the original post actually talks about CGA [1] with just four colors. Encoding a color needs two bits then, so each byte encodes four pixels.
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.
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!
The circle one is fishing for sonething clever. 90s without floats means no trig
So use sin/cos lookup tables?
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.
> (2 bits per color? how is that possible)
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".
2bpp is indexed obviously, question in 1994 would be is it bitplane or packed
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.
I had somewhat similar questions asked of me in the 2000s, and I still ask similar questions today.
It's been a long time since I did any interviewing, but for a whiteboard task I'd ask for something very simple like reversing a list. It's basically a lying test more than a coding test - and sad how many people claiming multiple years of C++ could not do it.
What is pitch in regard to a rectangle in question two?
void CopyString(char *From, char *To)
{
/* Fill this in */
}
Well in an interview I guess something like "Of course we shouldn't allow C-strings in general outside of syscalls and argv, but for the purpose of the exercise...." And now you've shown that you know what you're talking about and that you won't be difficult to work with.
/* YOLO */
while (*to++ = *from++) ;
Hey, in 2026 strcpy is still part of the C standard library (much to the chagrin of anyone security conscious).
The key point (which I believe static analysers these days can easily check for) is to check the sizes of the source and destination.
I can tell this is from forever ago by floppy disk.