I love building things, mostly with code.
Currently: Software Engineering Architect at Quip (Salesforce). Previously Attic Labs and a bunch of startups.
I have both given and been given interviews that involve a shared text editor like CoderPad - I've even used google docs for this.
Unfortunately, like all tech interviews, the experience varies quite greatly from company to company, or even interviewer to interviewer. That being said, here's what I've seen:
In my experience, CoderPad interviews aren't really "pair programming" as much as a way for them to look over your shoulder.
In fact, before CoderPad (or live updating text editors in general) were around, occasionally an in-person interviewer would hand me their laptop and just look over my shoulder. I like this more than whiteboarding and I suspect most interviewers are more trying to emulate this experience than judge your pair programming skills (of course this is just subjective experience though!)
A few things that might be helpful:
I have never been asked to (or asked a candidate to) actually run a program during an interview. I see the shared editor as a more comfortable environment to write down concepts, and a convenience for avoiding concepts easily lost when using the phone alone, not really "pair programming". Your interviewer may jump in and write things, but it's more like them holding the other whiteboard marker in an interview than them trying to solve a problem with you.
As a general interview tip (but especially for this environment where your mistakes will be extra obvious), be sure to talk the interviewer through what you're thinking about. Just literally say everything on your mind. When I'm on the other side of the table, I don't really care if you can solve the problem - anyone who has memorized fizzbuzz could pass if that were the case. I want to know how you think about it, even if you don't get close to a real solution. Nothing wrong with sitting there with a blinking cursor chatting about possible approaches, or writing sketches of pseudocode and talking through them.
There's likely a cultural component they're trying to learn here. They want to know what it would be like to pair program with you, even if you're not actually sharing the problem solving effort with your pair. So be friendly and transparent!
In this context, I would be very ok with (and encourage!) a candidate to ask questions. I've even popped open a tab and googled docs (while talking the interviewer through what I'm doing, of course) - in a best case, this format would allow them to be a fly on the wall during your normal process. After you get the job, you'll look up docs all the time! If your interviewer is trying to learn about how you work, they should be totally ok with you treating them like a co-worker (ask Qs) and using the resources of the internet to complete your task. FWIW, during whiteboards in the past I've just said "normally at this point I'd look up on MDN the sort docs, cause I can never remember what order the args are..." even if there's no computer nearby. Better than guessing or freezing!
I love building things, mostly with code.
Currently: Software Engineering Architect at Quip (Salesforce). Previously Attic Labs and a bunch of startups.
That depends quite a lot on the position you're interviewing for, but some general advice:
For Algorithm & Data structures questions, you're likely not going to be asked to implement something crazy, more likely they want to know you understand the basics.
Unfortunately, this translates to folks asking questions in technical terms (for instance, asking you what type of data structure to use, or explaining complexity in terms of big O notation).
Fortunately, Vaidehi Joshi writes an incredible series that explains this stuff in a wonderfully clear and understandable way: medium.com/basecs - I wish this existed when I was starting to get algorithm heavy interview questions, it would have saved me a lot of stress and feelings of inadequacy.
Lately I've seen a lot of focus more on practical application rather than general CS questions, which I am a fan of. For instance, you may be asked to explain a simple architecture of a twitter-like app, or the basics of implementing a scroll view. Or perhaps talk about how round-robin load balancer or rolling deployment strategy for a more operational role.
Lastly, remember that the interview is as much you interviewing them as it is them interviewing you. Preparation is good, but don't worry too much about learning concepts only tangentally related to your job. If you're going in for a ruby on rails position, brush up on RoR blog posts! If the interviewer decides that you need to write a sort algorithm in ruby, focus on the parts you're good at (syntax, organization, etc), and don't feel obligated to pretend to know stuff you don't know - let your skills shine bright and don't be afraid to let the interviewer know that your career focus may not be on the subject of the question.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I have both given and been given interviews that involve a shared text editor like CoderPad - I've even used google docs for this.
Unfortunately, like all tech interviews, the experience varies quite greatly from company to company, or even interviewer to interviewer. That being said, here's what I've seen:
In my experience, CoderPad interviews aren't really "pair programming" as much as a way for them to look over your shoulder.
In fact, before CoderPad (or live updating text editors in general) were around, occasionally an in-person interviewer would hand me their laptop and just look over my shoulder. I like this more than whiteboarding and I suspect most interviewers are more trying to emulate this experience than judge your pair programming skills (of course this is just subjective experience though!)
A few things that might be helpful:
I have never been asked to (or asked a candidate to) actually run a program during an interview. I see the shared editor as a more comfortable environment to write down concepts, and a convenience for avoiding concepts easily lost when using the phone alone, not really "pair programming". Your interviewer may jump in and write things, but it's more like them holding the other whiteboard marker in an interview than them trying to solve a problem with you.
As a general interview tip (but especially for this environment where your mistakes will be extra obvious), be sure to talk the interviewer through what you're thinking about. Just literally say everything on your mind. When I'm on the other side of the table, I don't really care if you can solve the problem - anyone who has memorized fizzbuzz could pass if that were the case. I want to know how you think about it, even if you don't get close to a real solution. Nothing wrong with sitting there with a blinking cursor chatting about possible approaches, or writing sketches of pseudocode and talking through them.
There's likely a cultural component they're trying to learn here. They want to know what it would be like to pair program with you, even if you're not actually sharing the problem solving effort with your pair. So be friendly and transparent!
In this context, I would be very ok with (and encourage!) a candidate to ask questions. I've even popped open a tab and googled docs (while talking the interviewer through what I'm doing, of course) - in a best case, this format would allow them to be a fly on the wall during your normal process. After you get the job, you'll look up docs all the time! If your interviewer is trying to learn about how you work, they should be totally ok with you treating them like a co-worker (ask Qs) and using the resources of the internet to complete your task. FWIW, during whiteboards in the past I've just said "normally at this point I'd look up on MDN the
sortdocs, cause I can never remember what order the args are..." even if there's no computer nearby. Better than guessing or freezing!Thank you Jesse for your insight! I really appreciate it. Do you recommend anything I should do to prep? Code Wars Katas? Data Structures? etc.
That depends quite a lot on the position you're interviewing for, but some general advice:
For Algorithm & Data structures questions, you're likely not going to be asked to implement something crazy, more likely they want to know you understand the basics.
Unfortunately, this translates to folks asking questions in technical terms (for instance, asking you what type of data structure to use, or explaining complexity in terms of big O notation).
Fortunately, Vaidehi Joshi writes an incredible series that explains this stuff in a wonderfully clear and understandable way: medium.com/basecs - I wish this existed when I was starting to get algorithm heavy interview questions, it would have saved me a lot of stress and feelings of inadequacy.
Lately I've seen a lot of focus more on practical application rather than general CS questions, which I am a fan of. For instance, you may be asked to explain a simple architecture of a twitter-like app, or the basics of implementing a scroll view. Or perhaps talk about how round-robin load balancer or rolling deployment strategy for a more operational role.
Lastly, remember that the interview is as much you interviewing them as it is them interviewing you. Preparation is good, but don't worry too much about learning concepts only tangentally related to your job. If you're going in for a ruby on rails position, brush up on RoR blog posts! If the interviewer decides that you need to write a sort algorithm in ruby, focus on the parts you're good at (syntax, organization, etc), and don't feel obligated to pretend to know stuff you don't know - let your skills shine bright and don't be afraid to let the interviewer know that your career focus may not be on the subject of the question.