Comment by rambossa | Hacker News Reader

Comment by rambossa | Hacker News Reader

Parent Full thread

Side note/rant: I hate the Cracking the Coding Interview style... studying for these type of interviews is annoying. Trying to find a good video on youtube, where they aren't just naively coding up the bruteForce->optimal possible solutions, especially is irritating. It is literally a landscape of college kids with thousands of viewers who treat these interviews like the SAT. Even the author of the book produces videos with very little insight or meaningful content.

"Find all the subsets in a set that add up to sum" -- "Okay for this we will use the sliding window technique and here is how it is done" -- WTF is this. I get that they want to see problem-solving skills, but this is on a different level requiring the interviewee to have studied and knowledge of the technique, otherwise we are basically trying to develop efficient algorithms from scratch and in little time. --This makes sense for college interviewees who have only studied the past 4 years, but for a professional with experience why is this adequate??

They are not just testing your analytical skills but also, I believe, your ability to self-study for something, even as "annoying" as algorithmic coding problems.

I kinda agree with you that it doesn't make sense much of the time if you have to specifically prepare for the coding interview; stuff you may never use in your job. But its not a lot of stuff: I bit the bullet and spent some time solving those questions and now can make past mostly any screen.

Its really not that hard, especially if you have a CS degree. Probably would take 1 week of dedicated effort to get better at it.

How is proving self study ability relevant to a job? Doesn't my resume of wildly varying projects and my ability to competently talk about them prove that?

It sounds to me like a way to weed out pesky applicants who have families or who are simply older.

> How is proving self study ability relevant to a job? Doesn't my resume of wildly varying projects and my ability to competently talk about them prove that?

People usually trust their own assessment of a candidate much more than that of others. While your projects might help generate interest in you and get you an interview, the actual interview process is meant to be an assessment by the Company conducting the interview. So you shouldn't automatically assume you have the jobs simply based on your past projects alone. I'm not saying I necessarily agree with how this works; I am simply pointing out why it works that way.

> It sounds to me like a way to weed out pesky applicants who have families or who are simply older.

Perhaps. It seems unlikely since many of the senior developers/hiring managers at most mature companies are older and have families.

While your projects might help generate interest in you and get you an interview, the actual interview process is meant to be an assessment by the Company conducting the interview. So you shouldn't automatically assume you have the jobs simply based on your past projects alone.

That's insane. If you brought me in because you liked what's on my resume, your number one priority should be determining if I really did what I said I did. Your priority shouldn't be arbitrary, unrelated questions or coding challenges pulled off some website.

I'm not aware of any other industry that behaves like this.

> That's insane. If you brought me in because you liked what's on my resume, your number one priority should be determining if I really did what I said I did. Your priority shouldn't be arbitrary, unrelated questions or coding challenges pulled off some website.

There generally is a component where you're asked about your past projects in detail. Its just not the only component.

Dude stop being logical. This is software development hiring.

I don't have a week to dedicate to crap like that. I do have 15 years of experience building stuff people actually need and i am reasonably good at it.

Exactly. 95% + of the work out there is more about plumbing and a doesn't design to plumb together. On the rare occasion when I have had anything algorithimc to do I Google for similar problems.

The last time I had a proper algorithmic problem, I was in an academic institute and we had a guy researching algorithms so I asked him (though he didn't come up with mush). It was basically a variation the stable roommates problem. I came up with a solution - brute force plus a load of optimization and it worked well enough for the purpose.

When I get that crap in interviews some of the time I get the answer, some of the time I don't. Its pot luck. Its says very little about my skill for the jobs I am applying for. Ironically I was way better at answering those things 15 years ago when I was fairly crap at building reliable robust systems.

OP of the comment here... Actually, I had a production service centered around the stable-roommate-problem. It took me a week or two to develop something out and fit it into our codebase. It then took 1-3 more weeks to actually make it work for us and cover edge cases (Irving's algo quits after instability -- this isnt an option in the real-world). I had many deep-thinking sessions where I was mostly in my head, writing scratch on paper, collab-whiteboarding (sometimes arguing), or testing PoCs.

The success resulted from deep research and much trial & error. It was no magical "algorithmic skillset" that they expect in those type of interviews (I wonder if those are even a good filter for actual production algos).

Here is my simple write-up of SRP: https://medium.com/@rambossa/stable-matching-algorithm-and-h...

and then some interviewers have the nerve to ask, "have you seen this question before?"

As bad as coding interviews are, at least they're better than riddle/lateral-thinking questions

Those are at least a little fun, though.

Reply on news.ycombinator.com