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

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

#361

Post by zanny » Mon, Feb 18, 2019, 11:17 PM UTC

TeMPOraL wrote: post #351

AnIdiotOnTheNet wrote: post #289

Earlier quoted context omitted.

We convinced our parents to buy a computer because it would help our education when all we really wanted one for was playing computer games. Joke was on us though, because playing computer games at the time usually involved a lot of putzing around and figuring out how stuff worked, ultimately teaching us marketable skills.

Totally true. In my case it was a natural progression: "videogames are great!" -> "I have an idea for even better videogame!" -> "how do I make one?" -> "can I tweak this one into being a bit more the way I like it?" -> tinkering around data files -> "I really want to make my own game" -> picking up a programming book at 13 -> a programming career.

22 -> make crud Java apps at a corporate software farm for a decade and lose faith in humanity

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

#362

Post by jschwartzi » Mon, Feb 18, 2019, 11:18 PM UTC

wolfgke wrote: post #325

smadge wrote: post #322

Earlier quoted context omitted.

A person can choose to spend less time on a hobby at any point, but once a child is born their parents have an ethical obligation to their children.

> but once a child is born their parents have an ethical obligation to their children. Indeed - and that is why you should be very cautious to give birth to children; in particular if you have career plans.

No, this is the wrong way to think about it and it has destroyed our generation by its proliferation. You should give birth to children and have enough balance between your work and your life to raise them and still grow in your career. You should never have to choose one or the other.

This false dichotomy cuts to the heart of a lot of gender and racial diversity issues that plague the workplace in the US.

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

#363

Post by mlthoughts2018 » Mon, Feb 18, 2019, 11:20 PM UTC

joshuamorton wrote: post #294

mlthoughts2018 wrote: post #278

Earlier quoted context omitted.

I’m sorry but you cannot do what you are claiming. It has nothing to do with whether the candidate has more context or not. In fact, conversational interviewing like this has very little to do with any of the domain specifics of the project. The point is to recursively keep probing for deeper technical specifics, so they have to explain at finer and finer technical levels what were the tradeoffs, why exactly were cer…

>I’m sorry but you cannot do what you are claiming. But I have. Not in the specific context of a job interview, but I have absolutely convinced technical experts that my level of expertise in a field is above my actual level of expertise. Ironically, if this were a technical interview, I'd fail it, not because I lack the skills to convince technical experts of my non-existent abilities, but because you don't find me…

> “But without context, you can't effectively do that.”

This is simply false. You don’t need context to understand if the breakdown of a technical problem into constituent trade-offs was appropriate or not — by definition that very breakdown into constituent technical details is the context.

> “investigating that was someone else's responsibility"

This just confirms to me that you are not correct in asserting people can just skate by these discussions. If someone tells me something like that, I’ll ask them what did that other person find when they investigated? If you say anything like, “I don’t know; that was their job not mine,” then you’ve lost credibility because you didn’t put that other person’s conclusions through strong skepticism until you were satisfied you knew the details well enough that you could own or support them if you had to. That is exactly the sort of thing that indicates bullshitting.

> “attempt to verify their authenticity during the interview, at which point you quickly venture into the land of bias and subjectivity.”

This is just wrong. You don’t ever “just trust” the candidate, that’s the opposite of this interview style. Further, you never “attempt” to verify authenticity.. you just do verify it, since it does not require context or domain specialty to analyze reductionist decomposition of any engineering work down into primitive constituent tasks or decisions that are universal.

This approach is far less biased or subjective than appraising “how a candidate thinks” while they solve tricky puzzles in a foreign environment with unrealistic time pressure.

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

#364

Post by driverdan » Mon, Feb 18, 2019, 11:23 PM UTC

bob33212 wrote: post #340

kradroy wrote: post #329

Earlier quoted context omitted.

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.

If they ask you any CS101 or algo questions end the interview and explain why.

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

#365

Post by whatshisface » Mon, Feb 18, 2019, 11:24 PM UTC

arrrg wrote: post #313

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

I can see this sentence being an interesting Rorschach test. Either you think it’s quite sensible or utterly absurd. My own brain was even flip-flopping around for a bit before coming down on the utterly absurd side. I think the maybe reasonable counter-argument against your sentence would be that while you personally do not have to value something like raising kids above your work, others very well might and do and…

If work is everything, shouldn't we set aside some time to raise the next generation of workers? Working all the time is so defeating it even defeats the amount of work being done 30 years from now.

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

#366

