5 ms·

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 2

by ventana 5mo ago

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!

Akronymus 5mo ago
> (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. https://en.wikipedia.org/wiki/Color_depth https://en.wikipedia.org/wiki/Color_depth
- ventana 5mo ago
  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 https://en.wikipedia.org/wiki/Color_Graphics_Adapter
  - Akronymus 5mo ago
    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.
- consp 5mo ago
  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).
F3nd0 5mo ago
> (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. :-)
- lstodd 5mo ago
  2bpp is indexed obviously, question in 1994 would be is it bitplane or packed
  - HarHarVeryFunny 5mo ago
    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.
    - bananaboy 5mo ago
      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 https://github.com/samizzo/cgasample
- Sharlin 5mo ago
  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".
HarHarVeryFunny 5mo ago
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.
- __s 5mo ago
  The circle one is fishing for sonething clever. 90s without floats means no trig
  - HarHarVeryFunny 5mo ago
    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.
- ventana 5mo ago
  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.
  - HarHarVeryFunny 5mo ago
    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.

by ventana 5mo ago

Akronymus 5mo ago

> (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. https://en.wikipedia.org/wiki/Color_depth https://en.wikipedia.org/wiki/Color_depth

ventana 5mo ago
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 https://en.wikipedia.org/wiki/Color_Graphics_Adapter
- Akronymus 5mo ago
  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.
consp 5mo ago
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).

F3nd0 5mo ago

> (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. :-)

lstodd 5mo ago
2bpp is indexed obviously, question in 1994 would be is it bitplane or packed
- HarHarVeryFunny 5mo ago
  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.
  - bananaboy 5mo ago
    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 https://github.com/samizzo/cgasample
Sharlin 5mo ago
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".

HarHarVeryFunny 5mo ago

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.

__s 5mo ago
The circle one is fishing for sonething clever. 90s without floats means no trig
- HarHarVeryFunny 5mo ago
  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.
ventana 5mo ago
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.
- HarHarVeryFunny 5mo ago
  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.