An Algorithm for Passing Programming Interviews (2020) • Hacker News Board

Re: An Algorithm for Passing Programming Interviews (2020)

#291

Post by aix1 » Mon, Jan 03, 2022, 2:14 PM UTC

simplestats wrote: post #114

aix1 wrote: post #28

Earlier quoted context omitted.

> In my experience, interviewers will rarely tell you the runtime of the optimal solution. I agree. As an interviewer, I genuinely want each candidate to do well and I think that, on balance, setting a specific complexity goal is likely to do more harm that good. For a strong candidate, it could limit their opportunity to shine by narrowing down the solution space and discouraging them from exploring tradeoffs (e.g.…

In my experience, "no solution at all" is already the default. When people choke on questions it is because they get stuck trying to guess at what you want, and panic thinking it must be some clever trick they don't recognize. Becasue we've all seen a million tricks and forgotten most of them. If you're happy with just getting it done quick and dirty, at least as a start, then telling them so is obviously better than…

I don't ask questions that can only be solved with some clever trick. In my experience, I get the most signal by posing a question that has many solutions of varying degrees of efficiency.

This way anyone except the least qualified candidates can make some meaningful progress. I then gently guide the candidate to help them produce the best solution they're capable of in the allotted time.

I then score the interview on the basis of where they have landed, the process by which they got there and how much help they needed along the way (and of course the role/level they're interviewing for).

Re: An Algorithm for Passing Programming Interviews (2020)

#292

Post by lkxijlewlf » Mon, Jan 03, 2022, 2:16 PM UTC

cleverwebble wrote: post #134

o10449366 wrote: post #95

Earlier quoted context omitted.

No, if you really want to game it you sign up for membership on Chinese forums where people post the questions word for word minutes after completing the interview. That or work exclusively with private recruiters that tell you the questions verbatim because they have a vested interest in you passing. Interview questions don't rotate that frequently, especially for smaller companies or more specialized roles, and a $…

As an interviewer, this is so incredibly frustrating - we don't change our questions often and because of that the questions and answers are all over these forums. With that said, it is incredibly easy to spot someone cheating - they often write the most perfect optimal solution from start to finish, helper functions first, often with the same function names as the forums themselves. The trick I've learned is to ask…

Why are they "cheaters"? If candidates are supposed to study LC to pass a stupid interview, why get all pissy when they do exactly that?

Re: An Algorithm for Passing Programming Interviews (2020)

#293

Post by ironman1478 » Mon, Jan 03, 2022, 2:17 PM UTC

tubby12345 wrote: post #88

gopher_space wrote: post #78

Earlier quoted context omitted.

It's a great way for second-raters to grind their stats instead of actually building something.

>second-raters to grind their stats so sayeth the people on the outside of companies building the most complex software in the world.

Most of the engineers at those companies (and really all companies) don't work on those projects. Some people work on truly complex projects, but those people are a tiny fraction of the entire workforce. It wouldn't even make sense for a company to allocate people that way.

Also, I'd contest the statement that Google or Facebook works on the most complex software. They don't work in fintech, medical, hard real time that I know of (waymo does, but they've been spun out), and many many more fields of SW, HW and CS.

They work on hard stuff, but don't discount the complexity that other companies deal with.

Re: An Algorithm for Passing Programming Interviews (2020)

#294

Post by bryanrasmussen » Mon, Jan 03, 2022, 2:21 PM UTC

o10449366 wrote: post #264

bryanrasmussen wrote: post #250

Earlier quoted context omitted.

Hey I have some suggestions to how you can improve this process that, having passed through it myself, obviously has some inefficiencies! -hmm, well that wouldn't be very ethical would it. Guess we'll just have to leave things not working very well.

I can't speak for them, but I would assume that jsiaajdsdaa still considered themselves qualified for their positions - even if they employed ethically questionable methods for passing the interviews. In the end isn't that all that matters given that's what these interviews are supposedly trying to measure? What part of jsiaajdsdaa's process do you think is more efficient? To me it sounds less objective ("the goal is…

I think as a general rule the idea that you give someone something that they are unlikely to solve because they are not completely familiar with the problem space does measure some things well - specifically, how one performs with something new and unknown (a critical programming skill) and their ability to abstractly reason as opposed to having memorized some information.

Although for other things related to the job not that useful.

That said I was talking about your comment that it was somewhat unethical; they didn't so much think that they gamed the system but that the system was so inefficient at doing what it should do that someone had to fit themselves to the system to get in.

Re: An Algorithm for Passing Programming Interviews (2020)

#295

Post by gsliepen » Mon, Jan 03, 2022, 2:23 PM UTC

GistNoesis wrote: post #103

sk5t wrote: post #22

Earlier quoted context omitted.

The solution described in the article is likely to be extremely wasteful in both time and memory, by allocating a queue entry for each call, and then O(n) scanning and dropping stale entries on each successive call. Tabulating call count by division(s) of time would be less obviously problematic.

How bad is the code I want to write even though I know it is wrong : initialize : double credit = N At every request : penalty = (elapsedTime / window_size) - (1/N) gain = N* (elapsedTime / window_size) credit = min( credit + gain - (penalty if( credit < 0 ) throw exception

I wouldn't call it penalty, but cost, and if credit = N, then I assume the cost of one call would just be 1. So:

    gain = N * (elapsedTime / window_size);
    credit = min(credit + gain, N);
    if (credit >= 1) {
        credit--;
        log(...);
    } else {
        return; /* not enough credits */
    }

Your approach has the nice property that after the initial burst, you get regularly spread out log messages, whereas the linked list approach will stay bursty.

Re: An Algorithm for Passing Programming Interviews (2020)

#296

Post by PUSH_AX » Mon, Jan 03, 2022, 2:33 PM UTC

shinazueli wrote: post #199

renewiltord wrote: post #138

Earlier quoted context omitted.

Google translate is sufficient. They’ll do it pretty carefully, complete with “pretend you get stuck at this specific point and if you get asked why to use a hashmap, act baffled for a moment, and then say X”

It’s ridiculously obvious when people have seen the question before. The way we do it is like this: we have like 3 or 4 different small variations on each question. Such that the solution is measurably different, in quite telling ways, but that the given problem looks almost identical. In one specific case the given is identical, but there are 3 variations to the question based on how the candidate asks questions abo…

> It’s an arms race. And one that I enjoy.

Objectively, a waste of everyones time and energy is what it is.

Re: An Algorithm for Passing Programming Interviews (2020)

#297

Post by quasiprime » Mon, Jan 03, 2022, 2:42 PM UTC

o10449366 wrote: post #105

andrew_ wrote: post #99

Or don't agree to interviews that include algo challenges, leetcode/hackerrank nonsense, array shuffling shenanigans. Choose companies that put thought into their evaluations.

Just my $0.02: I'd much rather spend a few weeks refreshing basic data structures and algorithms than doing the "non-algo" challenges I've gotten because they feel way less objective than getting questions where there's a correct answer. Most of the time the alternative to non-algorithm questions is some form of take home assignment that's usually multiple hours long and that you get no feedback on or chance to corre…

On one hand I like take-home exercises because they are closer to what is a real world job and I guarantee the quality of my deliveries. Up to now I can say I've passed every single take home exercise that was thrown at me. On the other hand... the time I spent on those is abysmal. If I sum it up, I must have spent over a month working on take-home exercises. And even if I passed all of them, in the end no company gave me an offer because I wasn't a cultural fit or something. One company even ghosted me after having me to do a 1-week take-home exercise where I had to build an entire app, front end and back end, that consumed an open data API that had 1 million rows.

I still prefer take-home exercises because are more realistic and make more sense than timed, algorithmic exercises. But I wish companies would do their cultural fitness thing _before_ having candidates to spend their time on their code challenges.

Re: An Algorithm for Passing Programming Interviews (2020)

#298

Post by nefitty » Mon, Jan 03, 2022, 2:55 PM UTC

PUSH_AX wrote: post #296

shinazueli wrote: post #199

Earlier quoted context omitted.

It’s ridiculously obvious when people have seen the question before. The way we do it is like this: we have like 3 or 4 different small variations on each question. Such that the solution is measurably different, in quite telling ways, but that the given problem looks almost identical. In one specific case the given is identical, but there are 3 variations to the question based on how the candidate asks questions abo…

> It’s an arms race. And one that I enjoy. Objectively, a waste of everyones time and energy is what it is.

The lack of self-awareness shown by this interviewer is staggering. You're right, they seem to relish wasting their (paid) and applicants' (unpaid) time. I won't hold my tongue. The people that do this are total assholes, if not downright sociopaths.

Re: An Algorithm for Passing Programming Interviews (2020)

#299

Post by electriccatblan » Mon, Jan 03, 2022, 3:06 PM UTC

kache_ wrote: post #290

sydthrowaway wrote: post #256

Earlier quoted context omitted.

Whats your technique?

3 hours of leetcode every day for 1.5 months 6 hours of sys design over the weekend for 1.5 months

How did you practice system design? Did you work from problem sets or just study principles?

Re: An Algorithm for Passing Programming Interviews (2020)

#300

Post by kache_ » Mon, Jan 03, 2022, 3:07 PM UTC

titanomachy wrote: post #81

kache_ wrote: post #71

Earlier quoted context omitted.

When gaming it is just passing by studying, a repeatable process that anyone (with a CS degree) can do, just means the interview process is quite well designed. The interview process is a test of endurance, not intelligence. And it should be exactly that, since software engineering is mostly an exercise of endurance and focus. Every time a friend of mine QQs about failing a FANG interview, I give them the study presc…

I don’t know if it’s as useful a signal as you imply. For me, it’s easy to be motivated studying leetcode: small, self-contained puzzles with just the right amount of challenge and immediate gratification. Actually doing a FAANG job can be a slog where it takes months to see results from your work. I can get hired as a software engineer wherever, but I’m only mediocre at doing the job. I’m not the only person I know…

you're not mediocre at the job. Trust me, you haven't seen mediocre