Post by mlthoughts2018 » Mon, Feb 18, 2019, 11:25 PM UTC

nybblesio wrote: post #327

mlthoughts2018 wrote: post #312

Earlier quoted context omitted.

Not really though. If your price is working in a quiet, private office with a door that shuts, or having humane treatment when you’re being interviewed, then it seems nobody would pay it. Let’s take their word for it that they are desperate for a machine learning engineer. Then it suggests they care more about mandating workspace conditions (since financial cost even to provide thousands of workers with private offic…

This is such an important observation. Claims of limited talent pool don't align with reality. If demand were truly inelastic, companies would negotiate.

In some cases I do think there is a limited talent pool. Unwillingness to negotiate in those cases usually means the company would rather simply suffer along with worse business outcomes, or try to invest in a totally different area of work, than to accept they are at a negotiating disadvantage and that it may be the case that painful company culture changes have to be made (like giving some people private offices and not others).

“The market can stay irrational longer than you can stay solvent,” seems apt for this.

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

#367

Post by wolfgke » Mon, Feb 18, 2019, 11:26 PM UTC

mturmon wrote: post #345

wolfgke wrote: post #293

Earlier quoted context omitted.

> I wonder if the added friction of changing your place of work caused by this practice is meant to somewhat counterbalance the heavy incentives engineers have to job-hop in the current climate. Kind of makes sense from the point of view of tech employers. I am not sure what to think about this claim: it is the other company that prevents you from working for them by this interview process. The current employer has t…

These same employers (famously) had a cartel that prohibited job hopping before - the Jobs/Schmidt email - so it’s not surprising that the system would trend toward the same equilibrium again.

> These same employers (famously) had a cartel that prohibited job hopping before - the Jobs/Schmidt email - so it’s not surprising that the system would trend toward the same equilibrium again.

This explains this phenomenon plausibly for the FAANG companies. But I think there also exist lots of startups that could easily act as a cartel breaker - to their advantage, since this way they can poach from other companies.

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

#368

Post by fucking_tragedy » Mon, Feb 18, 2019, 11:27 PM UTC

vmasto wrote: post #360

toasterlovin wrote: post #344

Earlier quoted context omitted.

To my mind, the more likely explanation is that they would simply get too many false positives if they didn't use the algorithm stuff to filter potential hires. You lose a lot of potentially good hires that way, but the pool you're left with are all of a certain intelligence level. Whereas, if you don't use the algorithm stuff to filter, it's really hard to figure out who is even intelligent enough to do the job.

I'm not following, how does memorizing algorithms correlate with intelligence and skill in the engineering discipline of the job?

There's a correlation between the belief that memorizing algorithms correlates with intelligence and the application of algorithm questions in interviews.

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

#369

Post by driverdan » Mon, Feb 18, 2019, 11:31 PM UTC

erik_seaberg wrote: post #326

ninja10 wrote: post #285

Earlier quoted context omitted.

It's quite frustrating, I've submitted my portfolio of open source projects on GitHub for interviews. I specifically told the recruiters, HR personnel, hiring managers and some of the developers that the projects contain a large enough body of work to see examples of my code. These projects are quite comprehensive and not one person looked at them or mentioned them during the interviews. Unfortunately, people in gene…

Knowing what good work looks like is a plus, but I wouldn't be convinced by cherry-picked successes. That doesn't tell me how much you struggled with them, how many others you failed, or how much of the work was actually yours.

Requiring irrelevant coding tests isn't going to give you those answers either.

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

#370

Post by bunderbunder » Mon, Feb 18, 2019, 11:31 PM UTC

nybblesio wrote: post #330

bunderbunder wrote: post #155

Earlier quoted context omitted.

If anything, it's testing your ability to mis design computer programs. I hate working on software that was written to be read by an audience with perfect recall, because, as a human, I just don't have that. Give me code that assumes I have the memory of a goldfish, and can't keep track of anything that isn't right in front of my face. I'm pretty sure that's what half of Dijkstra's papers were trying to say, weren't…

Agreed and Knuth's Literate Programming. Our industry is caught in the event horizon of the black hole named, "cargo cults".

The black hole that gets me is a love of complicated things. It seems like, given a choice between two different things that are equally capable of solving the problem, 9 out of 10 hairless apes will pick the one that has more switches and knobs.

I haven't tried literate programming, but one of the things that entices me about it is that my instinct says that it's a vaccine against unnecessary complexity. If you can't express it comprehensibly in both English and code, there's likely an easier way to do it.