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

Caltech's CS interview prep course

courses.cms.caltech.edu

Post reply on HN
Print view View original

311–320 of 336 posts

Re: Caltech's CS interview prep course

#311

Post by strikelaserclaw »

BalinKing wrote: post #273
hither_shores wrote: post #177

Earlier quoted context omitted.

> So wait you are smart enough to get into caltech, smart enough to graduate with a degree in CS... If you got B’s in caltech CS I’d make you an offer for 200k+ without blinking or even asking you anything. I went to Caltech and would definitely not do this. The CS faculty was fantastic, but the undergraduate option has some problems: - a wildly disproportionate share of cheating cases came from CS undergrads - CS gr…

Just out of curiosity, do you consider “$/effort optimizer” to be desirable or not?

obviously not, judging by his tone, people who optimize for money might only study leetcode. Algorithm skills probably account for at most 10-20% of the skills you need to become a good software engineer.

Re: Caltech's CS interview prep course

#312

Post by deltaonefour »

wittycardio wrote: post #306
deltaonefour wrote: post #181

I think the thing going on with interviews is that (most) of software engineering is actually pretty easy. Anyone can do the job outside of an interview session with the right experience. Note how I stressed the word (most). The interviews mostly serve to keep salaries high.

What you mean is basic web development is easy, software engineering is a much broader field than web development and there's lots of hard problems there. Even basic web development can get really complex with scale , I think the issue is people conflate being able to write a few lines of code with being a Good programmer. It's like saying writings easy because everyone knows how to write

I mean both. Web development is easy. But the majority of software development jobs are web development. A huge majority.

This majority makes it so that the broad statement of software development being easy mostly true.

Think about it in terms of availability of jobs over the breadth of engineering topics.

Re: Caltech's CS interview prep course

#313

Post by hnfong »

paradygm wrote: post #49
dvt wrote: post #3

If you don't think modern interviewing practices are a problem, this should be proof enough. Not only do we have an entire programming book sub-genre dedicated to this nonsense, but now we're also wasting class time on memorizing sorting algorithms. Fantastic. Of course, we're going to see the inevitable arguments that "40% of the people I interview lie on resumes" or "I interviewed this guy once, and he couldn't eve…

> I've told at least 5 or 6 companies that wanted to white-board me to suck it. It's honestly insulting that I'm forced to white-board when I have two books with my name on them (published by Apress), contributions to Golang (small commits, but they still got me in the AUTHORS file), and OSS projects with hundreds of stars on GitHub That is all commendable but none of that tells me if I can work with you. When I inte…

> I have never understood the hostility toward whiteboarding

If anything a candidate that rejects whiteboarding is a good signal that they're not a good team fit.

