Hacker News Reader

> Watching somebody rightfully struggle to do that is :

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?"

Yes! I learned this in my first internship when I froze up on the terminal because I had a manager hovering. It's something that comes up a lot in my circles. I did feel a little better when I eventually taught that same manager something about SSH. That excited "Oh you can do that??" felt so good.

That's something I try to alleviate.

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.

> the one screening interview we do which is a one hour pair programming exercise.

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.

Is the person you’re pairing with googling things and actively helping you? That interview style is fun because then you’re problem solving together and you can see how well you can communicate about complex technical subjects.

Pairing is hard. It is the part of our process that I like the less.

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.

Kudos for you trying to alleviate that, but from my past experience you are very the minority - most of the interviewers behave like '12 angry men' judges.

I even find it extraordinarily hard to type my password when there is any one else but me in the room.

Right! Whenever I am next someone about to type in their password, I forcefully look away so the person feel in peace to type in their passwords :)

I had never heard of this set up a project interview test. Sounds stressful and awkward but

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.

> 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 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).

Yes! That's what I'm getting at. It seems like technical interviews as I've experienced them (Microsoft being the biggest name I've tried so far) are knowledge based stress tests.

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

> 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.

I've always wanted to do this, but I couldn't convince any previously employers to pay for it.

> This is something I need to study each time I want to change jobs.

+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.

Codesandbox is amazing at pre configured projects for interviews.

I think a good way to gauge a persons tech ability is just have them sit with you for a debug session.