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!

    void CopyString(char *From, char *To)
    {
        /* Fill this in */
    }

The only correct answer to this interview question is "No."

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.

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.

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 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.

I had somewhat similar questions asked of me in the 2000s, and I still ask similar questions today.

What is pitch in regard to a rectangle in question two?

How does the video whiteboard work? I presume he isn't really writing backwards or is this some sort of software that handles the video and writing surface?

I interviewed at Microsoft in Redmond in 1997 and got zero programming questions. They were all knowledge-based or brain-teaser questions so I don't know if I believe that they gave 4 programming questions in 1994.

This brings back memories! I could easily pass this interview today, because I used to write code like this all the time 25 years ago doing gamedev (and so did everyone else to some extent). But the really interesting thing is that I just realized I haven't written code like this in a long, long time.

Programming has changed over time, but the change has been so gradual I hadn't even realized this until this article. These days I'm pondering how the profession has changed in the last 2 years due to AI. Feels a lot more like a step change. And yet I'm having more fun than I've had in a long time, both at work and at home, throwing Claude at problems. I still don't fully understand why.

I had a go at the circle one. What I tried was starting with something very straightforward (pseudocode):

  for each x from -r to r
    find y that minimizes abs(x^2 + y^2 - r^2)
    plot(x,y)

Finding y could be done by taking sqrt(r^2 - x^2) and then taking whichever for floor or ceil of that gives less error. But I assume they probably don't want sqrt. We could find y without using sqrt by doing some kind of search--say start with 0 and increment checked x^2 + y^2 - r^2 until we find where that crosses 0 and then take whichever y made it closes to 0. But that will be even slower than sqrt.

But what if we take advantage when we are trying to find the y for x+1 that we already have found the y that minimizes the error at x? Say we wrote a next_y(y, e) function that takes the y that was used for x and the error e that would be the error if we also used y for x+1 and that function returns the y that would minimize the error at x+1.

That's pretty easy (Python):

  def next_y(y, e):
      if e < 0:       # need to increase y
          delta = 1 + 2*y
          while e < 0:
              if e + delta >= 0:
                  if abs(e+delta) < abs(e):
                      return y+1, e+delta
                  else:
                      return y, e
              else:
                  e += delta
                  y += 1
                  delta += 2
      elif e > 0:     # need to decrease y
          delta = 1 - 2*y
          while e > 0:
              if e + delta <= 0:
                  if abs(e+delta) < abs(e):
                      return y-1, e+delta
                  else:
                      return y, e
              else:
                  e += delta
                  y -= 1
                  delta += 2
      else:
          return y, e

Here's how it is used:

def circle(r): x = -r y = 0 e = 0 print(f'{x},{y}') for i in range(2r): e += 2x + 1 x += 1 y, e = next_y(y, e) print(f'{x},{y}')

Here are some half circles drawn with it: https://imgur.com/a/5aYzPqS

The basic idea is that when you increase x by 1 you increase x^2 by 2x+1, and so (x+1, y) would have error 2x+1 more than (x, y). You then need to change y to compensate.

Changing y by k changes y^2 by 2yk + k^2. Changing k by 1 changes the amount that y^2 changes by 2y + 2k + 1. Note that 2y + 2k + 1 goes up by 2 every time k goes up. In other words if you look at the sequence y^2, (y+1)^2, (y+2)^2, ... the third order diffs are 2. So to see how consecutive changes to y affect y, we can just keep track of the adjusted e and the current second order diff. Then for each consecutive y we can add the second order diff in to update the adjusted e to for the next y, and add the third order diff (the constant 2) into the second order diff.

I split next_y into two cases depending on whether we need to increase y or decrease y. There is probably some way to combine them but it is late and I'm half asleep. Oh, and I realize half of the abs() calls can be removed. I thought it looked clearer with them.

For a radius 50 half circle here is how times it took N tries to find the right y:

   3 0
  68 1
  18 2
   6 3
   2 4
   1 5
   2 10

i.e., for 68 values of x, the first y it looked at was the right one. Here are the numbers for a radios 300 half circle:

   3 0
 410 1
 121 2
  35 3
  13 4
   7 5
   2 6
   3 7
   2 8
   2 11
   1 24
   1 25

That was a fun little exercise. It has two multiplies, but they are both by 2 so could easily be replaced by add or shift.

An improvement would be to make more use of symmetry. The curve looks best when x is between -r/2 and r/2. It would be better to draw just those parts and then use symmetry to fill the rest.

Answer posts:

1) https://www.computerenhance.com/p/microsoft-intern-interview...

2) https://www.computerenhance.com/p/microsoft-intern-interview...

3) https://www.computerenhance.com/p/microsoft-intern-interview...

4) https://www.computerenhance.com/p/efficient-dda-circle-outli...

The "Borland flood fill" routine that Microsoft was trying to beat was in the very popular (at the time) "Turbo Graphics for Borland" package which had an immensely useful stack of graphics primitives, some a little more advanced than what was available in Windows at the time, for pure DOS mode.

It was an awesome package - I shipped many products which used it in that era - and it was always a bit amusing to me that it seemed like Borland had almost everything they needed to write an operating system. But, they didn't.

A friend of mine interviewed for MS around the same time, albeit for a senior-ish position, and his question required knowing Fibonacci trees.

It wasn't an abstract CS flex on interviewer's part either, because apparently the fib trees were actually used in some part of the FrontPage.

My first ever programming interview was like a group interview. There were three or four programmers asking me questions, one at a time.

The only one I remember was to check if two strings were equal (in C). I wrote (maybe buggy) code to iterate both pointers, comparing while looking for the null terminator.

The interviewer stopped me and said, “You should compare their lengths first. If they are different, you can exit early.”

I was pretty young and didn’t know much, but I explained, “But you have to look for the terminator to find length so it’ll take twice as long.”

He snapped, “There are optimized functions for that!”

I assumed he was right. Needless to say, I didn’t get the job.

Maaaany years later, I realized the std library was probably open source. So I checked (one). It was nice to be vindicated :D

All of them are available as YouTube videos. If you only watch one, I recommend the fourth.

https://www.youtube.com/watch?v=ielZBraKsw8

https://www.youtube.com/watch?v=sabeq-FtfGw

https://www.youtube.com/watch?v=OE_UNZW-4_U

https://www.youtube.com/watch?v=JtgQJT08J1g

today it's paxos/raft questions for an internship writing Next.js for 10$ an hour.

I was busy being born in 1994 when I should've been trying to pass this interview haha

What I like about these questions is that they're small enough to fit in your head, but still reveal a lot about how someone thinks about memory, representation, and hardware

The Bresenham line algorithm was such a breakthrough to me - talk about looking at a differential (partial differential) from an integer view, by a particular axis! Anyway, by extension, approaching a circle using similar is actually "relatively obvious".

[I'm self-taught, so some things aren't as obvious to me as they are to others, and I still get terminology wrong!]

You can tell a lot about a C/C++ engineer by asking a simple question like strcpy(). Assuming they get it right (which many don't), you can then cover test cases, you can discuss trade offs on safety vs performance, and failure modes. It can actually be very interesting.

I tried to implement flood-fill for a JavaScript project I am working on. I found out quickly that recursion was NOT the best way to do this.

There are 3 algorithms I learned for circles when I was a kid. I wrote about them a decade and a half ago The third one is prety clever

https://schmantics.blogspot.com/2011/12/third-circle.html