An Interview With

Making coding interviews more bearable.

Posted by Vaibhav Mallya on May 18, 2014
I learned about while researching the current crop of interview tools. What differentiates CoderPad from most of the others is that, in addition to showing the typed code in real-time, it also provides real-time code execution via REPL. This eliminates a common pain point during interviews (what I call the "I Can't Care If It Actually Compiles" problem). While it supports a large number of languages, it's not free - although that hasn't stopped people from using it.

Vincent Woo is the founder and sole employee of CoderPad. We're hanging out in the borrowed conference room of a downtown office building. It's been an unseasonably warm day for San Francisco, and we're both parched. After settling down, we load up a few pitchers of water and start chatting.
Vincent Woo - Bay native, soe founder, fan of unkempt hairstyles.

Vincent Woo

What inspired CoderPad?
I do a lot of interviews. It's actually one of my quirks. Even while I was working at Everlane, I interviewed for a lot of other positions. It's so much fun! I like talking about myself. I like trying to figure out the ins and outs of other people's hiring processes. I like seeing how people think. Interviews are stressful environments for both candidates and interviewers. I like applying pressure to the interviewer, and seeing how they react.

But, I found the phone screen experience lacking. I thought it was really archaic and bizarre that everyone was using Google Docs, or Etherpad, or Stypi to conduct technical phone screens. I was like, why don't I just take that, slap a compiler on it, and just see if I can use that myself in interviews, and I did! The v1 actually used a Ruby to JavaScript in-browser compiler to do just Ruby, and it was just good enough to work OK.
Did you write this yourself, or did you find some libraries?
I slapped a few libraries that I found together. There's this great, great project by the people, where they cross-compile Ruby 1.8.7 using Emscripten into JavaScript. They compiled the entire MRI Ruby binary from its C source code into JavaScript. It's several megabytes. Your browser hangs while it processes it, but once it's done you can run Ruby 1.8.7 in your browser. It's fantastic!

I also found these other crazy kids. They're in some midwestern schools, I forget. I'm doing them grave injustice by not remembering their names right now.

[Ed note: The project is Doppio by CJ Carey, Jez Ng, John Vilk, and Jonny Leahey.]

They wrote the entire JRE runtime in JavaScript! I was one of the first people to have live online Java compilation because I knew about these guys. They wrote their own JVM in JavaScript that you could download in the context of a browser! It was so slow. It was completely stupid, but at the time I thought there's no way I can ship without Java. No one will use this unless there's Java, right? I had a few dynamic languages, and Java, and that was it. I was looking for other ways to get more languages, and eventually I built my own server-side infrastructure, but at the time I was like, "How can I hack in Java right now?" It would take 10 seconds to compile and run "Hello World," but it was a glorious 10 seconds. Completely unusable, but it a lof of fun.
This was back in 2013?
Yeah, CoderPad's been live for about a year. One day I sucked it up and I just realized that there was no way I could scale this completely in-browser execution out as far as I needed it to. The insanity of it is apparent now. What are you going to do, compile every programming runtime into JavaScript? Good luck.
Some people would have liked that.
[we laugh]
Some people would have liked that and I would have liked that too if it was even remotely feasible. We're not in that age yet and there's all these other concerns, like various libraries and so forth. How do you dynamically pull those down? You can't do it. Basically you can't do it at scale right now. Anyway, I ended up transitioning it - the new code uses Docker.
Docker's great! It's been gaining a lot of popularity. Can you summarize it and talk about how you use it?
Docker is basically cgroups and linux containers sandboxing and standardization. You can restrict privileges. It's perhaps not as thorough as BSD's jailing, but Docker containers present this unified way to think about the world. That's the critical point with Docker. That's the genius innovation. In three years we're all going to be deploying software with Docker. We just don't know it yet. It's definitely coming. This is a tidal wave.
Docker aside, what else is being used?
What I love about CoderPad it's is a bleeding-edge project at literally every part of the stack. The front end is a crazy mishmash of JavaScript that basically lets you believe that you have a full console in your browser that you are sharing with someone else in real time. Either of you can Ctrl-C out of any program at any time. No one else has that, really. That is connected live through web sockets or some other real-time interface to one of my back-end servers that is running one of a dozen languages in a container shuttling input/output between a language runtime and all the clients connected to that pad instance. At the same time, I'm doing memory and input/output heuristics. So there's a lot of malicious behavior detection, sandboxing, memory limits, I/O limits, that sort of thing.
Vincent again, showcasing another unkempt hairstyle.

How far can you stretch your current setup? Does it, say, allow for running multi-threaded or multi-process programs?
Totally. Docker is actually very good at containerizing multiple processes per image. It's very flexible in this regard. A lot of other languages will run a compiler and then execute a binary. They do multi-step stuff. A lot of the other REPLs will execute this Ruby code and then shell me into a REPL instance with the same context as the code that I just ran. You can run some code with x=10 and then immediately after, CoderPad will give you a REPL where you can play with the value of x in real time. It's still 10. That' the magic. No one else really has this voodoo for maintaining state.

For instance, I have this MySQL mode. In MySQL mode, I have some default schema set up in MySQL database. I run the MySQL daemon and then I also run the MySQL CLI so that the user can play on a live MySQL CLI, querying a live data set in real time.
Have you seen any interesting or really novel use-cases from this?
I saw a guy program a videogame in CoderPad. It was a roguelike MMO -- text-based. He would interact with standard in and out to move his character around. He built the whole thing in CoderPad. This CoderPad was live for days. He just kept coming back to the tab and using the same code. Ordinarily I would say that a product like Nitrous.IO is much better suited to this application, but I've been really surprised at just how far people can take it. It can do pretty much anything that you need to do at this point. A lot of people use it for pair programming and tutoring. That's another big use case.
Has anyone broken through CoderPad's isolation yet - exhausting resources, assumed root, anything? Even though the processes are run in Docker, your monitoring seems to be a bit ad-hoc.
As far as I can tell, no one's managed to break CoderPad's isolation.
With the stack you've built so far, are you going to being focused on this narrow set of use-cases that you've figured out? Or do you want to do other stuff like, say, classroom-wide code execution guidance, general pairing, etc?
Let me tell you a funny story.

You know how one of the things that makes Stripe great is the quality of their documentation, right? Especially all their code examples. A lot of those are so good that you can actually paste them into an IRB console! But, I wondered - what if you could just hit a button and it would run all that code in the console, and you could see the output?

So I just went ahead and built it. I hacked together this static HTML page that connected to my back end. It looked nice. I broke into the Stripe holiday party, grabbed as many people as I could and made them look at it, and got their emails.They debated internally briefly, and they just told me "no." I never really figured out why.

That kind of hurt me inside a little bit as a person. Not really, I'm dramatizing. But I've wanted to revisit this idea because I think there's a lot of potential here for API-heavy companies who live and die by getting developers on board their platform to have more interactive API exploration.

I think there are some companies pursuing this - Runnable and Apiary, for example. But none of them have high-fidelity, real time experiences. You can't just hit a button and get dropped into a console. You could with CoderPad, of course.