The four programming questions from my 1994 Microsoft internship interview (2023)
1–10 of 103 posts
Re: The four programming questions from my 1994 Microsoft internship interview (2023)
#2It'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!
Re: The four programming questions from my 1994 Microsoft internship interview (2023)
#3It'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.…
> (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.
Re: The four programming questions from my 1994 Microsoft internship interview (2023)
#4It'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.…
> (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 th…
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.
Re: The four programming questions from my 1994 Microsoft internship interview (2023)
#5Earlier quoted context omitted.
> (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 th…
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. [1]: https://en.wikipedia.org/wiki/Color_Graphics_Adapter
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.
Re: The four programming questions from my 1994 Microsoft internship interview (2023)
#6It'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.…
> (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. :-)
Re: The four programming questions from my 1994 Microsoft internship interview (2023)
#7It'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.…
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.
Re: The four programming questions from my 1994 Microsoft internship interview (2023)
#8 void CopyString(char *From, char *To)
{
/* Fill this in */
}
Re: The four programming questions from my 1994 Microsoft internship interview (2023)
#9It'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.…
> (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. :-)
2bpp is indexed obviously, question in 1994 would be is it bitplane or packed
Re: The four programming questions from my 1994 Microsoft internship interview (2023)
#10The 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.