Harder programming questions do a worse job of predicting outcomes • Hacker News Board

Re: Harder programming questions do a worse job of predicting outcomes

#331

Post by jpindar » Mon, Feb 18, 2019, 10:36 PM UTC

castlecrasher2 wrote: post #44

rightbyte wrote: post #24

Earlier quoted context omitted.

This is kind off strange for a non US resident to grasp. I've been employed as a programmer three times and noone tested my coding abilites what so ever on the interviews. No samples, nothing. Never heard of any collegue doing that either.

>This is kind off strange for a non US resident to grasp. I've worked for two non-technical companies as a software developer and one highly technical company, and interviewed at a few Silicon Valley companies. The difference between the interview processes is staggering; my current job's interview was two hours of conversation, no code tests, just a general assessment of "do you know what you're doing" by the hiring…

This is also my experience interviewing for embedded systems and (hardware) test automation work at electronics manufacturers. I've never been asked to code anything. (Nor have I been asked to draw any schematics.) Just conversation.

Re: Harder programming questions do a worse job of predicting outcomes

#332

Post by chcknsammich » Mon, Feb 18, 2019, 10:40 PM UTC

drugme wrote: post #308

wolfgke wrote: post #288

Earlier quoted context omitted.

> They have kids. Developing a sentient being is a higher priority and more difficult than developing React Redux. This is like saying: "I have a time-intense hobby that I prefer over working too much for you.".

No, it's called having a life and a sense of proportion. The sooner tech companies learn to embrace and work with this very basic fact, the better.

So the sooner they abandon all of their own priorities and instead adopt only yours, the better?

Re: Harder programming questions do a worse job of predicting outcomes

#333

Post by abhishekjha » Mon, Feb 18, 2019, 10:40 PM UTC

zinclozenge wrote: post #15

The less talked about absurdity is that successfully passing programming interviews is a skill itself. It's especially absurd because the time I spend developing that skill is less time spent developing skills and knowledge more directly relevant to my job. Yet, programming interview skill is more relevant to progressing my career. edit: now if you'll excuse me, I need to do some dynamic programming problems.

Hi.

Where are you learning DP problems from? I am very bad at those and need a few good references so that it sticks in my memory.

Re: Harder programming questions do a worse job of predicting outcomes

#334

Post by koube » Mon, Feb 18, 2019, 10:41 PM UTC

Ensorceled wrote: post #286

trishume wrote: post #281

Earlier quoted context omitted.

I've interviewed with Google and the interviews I got didn't really require having memorized algorithms. Maybe on the level of breadth first and binary search which are pretty basic. But I don't think most interviews used any algorithms from a book at all. I think their interview prep packet overstates the amount of knowledge expected.

We ... had different experiences. It was a day of implementing algorithms on a whiteboard. I was supposed to be interviewing for a management position so I didn’t get the study packet either.

I also interviewed at google, in the in-person all of the algos I got were very fair in my opinion, in that it took a little bit of thought to figure out what I needed to do, and then after that, most of the work was just turning that idea into an algorithm. It was all on the whiteboard but I thought it was fair. They were fine with little errors and we talked through them.

On the phone interview I was asked how to something I had no idea how to do. I have no idea how I passed the phone interview.

Seems like a mixed bag, the question as far as I know is completely up to the interviewer, which makes the interview very subjective when they don't use a normal question.

Re: Harder programming questions do a worse job of predicting outcomes

#335

Post by warp_factor » Mon, Feb 18, 2019, 10:44 PM UTC

drblast wrote: post #316

warp_factor wrote: post #309

Earlier quoted context omitted.

