Being watched usually makes me a horrible coder. I get so distracted from having a backseat driver that it can even hard to type at times. The only thing I can whip up on the spot in a readable manner is something I already know pretty well, and if the interviewer can't keep up, it becomes a big conversation about "what are you doing again?"
It can be pretty hard to make a stranger feel at ease in a stressful situation so I can't pretend I have a 100% success rate, especially for the one screening interview we do which is a one hour pair programming exercise. However we do it, I am going to be there and look at what you are doing.
For the onsite though, most of the time, I explain the exercise and then I leave people work while I do something else in the same room.
I stay there so they can ask questions if they are stuck but I am not hovering over their shoulders so they can concentrate.
I'm not toot excited about the pairing part. Most pair interviews I've had feel like the interviewer is trying to shove a box that says "they arrived at the solution I like in the manner I was expecting". Most pairing feels like me going out of my way to connect with a robot interviewer w/ no imagination.
> For the onsite though, most of the time, I explain the exercise and then I leave people work while I do something else in the same room.
I love this. I'd love to see more interviewer's do this.
We try to make it easier and fairer with a rule like " if candidate reaches this step = automatic pass" (and the step in question is not that far in the interview).
But there are still many person to person differences and I often have dilemmas.
It is very hard to differentiate between giving a pointer and handholding the candidate.
So sometimes I ask myself if I gave too much or too little help, since there are cases where the candidate would have gone far enough with just a little bit more push and others where I feel that I helped them too much. On a 45 minutes exercise, if you help somebody not getting stuck for 10 minutes, it can make a difference.
Another part that make me uneasy is wondering if accents or culture differences can make me act differently. Like different micro expressions or attitudes from what I would expect, can these influence me enough to go from pass to no pass more easily for some ethnical/cultural groups ?
All in all it is a perilous exercise.
For me, it would possibly be preferred to algorithms because one of my strengths is reasoning about technologies. In group projects and when working with friends, I naturally take the pragmatic setup role.
Algorithms, on the other hand, I struggle with because even tonight at dinner my sister was trying to remember what word describes toxins moving up the food chain, something we learned 10 years ago.
Before she could finish her thought I was blurting out bio-magnification!
It made me think why do I remember some things so well and others really do go in one ear and out the other.
I know to an interviewer it may seem like they're testing if we have knowledge that will be applicable to the job at hand but to me, it feels arbitrary.
I am adaptable. I am not a textbook.
When I am on the other end of that table, I will have already asked for a portfolio of sorts: school work, personal projects, anything that you want to represent you.
I will spend some arbitrary amount of time finding code snippets that are problematic or interesting and I will ask you to speak to them.
I feel that will be enough to know whether or not I want you on my team.
> I will spend some arbitrary amount of time finding code snippets that are problematic or interesting and I will ask you to speak to them.
> I feel that will be enough to know whether or not I want you on my team.
I like your approach but wonder if I would be successful if looked at through that lens—I have looked back at code written a couple years ago and was surprised to find that I was the author and would definitely be unable to speak to my choices then (though I could probably speak to how I'd do it differently now, which might be a useful signal in the interview).
This doesn't make sense to me because once I become comfortable in a group, immediate stress isn't an issue anymore (background stress yes but that's another beast entirely).
I don't preform well while stressed, to the point that I pass out in acutely anxiety producing situations.
My test (which is really just more of a traditional behavioral interview) is looking for how you introspect and reason about design decisions that you've made in the past.
Something that I value in teammates over anything else.
It's a glimpse into how they will respond if I do have to ask them about why they did this or that in a merge request.
If you can reason about why you chose a foo over a bar 4 years ago then I'll feel pretty confident that you can speak to the decisions you made last week.
My thoughts will likely change as I get more industry experience but this is a good milestone for me to look back to.
It's not always easy to remember how it felt presenting your first programming project or landing your first technical interview. Or worse how it felt just before that stressful event.
We all have a tendency to think wow I guess I was so anxious over nothing. Is this what keeps the status quo in place ? Hindsight bias
I've always wanted to do this, but I couldn't convince any previously employers to pay for it.
+1. It is not that I don't know how to do it, but I have to practice beforehand to have it in my auto-pilot and not spend time during the interview. Otherwise I will panic seeing the clock ticking and my IDE freezing indexing files, etc.
This is something I need to study each time I want to change jobs. I suspect that I will have to create a new project somewhere in the interview process but it is just something I very rarely do in my day to day job, if ever. I suspect that it is the same for many engineers.
FWIW, at my current company, the interview projects come preconfigured, so you only have to import them and start coding. We have also already imported some popular libs.
Watching somebody rightfully struggle to do that is :
- a pain for the interviewee
- awkward and uninteresting for the interviewer .. I don't expect many people to have to create new projects often so it is totally ok to have forgotten it
- a waste of time for the both of us.
We also actually don't do algorithms.
We have a debugging interview, with a shitty codebase where you have to find the issues and correct them. When you are done with the bugs, you can collect your thoughts on what's wrong with that codebase so we can discuss how to do it better.
Another interview is to have to design a product similar to ours (a simplified version of course) and you have to come up with API and app technical designs.