Hacker News Reader

Comment by paxys | Hacker News Reader

This is exactly why the technical interview process is what it is. No point wasting time asking about backgrounds and describing past projects (all of it can be easily faked). Make them write code in front of you live as part of the screening round.

View on HN

The goal of an interview is to let great people through. It's not to see how well people code while you're watching their every keystroke.

I used to make people write code in front of me. I've missed out on some excellent candidates that don't perform at their best with that kind of pressure.

What I do now is ask people to share some code with me that they're proud of. Before the interview I look through it. Then on the call we'll have a quick talk through anything good or weird I've spotted. That helps me know if they've actually written it, and understand it.

Secondly I ask them to talk me through an interesting (to them) project they've worked. Then I dig into the how/why on project specifics to see how deep their understanding is. I tend to navigate to specifics that'll be important in the work I'm offering.

I also give candidates a heads up that that's what I'll be doing so they're not caught off guard. It's hard for them to know exactly the path of our conversation, but if they know what they've done and why they perform well.

With those tactics I've been able to hire some excellent engineers - several of which get quite anxious at the prospect of writing code in front of strangers.

> What I do now is ask people to share some code with me that they're proud of.

What if they dont have code to share?

Good question. That can happen - though it's usually for more junior roles. In that case I give them a take home task. The important thing here is that whether or not the result is good, I commit to talking it through with them (provided it works).

You might ask "why spend your time walking through code for a candidate that won't make it through?" Well, it's important for me that if people aren't a good fit for the role, they would be happy recommend us to people that they think are a good fit. Interviewing with that mindset ensures I (and my team) treat candidates like people, instead of like numbers.

In the spirit of the actual Ask HN though, I have had a small number of candidates that were deceptive, or difficult. In those cases it's just a polite but firm "I'm going to have to draw this call to close because <xyz /> and I don't want to string you along." Fortunately I've not had a person different to the interview show up on day 1 though... that'd be a little more awkward.

I don't like making people write code live. Some really good coders just don't work well with people looking over their shoulder.

I prefer giving people a take-home with an original problem to solve. Then, follow that up with a live call where you ask them some questions about it.

Yep, that's me. I feel like an experiment when people are watching what I'm doing, even if it's something as mundane as browsing the web.

I used to do a lot of work in an electronics lab that had a whole bunch of windows on one wall that looked out onto a hallway. That hallway was more or less the main passage through the building, so it was fairly high traffic. I used to tell people I felt like I was working in the engineer exhibit at the zoo.

i feel uncomfortable when people watch me browsing or worse reading email or the like, but not when coding. especially not when it's colleagues, since it is their project too

You can still be coached through a take-home and follow-up though.

I like to ask a very easy problem to start (some candidates spend the full 45 minutes on it) and then ask a similar problem after to build on it. If you work for a company there is some expectation of being able to work while people watch you. I don't like asking crazy dynamic programming problems, etc, but something simple and something slightly harder should be fine for someone who's good at their job.

> If you work for a company there is some expectation of being able to work while people watch you.

I don't know what kind of company you work for, but, in spite of the fact that every single technical interview I've ever had involved live coding, I've literally never had to write code in front of anyone at work. By "write code" I mean "write code that's expected to compile and run." I've done plenty of whiteboarding at work, but never anything like what happens in a technical interview.

you never had to work through some piece of code together with a team mate? to get help or to explain to them how something works?

That's not in any way comparable to live coding in an interview, for multiple reasons.

ok, you are right.

i brushed over this bit, which makes the critical difference:

write code that's expected to compile and run

for what it's worth, i never had an interview where this was required (except in a coding test, but that was without being watched while i worked on it) and to me it totally does not make sense especially for a whiteboard. making sure every semicolon or brace is in the right place would just be a colossal waste of time.

> You can still be coached through a take-home and follow-up though.

Of course. Anyone who lacks the ability to complete the assignment can submit a solution written by someone else and be told how it works. Where they’ll fail in follow-up questioning is when you dive into their decision making process.

I have only found one person to have cheated in an interview, and they were exceedingly easy to identify as a fraud when questioned in person.

Personally, when a company asks me to do a take home, I say no.

What do you prefer?

What’s your approach? I don’t like giving take home because it’s too easy to cheat, and ends up being an exhibition in how much excessive effort someone will put in. But, I think it’s great if you can have a second discussion so they can explain what they wrote.

I've found that candidates have little or non appetite for take home problems.

If they are busy interviewing, putting aside 2-3 hours (which is not much really) per interview, limits how many they are willing to do per week. As its still a candidate driven market.

Keep in mind, people have to find the spare time while doing their jobs and living life. If they have a family - good luck finding spare time :-)

The best win/win I've found is to pair with someone for about 30 minutes. You help each other, just like you do in real life.

They sometimes literally have a different person do the interview than shows up in person; no interview process catches that.

how about ID check? (if interview is conducted onsite in the office)

My understanding is that the scams usually target hiring processes that are all remote, often the applicants are from far away.

> Make them write code in front of you live as part of the screening round.

I think there's always lots of arguing over what's the correct way to do this.

Ideally, I think you'd basically have any number of options, from which you (the candidate) could pick whatever feels the most suitable:

  [ ] - solve an algorithmic problem in person, show code, discuss now
  [ ] - solve an algorithmic problem later, share Git repo, discuss later
  [ ] - solve a real world problem in person, show code, discuss now
  [ ] - solve a real world problem later, share Git repo, discuss later

That would solve the issue of person anxiety and time sensitivity - e.g. some people's nerves getting the best of them, even though it wouldn't solve the issue of someone else being able to do the task for them.

Then again, many companies/countries out there have a sort of grace period, for example, in Latvia that is 3 months - during which an employee's suitability for the work environment is assessed.

So, give them low priority issues to solve in non-core products, or even additional code tests to work on or prototypes to build, which should very quickly show whether they're suited or not.

More so, in some companies your salary during this period can be lower and the laws around quitting (or being fired) can also be more streamlined.

Of course, one could argue that some would exploit this to just rotate people after 3 months for low salaries, but I would at least hope that such attempts would be glaringly obvious and not much would get done in just 3 months of work.

> Of course, one could argue that some would exploit this to just rotate people after 3 months for low salaries, but I would at least hope that such attempts would be glaringly obvious and not much would get done in just 3 months of work.

As a candidate you should be able to detect easily during the interview that it would a bad place to work for.

The coding portion is the easiest to cheat on. I know because I interviewed someone who did cheat. She shared her screen with someone else and had someone talking her through the interview. Somehow the audio feeds crossed, and I heard the guy speaking.

The person on the other end is probably just googling keywords from whatever question you ask. You can throw them off by asking followup questions or adding new constraints.

> You can throw them off by asking followup questions or adding new constraints.

This only works if the helper couldn’t get the job. I just experienced one of these, and I don’t know what to do to protect us.

Yes, that's true. My company has made a number of questionable hires since the pandemic, when companies stopped doing in-person interviews. There will always be people who cheat but maybe requiring a few in-person interviews and imposing financial penalties will discourage this sort of behavior.

> who refuse to use their cameras during Zoom interviews and who often can't answer specific questions about their backgrounds.

Glad someone said this. Also most programmers and developers knows how tech works, they just don't want to be profiled by some AI algorithm. And why use Zoom, or any of close source, when you have jitsi to use for a video/voice chat?

Reply on news.ycombinator.com