I personally prefer to conduct coding interviews in an environment where the code can be executed (if that's the main objection for "whiteboarding"), but even so the environment is often too different from what the interviewee is used to (IDE / availability of familiar libs / OS environment) that it's not that different from whiteboarding anyways.

In my personal experience there are indeed occasionally people that I'd recommend for strong hire with their past experience / credentials alone, but it's too rare to make any rule out of it, and if any candidate outright rejects it, it probably gives a signal that I'd personally interpret as negative anyways.

Re: Caltech's CS interview prep course

#314

Post by hnfong »

fermentation wrote: post #12

Sometime around my Junior year of college my goals shifted from "I'm here because I want to learn" to "I'm here because I want a job". I was surprised to find that doing well at learning (getting As) not only wasn't good enough for an entry level job, it wasn't even really correlated. The more time I spent on coursework the less time I had to grind through interview questions. I wonder if there are any other industri…

I think getting As correlates pretty well with grinding through interview questions. Perhaps not the same type of questions, but it's still "learning standardized skills from a prescribed area of study".

I don't think most algorithm interviews correlate with what you actually do on the job though. There's a lot more communication (eg trying to figure out what the boss/client/pm really wants, explaining non-trivial concepts to impatient/bored colleagues, or trying to convince other people that your "crazy" idea is actually sane), and a lot less hard problems thrown "in your face" (eg. prove that there is no solution for a^n + b^n = c^n where n > 2), but a lot more hidden traps that don't show themselves until something blows up in production (eg. turns out a minor version difference of python triggered a serious outage).

Re: Caltech's CS interview prep course

#315

Post by wittycardio »

deltaonefour wrote: post #312
wittycardio wrote: post #306

Earlier quoted context omitted.

What you mean is basic web development is easy, software engineering is a much broader field than web development and there's lots of hard problems there. Even basic web development can get really complex with scale , I think the issue is people conflate being able to write a few lines of code with being a Good programmer. It's like saying writings easy because everyone knows how to write

I mean both. Web development is easy. But the majority of software development jobs are web development. A huge majority. This majority makes it so that the broad statement of software development being easy mostly true. Think about it in terms of availability of jobs over the breadth of engineering topics.

The problem is that the way software works , every part of software interacts with every other part. Web apps use databases , compilers , networks and so on. Now ofc most of the time you won't need to understand the details behind those but it's good to understand them well enough to be able to if you need.

Re: Caltech's CS interview prep course

#316

Post by whimsicalism »

game_the0ry wrote: post #301
thaumasiotes wrote: post #284

Earlier quoted context omitted.

Having just passed Google's algorithmic interviews, and established a leetcode account specifically to prepare for that, I have a good record of how much leetcode I did: 3 easy problems, 4 medium problems, and 3 hard problems. It would make sense to count 2 additional hard problems that I worked on (with pencil and paper) but didn't submit a working solution for. This is more than four hours of work, but it's much le…

> (For example, my recruiter strongly believed that candidates needed a minimum of 5 weeks to prepare for an interview.) Your recruiter believes this for a reason and they have probably seen many candidates go through the process. Not saying you're a liar, but if you got into G with that little prep, I have some follow up questions: * Where did you level when you got your offer? L3 vs L4 vs L5 makes a big difference.…

I can answer for myself as GP, didn't interview with G but got into a similar company.

> L3 vs L4

Slightly above L3 would be the equivalent ($200-$260 salary band)

> * How many LC questions were you given per round? I would expect 2 is the norm.

6 interviews, 5 were technical -> 3 were algorithmic style, 2 were domain specific. Usually they had 2 questions, but really the first question was very easy and often related to the second one.

> * Did you have optimal solutions or were you nudged to a solution by the interviewer?

No clue, there was one I was struggling on because string parsing is annoying in C++. Not much nudging. I believe my solutions were generally pretty efficient.

> Did you pass any other FAANG / leetcode interviews?

Yes, the only other one I was in. I found actually getting interviews (as entry-level) to be much harder than passing the interviews once you got them.

> What's you educational background? Do you have computer science / STEM degree from MIT or similar?

Yes to the second and I did take a DS&A class in sophomore year of college.

> Did you crush the system design interview?

Probably was my weakest.

> How do you feel behavioral interviews went?

Well, I am good at talking.

Re: Caltech's CS interview prep course

#317

Post by game_the0ry »

ketzo wrote: post #235
game_the0ry wrote: post #108

Earlier quoted context omitted.

Bingo. It should be telling that there are a number of, usually for-profit, resources for prepping for just the interview process: * leetcode * Cracking the Coding Interview * Elements of Programing Interviews * Interview Kickstart, which costs like $5500, is a bootcamp just for passing interviews * educative.io * algoexpert.io That being said, I might just play along with the DS / Algo interview game. Having an inte…

I know you think you’re making a “cynical but rational” kind of argument here, but man, this comment is a huge fucking bummer. You’re acknowledging that you have the both the ability and the knowledge to change (your small part of) a shitty system, and instead you’re pulling up the ladder behind you. That sucks. You should not let yourself feel good about that, even if it’s “economically rational” or whatever. You’re…

You'll feel better when you see some of my other comments. I'll paste it here for you:

> What’s your suggested alternative? In my experience, any alternative to leetcode provides a better signal-to-noise ratio. You are better off asking trivia questions.

Additionally, this is the common narrative among leetcode advocates - "If no leetcode, then what?" As a hiring manager, you think harder and do better, that's what.

> Please remember that while some of us would do well and prefer some live pair programming or debugging sessions, it stresses the hell out of some folks and penalizes them unfairly.

So does leetcode. And a candidate that is truly a good fit for the role would be more at ease with the interview than if they saw a leetcode question they haven't seen before.

> Take home tests penalizes people with families and other responsibilities...

So does studying for leetcode for hours.

> ...and probably has a racial bias as well in countries where different races have different societal loads.

Share some sources before making a claim this ridiculous.

> In the end, even if these coding challenges might not reflect the actual work you do, they might still be predictive of success in the job, as much as any other method can be when we look for unbiased markers.

In my 6-ish years of experience, this is false. I have actually tested this theory in practice, and through my anecdotal experience, leetcode is a poor signal for job performance.

I can usually usually accurately screen a candidate for success in about 45 mins. And, unlike leetcode, you can't pretend like you haven't seen the question before, bc I can push the candidate to their limit, which is where you will find hire / no-hire signals. I love talking about this stuff, but I find that my peers engineering peers do not give a shit and would prefer to stay in leetcode hel

Re: Caltech's CS interview prep course

#318

Post by deltaonefour »

wittycardio wrote: post #315
deltaonefour wrote: post #312

Earlier quoted context omitted.

I mean both. Web development is easy. But the majority of software development jobs are web development. A huge majority. This majority makes it so that the broad statement of software development being easy mostly true. Think about it in terms of availability of jobs over the breadth of engineering topics.

The problem is that the way software works , every part of software interacts with every other part. Web apps use databases , compilers , networks and so on. Now ofc most of the time you won't need to understand the details behind those but it's good to understand them well enough to be able to if you need.

But this doesn't have anything to do with the topic at hand. Most jobs are easy but interviews filter for something very specific. Algorithms. Algorithm interview skill is largely different from even the details behind compilers and databases.

It's like competitive typing. Everyone can type. But interviewers filter for the best.

Re: Caltech's CS interview prep course

#319

Post by wittycardio »

deltaonefour wrote: post #318
wittycardio wrote: post #315

Earlier quoted context omitted.

The problem is that the way software works , every part of software interacts with every other part. Web apps use databases , compilers , networks and so on. Now ofc most of the time you won't need to understand the details behind those but it's good to understand them well enough to be able to if you need.

But this doesn't have anything to do with the topic at hand. Most jobs are easy but interviews filter for something very specific. Algorithms. Algorithm interview skill is largely different from even the details behind compilers and databases. It's like competitive typing. Everyone can type. But interviewers filter for the best.

I think algorithms allow you to pick up all of those other things more quickly. I'm not saying that the interviews are a perfect way to measure this , but a good understanding of algorithms is really useful to understand any software

Re: Caltech's CS interview prep course

#320

Post by jltsiren »

lmm wrote: post #294
jltsiren wrote: post #253

Earlier quoted context omitted.

Algorithm design is a skill you can learn. It probably correlates with IQ, but you have to control for experience to see it. Experience is certainly more important than intelligence. In my experience, algorithm design is primarily pattern matching. You have a toolkit with a set of abstractions for modeling the problem and a set of algorithmic techniques for solving it. If you have the right tools in the toolkit, pote…

> primarily pattern matching. You have a toolkit with a set of abstractions for modeling the problem and a set of algorithmic techniques for solving it. If you have the right tools in the toolkit, potential solutions will jump out. You then pick a promising solution and figure out the details. If you don't have the right tools, you have to go back to reading or start building new tools from basic principles. That can…

Intelligence is usually understood as a relatively fixed factor that cannot be trained effectively. Algorithm design is mostly about the patterns you already know.
Post reply on HN