4 ms·

I once interviewed at a company that had me write a couple styles of matrix multiplication in C as a take home test, as well as give a one-page description of a

by rcfox 7y ago

I once interviewed at a company that had me write a couple styles of matrix multiplication in C as a take home test, as well as give a one-page description of a project I had done. The project I described heavily involved graph searches. Then I had a phone interview where they started off by commenting that I was the only one to include tests and address undefined behaviour. Then I had to write a piece of code to traverse a tree and add numbers, I can't remember what it was exactly, but I got nervous and messed up somehow. Then I waited for 2 weeks just to hear back that they wanted someone more experienced with graph theory.

mjevans 7y ago
Expecting perfection on a white-board test is setting everyone up for failure. At best that's a large napkin exercise. Though having a failure, or a point where for whatever reason production is a bottleneck (if they happen to do it without obvious faults) is an opportunity to identify that either thing is the case in that section and move forward with how they'd react; what should be changed, etc. We're all still human; expect failure to happen. See what happens next.
- rjbwork 7y ago
  100% agree. I interviewed at Microsoft nearly a decade ago now. I was told I'd be interviewing for the company, and then if I was hired, based on preference and ability and need I'd be placed with a team When I got there I was told I'd be interviewing for the SQL Server team, interesting work, but not something I'm interested in. I had never taken operating systems in university because it was always available at a time that another class I HAD to take occurred. So by some random chance, I'd never heard of a semaphore. Perhaps inexcusable at this point in my career, but I was ignorant of the topic at that time. My first interview question was to write a way to let many readers on a resource, and only 1 writer, with no readers reading at the time of the writer writing. I decided to use lists of something or another, ProcessId, or something similar. Every time I would go to write the code, i'd get a few characters in, and the interviewer would interrupt me and ask me questions to help me along. Since I had no idea what a semaphore was, much less that I was supposed to use it, we spent like 30 minutes of this back and forth, me trying to write, him interrupting me. By the end of the session I had a single line initializing a list written. Some of my other interviews during that battery of interviews went better than that one for sure but, needless to say, I didn't get the job.

by rcfox 7y ago

mjevans 7y ago

Expecting perfection on a white-board test is setting everyone up for failure. At best that's a large napkin exercise. Though having a failure, or a point where for whatever reason production is a bottleneck (if they happen to do it without obvious faults) is an opportunity to identify that either thing is the case in that section and move forward with how they'd react; what should be changed, etc. We're all still human; expect failure to happen. See what happens next.

rjbwork 7y ago
100% agree. I interviewed at Microsoft nearly a decade ago now. I was told I'd be interviewing for the company, and then if I was hired, based on preference and ability and need I'd be placed with a team When I got there I was told I'd be interviewing for the SQL Server team, interesting work, but not something I'm interested in. I had never taken operating systems in university because it was always available at a time that another class I HAD to take occurred. So by some random chance, I'd never heard of a semaphore. Perhaps inexcusable at this point in my career, but I was ignorant of the topic at that time. My first interview question was to write a way to let many readers on a resource, and only 1 writer, with no readers reading at the time of the writer writing. I decided to use lists of something or another, ProcessId, or something similar. Every time I would go to write the code, i'd get a few characters in, and the interviewer would interrupt me and ask me questions to help me along. Since I had no idea what a semaphore was, much less that I was supposed to use it, we spent like 30 minutes of this back and forth, me trying to write, him interrupting me. By the end of the session I had a single line initializing a list written. Some of my other interviews during that battery of interviews went better than that one for sure but, needless to say, I didn't get the job.