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

101–110 of 226 posts

Re: The problems with live coding interviews

#101

Post by JohnMakin »

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 reading and writing half a dozen languages of vastly different paradigms, and although I'm very proficient in many of them, I definitely need to reference things that maybe shouldn't "need" to be referenced (like confusing bash/python loop syntax is very common for me as an example). This rarely ever slows me down in reality, but will definitely cause me to fail interviews I shouldn't.

If I was an interviewer, I wouldn't care if a dev knew whatever esoteric language syntax or API calls by heart. I'd just expect them to know how to use them intelligently. The former does not always imply the latter.

Re: The problems with live coding interviews

#102

Post by kps »

whynotminot wrote: post #73
decafninja wrote: post #11

Earlier quoted context omitted.

There's also the issue of scalability. Grinding leetcode at least scales horizontally to a huge number of companies. Homework is typically useless outside of the single company you're doing it for. I generally refuse all takehome assignments unless: 1.) It sounds uniquely interesting and fun to do. 2.) The company is prestigious enough, or pays well enough, that making any effort to try to get the job worth it.

Why would you be interviewing at all if the criteria for (2) isn’t met? Unless you’re just trying to get interview practice or keeping them as a safety option.

Sometimes people just need a job (especially in the US, where jobs are so coupled to health care). I've been in that position, and I'm very glad I'm not now.

Re: The problems with live coding interviews

#103

Post by JohnMakin »

whoomp12342 wrote: post #81

If I do a live coding challenge, it is absurdly simple and is meant to root out people who have literally no business being in the room. Write a function that takes in a string and returns 1 if the amount of letters in the string is odd. It returns 0 if the amount of letters in the string is even. If you can do this, we are good. I dont need NP hard or whiteboarding or algorithms. I can tell how good you are just by…

the best fit jobs I've ever had have also taken this approach. Absurdly easy programming problem, then 95% talking about my background.

Re: The problems with live coding interviews

#104

Post by sintezcs »

I have a very simple rule that I’ve been following for years and it always worked for me. I ask a recruiter about the interview stages, and if I hear “live coding” I immediately decline this opportunity and switch to the next one. Eventually I was able to find really great places to work at, that made me happy for the next years.

Re: The problems with live coding interviews

#105

Post by kps »

eyear wrote: post #17

Google, Facebook, Amazon use it for a reason. And they are top engineering companies. Period.

I worked at one, alongside others who like me had gone through their (in)famous process, and alongside others who had not (they came via acquisitions). There was no difference.

Re: The problems with live coding interviews

#106

Post by OkayPhysicist »

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…

One of the better laid out interviews I had consisted of them pitching a problem prompt via email, followed by an hour and a half to complete the problem, followed by a ~30 minute code review. Realistically, the task was like a 20 minute job, so plenty of margin for stress-related slowdown. I think that's a happy medium between unbounded take home exams that monopolize your time, versus in-call leetcode whiteboard sessions.

Re: The problems with live coding interviews

#107

Post by fasterik »

bennyelv wrote: post #7

