Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The problems with live coding interviews

garrettdimon.com

Post reply on HN
Print view View original

131–140 of 226 posts

Re: The problems with live coding interviews

#131

Post by emodendroket »

anongraddebt wrote: post #113
emodendroket wrote: post #74

Earlier quoted context omitted.

Well if I have two openings and five people what way do you think is more fair to choose among them?

On average, any random company will be filled with solidly average engineers. Which means, because of how numbers work, most of the engineers are neither good nor bad at engineering. They’re just mediocre. Companies need to realize this and come to grips with it. Additionally, this holds as well for the following: beyond a certain skill threshold, a company will not really be any less competitive by failing to hire t…

OK. How does this answer my question, since presumably I would still want to identify at least the mediocrities rather than the complete jokers who have nothing to contribute?

Re: The problems with live coding interviews

#132

Post by vparikh »

I have been in the software industry for 30 years as of this month. I have never had a gap of longer then 6 months and the shortest time with a company was 4 years 8 months and the longest time was 16 years. I have worked on the following technoclogies. Companies range from on of the Big 3 consulting firms to startups. Here are the technologies I have worked on

- C/C++ on Win16/Win32

- Assembly language development with Z80/8051/ARM on embedded microcontrollers

- Java (core java, Servlets, J2EE)

- Ruby on Rails

- NodeJS / Javascript

- Worked with AWS tech (the full stack)

- Relational DB (MsSQL, PostGres, MySql), NoSQL db (MonoDB)

- Coded for Linux/Unix, MacOS, Windows 16/32, PalmOS, iOS

I can provide reference for each of those skillsets form my past colleagues.

You know what - I probably couldn't pass half of the insane coding puzzles these interviewers throw out. Not because I can't solve them, I just don't remember enough of the syntax or library semantics of the top of my head.

At my experience can we just assume that I am a competent coder (maybe not the top 1%, but at least in the top %20) and talk about the job and how I can contribute ? I mean its almost insulting if you ask me to make a linked list/reverse a binary tree or other such nonsense looking over my shoulder me with a time limit.

Re: The problems with live coding interviews

#133

Post by frumper »

hnfong wrote: post #114
oceanplexian wrote: post #77

Earlier quoted context omitted.

> All things equal, if you can complete the problem in 10 minutes and the company can hire somebody that can complete it in 9, then objectively the other candidate is the stronger one. They are stronger in the specific problem space you’re testing for. If your business has a lot of novel coding problems that need to be solved in under 9 minutes, then sure, this is a great measurement. On the other hand, if your busin…

> if your business has a lot of hard problems that take days, weeks, or quarters to solve I suppose your ideal interview as an interviewer would be to give the candidate a take home task and ask them to spend 2 weeks to work on it? > If anything it’s a counter signal Or perhaps give the candidate a task that normally takes 30 minutes, and hire the candidate if they take 60 mins to finish it? I mean, you do you, but I…

No, the ideal interview is to ask them questions about what type of problems they've solved before and ask them to walk through what they did. Also, have a conversation with the person to get to know a little bit about what they're looking for in a job/company. It's an interview, not a tryout.

Metrics like a 10 minute task, or a 30 minute task is all relative. Do they know they language, the IDE, the operating system, the documentation, any experience in whatever abstract problem topic you choose, and personal comfort levels will all come into play.

If you want to filter someone to do a very specific thing then post to hire a contractor with the specifics of what you need. If you want a developer that can grow within your organization then pop quizzes area good way to dismiss good candidates.

Re: The problems with live coding interviews

#134

Post by blurbleblurble »

Recently I took a leetcode screening, my first ever, and failed to complete one single question in the allotted time due to a minor panic attack and a sudden loss of focus. The whole time I couldn't help but think about the state of the economy and how "this is it, this is my only chance." Half the time I was fighting with the in-browser IDE and struggling to remember names of JavaScript builtins that usually come easy.

Immediately after the time was up I magically started to realize how much I'd over complicated my one almost finished answer and quickly came up with much more efficient answer. Suddenly it started clicking how simple the first two problems were and how easy it would have been to crank them out if I wasn't panicking about the tech bubble collapse.

The recruiter later asked me how it went and I grumbled something about how it was a leetcode test. He said "oh well they need to make sure you have the skills for the job." At that point I was over the whole thing and honestly pretty fired up.

Over the next week I proved to myself that I do have the technical skills for that job, and that's honestly what counts.

¯ \ _ ( ツ ) _ / ¯

Re: The problems with live coding interviews

#135

Post by sneed_chucker »

JohnMakin wrote: post #101

