Live data from Hacker News

Stanford CS9: Problem-Solving for the CS Technical Interview

web.stanford.edu

221–230 of 292 posts

Re: Stanford CS9: Problem-Solving for the CS Technical Interview

#221
post #3

This is what I was afraid of. I always thought interviews were something where you present your abilities, experience and knowledge. It should not be something you "prepare" for because then you're not showing off your skills, instead you're just regurgitating what you are trained to do. I do somewhat blame the whiteboard culture, but I guess that's the one that has given the best results so far. I've no doubt that i…

Till today I haven't asked anyone to write actual code on whiteboard. Recently I had a chance to interview a Stanford grad who had previously worked on embedded sys in some start-up. I asked him to draw system level architecture of his product in OSI layer format like where HAL/ firmware, RTOS, insys mem, db, application, UI are placed and how they are communicating with each other ...and this guy was staring at me l…

I've never felt comfortable answering questions like those, because the designs are owned by the business. Even if I made it, I don't feel like I have the right to hand a design for my current employer to my next employer.

Re: Stanford CS9: Problem-Solving for the CS Technical Interview

#222
post #24

Earlier quoted context omitted.

I recently got a promotion to management. I have different responsibilities, but I get paid more and have more influence over solutions to interesting engineering and technical problems. This role feels even more like what my engineer friends in real engineering disciplines do than my role as Lead did: leverage their education and experience to solve complex, large scale problems. These interviews are good at testing…

Careful. Software engineering is very much a real engineering discipline, and it is a major cultural failing to not recognize it as such. Required viewing: https://www.youtube.com/watch?v=zDEpeWQHtFU

It should operate like a real engineering discipline. My point is in many ways it does not.

Re: Stanford CS9: Problem-Solving for the CS Technical Interview

#223
post #194
post #101

Earlier quoted context omitted.

I don't think these kind of coding interviews are given to average programmers though, and if they are I'm sure they are taken with a pinch of salt (or with a lot of help from the recruiter, or using simple tasks such as FizzBuzz [1]). In my experience, having been an average programmer (and maybe still being, I hope that by now I'm at least slightly above average) who worked in The Netherlands at a "system integrato…

FizzBuzz test is actually pretty great interview question, but most interviewers miss one crucial ingredient: time pressure. Original idea was that any competent programmer should be able to solve it in under 1 minute (only limiting factor being your own writing/typing speed). It is a good indicator of familiarity with the basic programming constructs (loops, conditionals, print statements). It's like writing down th…

I will highlight the most glaring problem I find in your take.

> FizzBuzz test is actually pretty great interview question [...] you should be able to do that without thinking

If you are going to code for me, I'm not interested in what you can do in 1 minute, I'm interested in what you can do in 1 year. I want you to spend more than 1 minute just thinking about any problem that is remotely worth solving. And that's the underlying problem: FizzBuzz is not representative of the problems I hire you to solve, and solving it fast is not representative of the approach I want you to take for solving the problems I hire you to solve.

FizzBuzz can be a reasonable point to start a conversation about approaches and style. But that's true of almost any piece of code - I used strcmp() for a number of years.

Re: Stanford CS9: Problem-Solving for the CS Technical Interview

#224
post #106

Just wait until you start interviewing at even crazier companies than FB/Google that would like you to tell them 20 ML algorithms, 20 computer vision algorithms, compare expected results of non-linear optimizations applied to some weird Deep Learning problem and analytically justify it (why is it worse/better than SGD on this loss function?), then off to some deep domain knowledge, conjure graph algorithms on the spo…

Sharing a data point: I've interviewed with Google multiple times and at no point during the interview was I asked a question that required an ML/CV/DL algorithm.

I suspect those would be more appropriate for a 'data scientist' / 'researcher' position - for a generalist, the interviews were very standard and not crazy at all.

In hindsight, if I had taken the time to review basic CS algorithms ahead of the interview, I would have done much better.

That said, I'm not sure I'd be a better employee at Google if the only difference between my being hired or not hired is the fact that I reviewed some basic data structures and algorithms.

Re: Stanford CS9: Problem-Solving for the CS Technical Interview

#225
post #123

Earlier quoted context omitted.

In design school, we had one class which involved things like developing your portfolio, learning how to present yourselves to companies, interviews with Creative Directors, etc. Given that technical interviews a common method of partially evaluating engineers/developers, it doesn't strike me as particularly odd for a practical course to exist that helps students maximize their ability to get a job. As you mentioned,…

I don't think most people have a problem with the class itself. It's more that the technical interview has gotten away from a practical method of showing what you know, and is now becoming a skill to maximize itself, whether or not it actually demonstrates if you can do the job. To take an absurd example, imagine if for some reason Law firms started requiring an Irish Stepdancing component to their hiring process. I'…

This isn't quite so far fetched as it seems. Perhaps someone tried the dancing thing to see how a candidate handles himself in an awkward position under pressure in front of people. They found some limited value in it and wrote a blog post about it. Then other law firms started using it. It became a way for such firms to assess a candidates emotional strength under pressure. And now law schools are offering a 1 credit course in "interview dance". Seems to be the perfect analogy to what's going on here ;-)

