Hacker News Reader

> When there's no difference between cramming for your History 101 mid-term and a technical interview for a software developer, we're not in a good spot.

Your "1 million strings" example is exactly the kind of thing that can be memorized, and is actually a quite common class of interview questions in certain segments of this industry. It's also only tangentially related to engineering. If I may, I'd draw an analogy with engineering a satellite system: your "million strings" example is more like the act of selecting a bolt from a catalog that fits the spec than it is engineering the spec in the first place.

Which is fine because something like searching through a million strings is very much an actual problem that would be faced on-the-job -- usually the spec is already written and handed to you by your manager -- and we can all agree that being able to recall obscure syntactical knowledge or invert a binary tree are things that, while commonly asked in whiteboard interviews, aren't something an actual software engineer would ever be faced with in their daily work.

> No, recruiters all over the world are paying hundreds of thousands of dollars a year because they can't find any competent programmers anymore.

They pay it because they can't identify and source competent programmers, not because there aren't enough. Thus, when they (think they) find one they pay through the nose for it.

> Being a good software developer has absolutely nothing to do with "important entrepreneurial tech skills." Knowing how to tackle problems, envision loops and algorithms, write pseudocode, understand the basics of how requests on the Internet work, or how your computer accesses databases or files; these are skills of a good software developer.

I disagree. Knowing where to apply your skills at a company is just as important as having those skills. If your stakeholders aren't happy, it doesn't matter how beautiful the code is. You've failed to deliver. That being said, it's a balance you have to strike. You can't just focus entirely on making stakeholders happy, other wise you'd have a patchwork quilt of an application.

Also, that's why I like side projects, you're the stakeholder and can focus on the tech/what you think is important.

Bootcamps are not going away, there just won't be so many of them any more. As another poster said, the market is correcting itself.

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.

> 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.