Well stated. I seem like the exact type of dev as described in this blog post - I get performance anxiety and the audited interview process doesn't fit my particular style. I wouldn't describe myself as slow, but my steps to solving a problem are often not linear and sometimes difficult to measure in such a setting. as a devops engineer as my main job, I also try to explain to interviewers that on any given day I am…

For what it's worth, I do interviews for my employer and we allow candidates to use Google during the coding interview as long as they screen share their browser window.

An impressive number of people still fail the interview despite the questions being pretty simple (in leetcode terms, probably on the easier side of medium).

Re: The problems with live coding interviews

#136

Post by RandallBrown »

uptown wrote: post #24

I’ve never tried this exactly, but I wonder how “live coding” interviews might go if the interviewer was the one doing the typing/coding and the candidate’s role was to verbalize what the interviewer was doing (and why) - and also guide them to some degree. It’d be more akin to pair-programming, which some of the interviews I’ve conducted have evolved into, depending on the strength of the candidates. Would that capt…

This is exactly how a company I used to work at interviewed. We did all the typing to remove that layer of stress and focus on their problem solving ability. It worked extremely well.

Re: The problems with live coding interviews

#137

Post by dieselgate »

vparikh wrote: post #132

I have been in the software industry for 30 years as of this month. I have never had a gap of longer then 6 months and the shortest time with a company was 4 years 8 months and the longest time was 16 years. I have worked on the following technoclogies. Companies range from on of the Big 3 consulting firms to startups. Here are the technologies I have worked on - C/C++ on Win16/Win32 - Assembly language development w…

Makes me think of the quip along the lines “the expert has forgotten more than the beginner knows”

Re: The problems with live coding interviews

#138

Post by RandallBrown »

lucisferre wrote: post #14

This presents as a bit of an unintentional strawman against demonstrating any kind of coding during an interview process. Live coding, if earnestly used only as a filter, does not inherently need to focus on speed or performance. It doesn't have to be a hard "galaxy-brain" problem. It doesn't have to have any tricks to it. It can literally be a simple task that one would expect any working software developer to be ab…

> It can literally be a simple task that one would expect any working software developer to be able to complete without too much fuss.

Unfortunately this varies dramatically from person to person during a high pressure interview.

I interviewed a very senior developer once that actually used to be my current manager's boss. The coding question was pretty simple and most people didn't struggle too much with it. He BOMBED it. Like, you could have taken someone with 30 minutes of coding experience and they would have gotten as far as he did.

It was also very obvious he was just incredibly nervous so I put him through to the next round anyway. We hired him and he was great.

Re: The problems with live coding interviews

#139

Post by AbsoluteCabbage »

goostavos wrote: post #43
commandlinefan wrote: post #35

Earlier quoted context omitted.

The point that's often overlooked by people who complain about any sort of interviewing process (this one being an example) is: somebody _does_ pass the interview, eventually, or they change the process. The poster here seems to be suggesting that live coding is an impossible hurdle that nobody can overcome, but that's obviously not true - people overcome it and get hired all the time. I've auditioned as a musician i…

>hey just went with somebody better Yeaaaaah, that's not how any of this works. I've done 100+ interviews for MegaCorp. Who ultimately gets hired is ultimately a dice roll no matter how "data driven" we call it. Did you get a good loop? Was one of your interviewers in a bad mood? Did you end up with a hiring manager who "used to code" and now measures everyone against whether or not they use out dated OOP techniques…

Flashbacks to losing out on a dream job because the husband and wife interviewers had a nasty argument after a long plane flight right before the interview. Sigh.

Re: The problems with live coding interviews

#140

Post by frumper »

viraptor wrote: post #41
kayo_20211030 wrote: post #2

Your experience sounds horrible, and unfortunately those sort of "tests" are just a horrible thing. Generally, do NOT do take-home exercises. That's your time, which has value; the company doing the hiring contributes nothing. At least, in a live-coding exercise both you and they have some skin in the game. As with all tests, good or bad, part of the test is actually doing the test. Often it's less what you know, or…

> Often it's less what you know, or could do; and more about "can you do the test?" It really depends on how you create the test and how you review it. You can prepare one where the actual solution is 10 lines of code and anything else is exactly for showing what the candidate knows / could do. I used something like "read data from CSV, write it to sqlite, treat it like a mature production app, feel free to use place…

Your test sounds like what people complain about. You give them instructions but it's "really about ... ". Just ask them what you want them to know. If you hired this person and they turned in code without error recovery or encoding, you'd tell them they need to add it and they would. No need to obfuscate your intentions and have them read your mind in what you're looking for.

No take home test is even needed. A simple conversation would let you know if they understand the importance of those things.

Post reply on HN