Hacker News Reader

Comment by stale2002 | Hacker News Reader

stale2002

LOL!

So your argument that what makes a person a good software engineer is the whiteboard coding algorithms?

That stuff is EASIER to learn than actual software engineering skills. All you got to do is spend a couple months cramming from the book cracking the code interview.

You learn that stuff in a singular CS class, that's called data structures and algorithms.

You are right about one thing though, if we are in a state where you can cram for your interview, that is a bad spot. And that is precisely the problem with the CS algorithms type questions!

The "hard" stuff in software engineering is about how you design maintainable code, how you design high level architecture, and generally all the skills that go into coding in a TEAM as opposed to be a programming superstar individual.

View on HN

> That stuff is EASIER to learn than actual software engineering skills. All you got to do is spend a couple months cramming from the book cracking the code interview.

You have got to be joking right? Not only is the intro-level algorithms class in universities a known-difficult class almost everywhere, MS and PhD students continue to try and discover better algorithms and new data structures.

Sure if you're working on a CRUD web app then it doesn't matter, but if you're working on Postgres, it sure as hell matters.

The PhD and MS stuff is not being asked in interviews. Yes, that stuff is hard.

Tech interviews are 40 minutes max. There is only so much stuff that can be asked and programmed in such a short amount of time.

The stuff being asked in tech interviews is "traverse a tree in this interesting way". There are only so many ways to traverse a tree.

And no, I am not talking about crud interviews, I am talking about Google interviews, and similar. (Although Google hits the very high end of difficulty, most interviews are much easier).

Perhaps there really is a way to do the mythical, problem solving, IQ test of a whiteboard programming interview. But that is NOT the way the industry does things currently.

The way that the industry currently works is that literally half of interview questions are almost word for word listed in cracking the code interview (I counted!). And the ones that aren't are still quite common.

When I did tech interviews with a dozen or so companies just recently, a full 90%! of interview questions were ones that I had been asked or studied before. Interviewers are lazy, and whiteboard algorithms as things are CURRENTLY is just about who can cram the most.

Tech interviews are 40 minutes max? Where are you interviewing?

I have seen far more 6+ hour interview loops that 40 minute ones.

Maybe each session within the full loop accounts for 40 minutes.

That being said, people have their pet questions they use to sort the wheat from the chaff--if you can't fizzbuzz your way out of a wet paper bag, I am not hiring you. The best questions are more about process than the final answer. Solve an easyish problem, add some features, add some more features. What other ways could you have solved that problem? Why did you choose this way? When would you use a different approach? How does your solution scale?

The worst questions are gotcha questions with a right and wrong answer, `what does the C99 standard indicate is the correct size of a stack frame?`

40 minutes as in 40 minutes of coding for a single interview question.

Usually 20 minutes out of a given hour long interview is just BS resume and chit chat.

And yes, there are often 5-6 interviews in a row. But that still leaves the fact that there is only so much that can be covered in an interview with 1 person in the 40 minutes you are given to code a problem.

And those 40 minute coding problems are all taken straight out of cracking the code interview, most of the time. Even at Google.

Process questions are good, and conversational interviews are also good. I wish people would do more of them. But unfortunately it is mostly just algo questions that you have to cram for.

> So your argument that what makes a person a good software engineer is the whiteboard coding algorithms?

No, his argument is that what makes a person a good software engineer is the ability to think about an abstract problem and come up with a solution to it.

I think you mean, think about a problem abstractly. However, a good abstraction is context specific, which is why it's often hard to deliver one in a interview, because the interviewer is both biased and a working against you.

That may be his argument, but his example is exactly the kind of "whiteboard coding algorithms" trivia that people mistake for engineering in this industry.

I'd agree with his argument if that's what it is, just not his example.

> I'd agree with his argument if that's what it is, just not his example.

I guess I wasn't very clear, then. The parent is correct, my argument did include: "ability to think about an abstract problem and come up with a solution to it."

I was trying to use a bit of brevity in my example but these responses make me believe I oversimplified an actual recent problem I had in mind (which is what I believe make the best interview questions). I do try to attach more business needs to the questions I've asked during interviews. Instead of:

"how would you store 1 million strings, search through them while caching results, and make sure only certain individuals can access certain strings"

What I really had in my head was: "We have tens of thousands of PDFs that we need to extract text from to make available. That text needs to be normalized. Only certain members of certain teams should have access to different types of text. Additionally, this is going to produce millions of strings. How would you get the PDFs to a place you could use them, extract the necessary text, normalize it, store it, utilize caching to make retrieving it snappy, and ensure correct access?"

Technical interviews should be more full of questions that spark conversations where additional inquiries come naturally. What kind of software? What version? What framework? Could you do that faster? And so on. Rattling off whiteboard questions is definitely what I was trying to make an example of avoiding.

Reply on news.ycombinator.com