You wouldn't be a good fit for Google. With their algorithmic interviews that require college-grad level of studying, they filter for people that are ready to follow orders without complaining. That's who they want to hire at the end of the day: some coders that don't get too critical about their job and do what they are asked to do, even if it is repetitive, stupid and doesn't really make sense (such as re-studying…

I was a naval officer in a prior life, and my current manager loves that I get the job done, whatever it is, without complaint. I'm pretty much the opposite of what you think, so if my desire to study for the algorithm interview is your litmus test for that, kinda proves my point. Not everyone that would be good for Google has a burning desire to work for Google. Google might want to consider that.

To make it clear, I absolutely hate coding interviews that makes candidate lose so much time restudying. I think having some critical-thinking is absolutely needed and way too many engineers lack some (especially those swallowed into FANGs)

What I described on my previous post is a credible explanation that my group of engineer friends came up with on why all the FANG companies pursue those heavy memorization algorithmic interviews.

Re: Harder programming questions do a worse job of predicting outcomes

#336

Post by cr0sh » Mon, Feb 18, 2019, 10:44 PM UTC

avip wrote: post #113

davidhyde wrote: post #25

I think that asking a candidate to perform a code review can be an effective method of evaluating quite a few desirable qualities. Can they understand someone else's code? Can they engage in constructive critical discussion? Are they able to effectively refactor something to make it better? Can they spot mistakes and do they have an opinion about how to avoid such mistakes?

There's a classical test of giving a never seen before programming language (invented for the test), then the candidates need to reason about some code. Never seen that in the industry though.

That would be a rather interesting challenge for an interview; I'd love to be able to try it someday.

I recently did something similar, that was of my own devising.

At one point several years back I wrote down some "code" in my own "shorthand" form; it was meant to implement a library and some test code for a microcontroller project I was contemplating at the time. I basically wrote it in such a fashion so that I was quick to get my main ideas down without being too "wordy" (whether in code or otherwise).

Then I put it away, and didn't revisit it again - until recently.

A couple of weeks back I found that code again, and looked at it - worried that I wouldn't be able to recall my shorthand or what I was thinking; in short, worried that my ideas would be "lost".

I looked over the code, walked thru it in my mind - and after a few minutes it all came back to me, and I was able to understand again what I had originally created (and where I could make improvements as well). It both left me feeling optimistic about the process, as well as a bit excited that I was able to remember it and improve on it - that I didn't have to worry about it, and that my shorthand "pseudo-code" was legitimate enough that it could have been real code for all that it mattered.

Re: Harder programming questions do a worse job of predicting outcomes

#337

Post by tombert » Mon, Feb 18, 2019, 10:44 PM UTC

KallDrexx wrote: post #243

tombert wrote: post #125

Earlier quoted context omitted.

I go back and forth about how I feel about doing heavy algorithm/data-structure stuff in interviews. On the one hand, I have never once written any kind of sort algorithm or LRU cache by hand for a production system, because why would I? Pretty much every language's standard library has a fairly-optimized sort and caching thing built in, and if they don't then there's still probably a million outside libraries to do…

> On the other hand, I genuinely do feel theory is really important. While not knowing the minutia of a tim-sort doesn't indicate that you'll be a bad engineer, not knowing the runtime efficiency of a sort can lead to some really awful code. Not knowing when to use a hash table instead of a nested-for loop can be a sign that you don't really know what you're doing, and not knowing some rough theory on concurrency ind…

I don't think you're wrong in general, but in one specific case I actually can give an example where me not knowing how a hash-map worked was really bad. I was working on a very limited set of memory for a small embedded thing when I was an intern, and was using hashmaps all over the place because they're magic, and kept getting out of memory exceptions.

I learned later that hashmaps are inherently O(n) (or O(log n)), or they take a lot of memory; internal arrays can get super huge if you're not careful.

In this particular case, an ugly nested for-loop was the immediate solution, and eventually I was able to cheat a little and have hard-coded integer indexes and was able to use an array.

Anyway, your point is valid, I just figured I'd give an example where knowing the internals for a hash table would have saved me a lot of time.

Re: Harder programming questions do a worse job of predicting outcomes

#338

Post by ball_of_lint » Mon, Feb 18, 2019, 10:45 PM UTC

trishume wrote: post #281

drblast wrote: post #273

Google recruiters call me a lot. I think I'd do a good if not stellar job working there. I've passed multiple FAANG interviews and been very successful as a senior developer. In my email I have an "interview prep packet" from them that essentially tells me to brush up on algorithms and read Cracking the Coding Interview to prepare for their interview process. I'm fairly happy in my job. If they offered more money or…

I've interviewed with Google and the interviews I got didn't really require having memorized algorithms. Maybe on the level of breadth first and binary search which are pretty basic. But I don't think most interviews used any algorithms from a book at all. I think their interview prep packet overstates the amount of knowledge expected.

My interviews with Google last year did have a BFS and a system question, but they also asked me a problem that required dynamic programming and one that required fast exponentiation. I'd say that Google ranks 8 of 10 or so in how algorithm-heavy their interviews are.

Re: Harder programming questions do a worse job of predicting outcomes

#339

Post by g9yuayon » Mon, Feb 18, 2019, 10:45 PM UTC

I just finished reading Bill Kilday's Never Lost Again. It was amazing that four engineers produced the ground-breaking Google Maps in 16 months. Algorithm/Math questions used to be really effective at finding engineerings like those four engineers. There was a reason that Microsoft resorted to algorithm puzzles in its hay days as well.

It's just unfortunate that there's so much prepping materials online nowadays that the programming puzzles have become ineffective. It gets worse as many interviewers were not good enough to ask follow-up questions. For instance, addition with big integers is a pretty easy interview question, right? But if a candidate can go as deep as this article: https://bearssl.org/bigint.html, I can be pretty confident that the candidate is really really good.

That said, I personally don't find it necessary to join the rat race. Instead, I'd suggest engineers just take time to thoroughly study just one book on algorithm designs. In fact, an introductory book, such as Kleinberg's Algorithm Design or Udi Manber's Introduction to Algorithms, will be good enough. It may not get you into Google, but it will likely get you into another damn good company. The best part of this approach is that passing interview is really just the byproduct of you trying to become a better engineer.

Re: Harder programming questions do a worse job of predicting outcomes

#340

Post by bob33212 » Mon, Feb 18, 2019, 10:48 PM UTC

kradroy wrote: post #329

drblast wrote: post #273

Google recruiters call me a lot. I think I'd do a good if not stellar job working there. I've passed multiple FAANG interviews and been very successful as a senior developer. In my email I have an "interview prep packet" from them that essentially tells me to brush up on algorithms and read Cracking the Coding Interview to prepare for their interview process. I'm fairly happy in my job. If they offered more money or…

I'm in your boat. I get hit up by Google 3-4 times a year. I was interested once and did the pre-screening. When I got their prep packet I looked it over and then promptly canceled my interview. I wasn't going to review stuff I've never used throughout my 10+ year career. I'm a big fan of not wasting time, which I why I get stuff done at work and have been promoted twice at my current company in the past 3 years. As…

I have a technical phone screen with Google this week and I have the same attitude as you. So i'll probably fail the interview, but I'm doing it just in case they ask a real world problem, which I'm pretty good at.