I'm a week away from graduating from my coding bootcamp (yay!) and I've begun the process of job hunting. I've heard back from one of the companies...
For further actions, you may consider blocking this person and/or reporting abuse
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.
I did this recently. I'd say the biggest key is to remember that this is more about collaboration than getting the solution. It's a test of seeing how you will work with a member of the team and how you will interact with them to solve a problem. This is a proxy for your day to day collaboration with team members.
Show you are open to asking for help. Don't be afraid to ask them to write the code while you dictate for a while. Especially if they are experts in the challenge at hand. Part of being a good developer is recognizing which one of your teammates is awesome at something and getting their expertise on a problem. You might get knocked for not utilizing your partner to the max of their ability.
Hope this is helpful, best of luck!
Thank you Kyle! This is great advice and very reassuring as I feel so worried about getting the right solutions, as I'm still new to coding. Thank you again for feedback.
This is a great question. I've never done this, but I will say that from what I've heard it's a pretty good way of interviewing, so I'd take it as a sign of company that does things the right way.
Do you know what form the pairing is going to take? Are they going to have their hands on the keyboard or you? Or for that matter, what about this pair programming? Will you be working on the problems together or will they be setting you up and quizzing you?
edit: The distinction of pair programming vs other might not be entirely relevant.
In general for interviews, I'd suggest that you be confident, and show an interest in the technology they are using and technologies you might want to use in the future. Any time the interviewer displays their own passion for a subject, it's also worth asking questions and showing an interest in what they are into. Besides doing your best with the problem solving, showing a willingness to take on future challenges is a big plus.
I'm pretty thrilled it's not a whiteboard challenge! According to the email I received, it will be an hour of using CoderPad in which I'll be presented a couple of JavaScript-based programming questions. As I work through the questions, the interviewer and I will have a conversation about the problems to better understand my development style.
Cool, as Kyle answered, the best thing you can do in this environment is come in with an eye towards collaborating to find the answer and have a good back-and-forth as you go. Seems like you are preparing well specific challenge ahead, so you're already setting yourself up for success.
I work at a company that does a lot of pair programming in interviews and have been on both sides of this equation (several times as the interviewer).
When I am pair-programming with a potential hire, I am watching for two things:
1) Thought process. What happens if you encounter a bug? What if you don't know something? I have seen good and bad reactions to both of these situations. The worst reactions I tend to see are giving up, or trying changes at random until the code runs without understanding why. Some good reactions are along the lines of carefully using debugging tools, reasoning about the code, looking up documentation online, or asking their pair for input. In general I'm looking for signs that the candidate is reasoning their way along rather than flailing.
2) How you interact with me as a pair. Sometimes the person I am interviewing just wants to rabbit-hole on the problem and pretend I'm not there. That's not an automatic fault or an end to the interview or anything like that, especially if they're zipping along without issues. I understand that some people probably assume that the pair is just there to scrutinize them. But especially if they are getting stuck, I like to see that they are interacting and recognize that in addition to being an interviewer that I'm also a resource they can utilize. There are bonus points for people who explain their thought process as they're going along and really try to work with me as a pair and this can make the difference when we might otherwise be on the fence about a candidate based on technical ability alone.
This is a very interesting topic I find to ask. My first programming job involved me doing some pair programming with another person going for the same job as me, the point was they wanted to see how we worked in a team (we both got hired). We both agreed that before actually doing any form of programming we would get a plan sorted out on the topic they gave us, the language we would use, who would work in what area first then take it from there. After initially being given the topic we set to work with planning which didn't take long about an hour later bam we're done.
My advice would be don't be afraid to ask questions, or ask for help. Asking for help when stuck with an annoying bug or asking for advice on a piece of code is always great in the long run.
I'm guessing that the interviewer or someone from the company will be there with you to supervise. Try and pretend they are not there, having someone watching over you both can make you feel a bit pressured but of course if they ask or talk to you respond.
Thank you for the sound advice, George! I greatly appreciate it. I'm happy that you and the other candidate both got a job!
Most of the company today are practicing this method so that they can hire someone who is very well versed with programming concept and his/her technical competence is just phenomenal. To achieve this level of fineness at your programming you need to go for the hefty amount of mock interview practices.
Well I would suggest to go for MockRabbit to check your readiness and your programming ability. Here is the link to download the app goo.gl/Hpkp23