A perspective from the other side of the desk (playing devil's advocate here): There's a fundamental skill that a good programmer has to have, and that is to be able to take a novel problem that they haven't seen before and break it down to solve it in a sensible way. There are plenty of programmers who fake their way through a career without having that skill. They just copy stuff and never really understand it. The…

I think there's an analogy here to GRE scores and other standardized tests. With GRE scores you can predict someone's GPA, but you can't necessarily predict their success at doing original research. That's because success as a researcher depends on personality traits that are hard to measure like creativity, independence, self-discipline, perseverance, and passion about a subject.

Programming puzzles are the equivalent of the GRE for programming jobs. It might tell you something about the candidate, but I'm skeptical that it measures the most important traits and skills that really good programmers have. It's an empirical question, but your skill at solving programming puzzles might not predict your ability to systematically break down large problems, write readable, robust, well-documented code, or design and debug complex systems.

I also have my own theory about this which might just be my own personal bias. I feel like standardized tests encourage conformity in thinking. By relying on standardized tests, you are selecting for individuals who are primarily motivated by external measures of success and approval. On the flip side, you are selecting against individuals who are intrinsically motivated to learn and build things, but who may not care about those external factors. My theory is that organizations with too much of the former and too little of the latter are going to have issues with groupthink and will be less likely to be innovative.

Re: The problems with live coding interviews

#108

Post by Freire_Herval »

addaon wrote: post #91
Freire_Herval wrote: post #90

Earlier quoted context omitted.

if you can mutate the graph and mark a node as traversed that's the easiest way. If you can't then save the addresses to a hash set. Both are extra memory but you don't have to deal with "parallel BFS," which honestly is just over complicated imo. With "parallel bfs" comparing "layers" of traversal has runtime cost that effects the big oh so I think the above solution is better overall even though it feels cheap.

But the whole point of the "cute solution" is to solve with O(1) memory; if you're willing to allow O(n) then the linked list also admits more sane solutions. I'm not sure what you mean by comparing "layers" of traversal. Tortoise and hare is about provide a termination condition in the case that a cycle exists. In the case that there's no cycle, every algorithm must inspect each node, so is O(n). In both the linked…

> But the whole point of the "cute solution" is to solve with O(1) memory; if you're willing to allow O(n) then the linked list also admits more sane solutions.

Yeah but the "parallel BFS" solution is actually slower. Overall people sacrifice memory for speed in these algorithm problems.

Additionally the input is already O(N) so if you count the input as memory the addition of O(2N) doesn't shift it. If you don't count it well you're deliberately removing real world actuality and making the problem harder.

>I'm not sure what you mean by comparing "layers" of traversal. Tortoise and hare is about provide a termination condition in the case that a cycle exists. In the case that there's no cycle, every algorithm must inspect each node, so is O(n). In both the linked list and the DAG case, if there is at least one cycle, (a) both pointers will enter it in at most O(n) time, and they will match in at most O(n) additional time, so this stays big-oh optimal.

It's layer based traversal via BFS. You have to compare the layers produced by the tortoise and the hare. Let's see for a binary tree:

  For traversal: 
  hare: O(N)
  tortoise: O(N)
  There are N total nodes so traversal via bfs or dfs will always be N.
BFS traversal happens in layers of breadth. The height of a full binary tree is log2(N + 1) - 1. The length of the last layer is 2^height. So the amount of nodes in the last layer is (N+1)/2

Because at each stage of traversal from the turtle and the hare we have to compare the "layer" of traversal between the hare and the tortoise to see if they overlap there is a roughly O(((N+1)/2 )^ 2) comparison as we cycle through each node in the layer to see if it exists in the other layer being compared. This reduces to O(N^2) processing time.

So total is O(N^3) because you have O(N) traversal time, and O(N^2) comparison time on each traversal step. You can reduce the layer comparison to O(N) if you save one layer to a hashset and then compare that set to the other layer, but that has a memory cost and only reduces the total big O to O(N^2).

Re: The problems with live coding interviews

#109

Post by [deleted] »

traverseda wrote: post #82
whoomp12342 wrote: post #81

If I do a live coding challenge, it is absurdly simple and is meant to root out people who have literally no business being in the room. Write a function that takes in a string and returns 1 if the amount of letters in the string is odd. It returns 0 if the amount of letters in the string is even. If you can do this, we are good. I dont need NP hard or whiteboarding or algorithms. I can tell how good you are just by…

I can never remember how modulus works, I use it so infrequently.

[deleted]

Re: The problems with live coding interviews

#110

Post by whoomp12342 »

traverseda wrote: post #82
whoomp12342 wrote: post #81

If I do a live coding challenge, it is absurdly simple and is meant to root out people who have literally no business being in the room. Write a function that takes in a string and returns 1 if the amount of letters in the string is odd. It returns 0 if the amount of letters in the string is even. If you can do this, we are good. I dont need NP hard or whiteboarding or algorithms. I can tell how good you are just by…

I can never remember how modulus works, I use it so infrequently.

highly recommend learning how division works within assembly. If you can understand sending this data into registers, you will never forget how mod works. Honestly, I dont even care if you use modulus or not. Solve the problem within a function demonstrating you know CS101 concepts we are good. like, really. No judgement, this is just an idiot filter.
Post reply on HN