Re: Stanford CS9: Problem-Solving for the CS Technical Interview

#226
post #202

Earlier quoted context omitted.

> and their GitHub profile. I have nothing in my GitHub profile. Some toy repos of no particular significance, one contribution to Rust that I've made before realizing it takes too much of my spare time... and that's it. I don't think that should make me un-hireable ... people that have kids tend to not have much spare time besides work, learning new stuff to stay relevant, and taking care of said kids. Not to mentio…

Having less time to "learning new stuff to stay relevant" makes us de-facto less hirable. The "github" thingy is just a proxy (as is the "whiteboard CS exercise").

If you're not learning on the job you should probably find another one that's more challenging.

Re: Stanford CS9: Problem-Solving for the CS Technical Interview

#227
post #137

Earlier quoted context omitted.

The industry wouldn't look the same, either: it wouldn't be nearly as profitable or widespread as it has become, and nobody but CS academics would care about it.

On the other hand, perhaps the quality of code would go up?

I've been through an acquisition or two in my day (on the acquiring side). I'd echo knicholes' comment about that and go further: in my experience code quality and degree credential don't seem to have any relationship.

Re: Stanford CS9: Problem-Solving for the CS Technical Interview

#228
I trained for google and failed. Still it didn't feelt like stupid or a waste of time.

It was interessting to do so, i think it made me better and i will try it again.

And yes there are people who don't care enough to work for companies like google and there are.

Also while i did more interviews as the person who is interviewing: I feel that i like to have more better prepared people to interview.

Re: Stanford CS9: Problem-Solving for the CS Technical Interview

#229
post #64

Earlier quoted context omitted.

> FWIW, preparing for interviews is standard practice irrespective of the industry. This is simply wrong. I suppose if you've spent your whole life as a developer, it may seem like it would be done likewise other industries, but it's not the case. Typically, how you might "prepare" for interviews in other industries is...learning about your potential employer. And maybe reviewing your accomplishments. That's it. And…

Typically, how you might "prepare" for interviews in other industries is...learning about your potential employer. It has always shocked me that people don't instinctively think that doing this is an absolute necessity for every single job interview. I have very often been met with a totally blank look when I've asked candidates what they think it is the company I'm interviewing them for does, even when phrased as ni…

I would expect during an onsite that interviewers would want to tell the candidate about what the company does and why it is a great place to work. If you need to ask candidates those questions during an in-person interview then I recommend adjusting the filter prior to that step or consider that you might be getting blank stares for a couple of different reasons.

Re: Stanford CS9: Problem-Solving for the CS Technical Interview

#230

Earlier quoted context omitted.

Our industry also has quite a lot of self-taught professionals, who can perform as well as their college educated counterparts, which is something you won't really get in professions like Law or Medicine. I think that's a good thing, when it comes to software.

That implies CS degree is a hoax, which is not. The bootcamp style of skilled labour generation is possible simply because of the demand-supply gap.

I'd make a different point: the CS degree isn't a hoax, but it's not strictly necessary for software engineering work. In a real world application systems very quickly escape the boundaries of undergrad CS facts.
Post reply on HN