3 ms·

Had an interview (one of my last formal interviews I ever did) back in 2002 where the developer gave me a computer, no internet access and Notepad (not Notepad+

Had an interview (one of my last formal interviews I ever did) back in 2002 where the developer gave me a computer, no internet access and Notepad (not Notepad++, or an IDE or anything decent) and said I had to write an entire generic double-linked list class in C++. Without access to documentation or a compiler. In a room. On a folding chair. Without a break. I had two hours to do it in. I cranked out around 1,100 lines of code. The interviewing developer was all smugness when looking through the code because he didn't like my bracketing style, or my variable style, and so on, and pissed and moaned because I had a couple of syntax errors in the entire class. I was offered the job. And I turned them down. I did it to prove I could do it. Then I walked away. That was pretty much my last ever formal interview.

arethuza 6y ago
I had a second interview about the same - was given a Linux PC in the corner of the office and asked to write a simple client server system in C++ that registered clients based on their MAC address. They left me alone for two or three hours and didn't speak to me and at the end I had a chat with the CTO about the code and he was happy enough and all was OK. The main bit to me was they left me alone - if someone had asked me anything, or even worse, watched me coding I would never have been able to do it.
- rleigh 6y ago
  Likewise. In one interview, I was given a short task to write some simple multithreaded C++ application before the interview. IIRC it was just a bunch of timers running in parallel to trigger events. During the onsite, they said here's the code you gave us, now here's a laptop, make it a client/server system in the next couple of hours. The time pressure didn't hurt. Had to remind myself about the order of all the necessary system calls on the client and server side to set up the sockets, listen and connect, define a suitable message format, and whatnot. But I had a working client and server talking to each other doing their thing. What I like about this style of interview is that it demonstrates your ability to be given a high-level problem and then go through requirements, design, implementation, testing then when given new requirements, iterate over the process to meet them. It's much more representative of day to day job requirements than a whiteboard. And being thrown that challenge shortly after coming onsite demonstrates that you can handle the pressure of being given new requirements and new tasks out of the blue and roll with it.
  - arethuza 6y ago
    Amusingly enough I wasn't being interviewed for a developers job - it was a jack of all trades Director of Engineering job. I didn't write a line of code when I worked there....

arethuza 6y ago

I had a second interview about the same - was given a Linux PC in the corner of the office and asked to write a simple client server system in C++ that registered clients based on their MAC address. They left me alone for two or three hours and didn't speak to me and at the end I had a chat with the CTO about the code and he was happy enough and all was OK. The main bit to me was they left me alone - if someone had asked me anything, or even worse, watched me coding I would never have been able to do it.

rleigh 6y ago
Likewise. In one interview, I was given a short task to write some simple multithreaded C++ application before the interview. IIRC it was just a bunch of timers running in parallel to trigger events. During the onsite, they said here's the code you gave us, now here's a laptop, make it a client/server system in the next couple of hours. The time pressure didn't hurt. Had to remind myself about the order of all the necessary system calls on the client and server side to set up the sockets, listen and connect, define a suitable message format, and whatnot. But I had a working client and server talking to each other doing their thing. What I like about this style of interview is that it demonstrates your ability to be given a high-level problem and then go through requirements, design, implementation, testing then when given new requirements, iterate over the process to meet them. It's much more representative of day to day job requirements than a whiteboard. And being thrown that challenge shortly after coming onsite demonstrates that you can handle the pressure of being given new requirements and new tasks out of the blue and roll with it.
- arethuza 6y ago
  Amusingly enough I wasn't being interviewed for a developers job - it was a jack of all trades Director of Engineering job. I didn't write a line of code when I worked there....