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

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

#271

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

entee wrote: post #268

Apocryphon wrote: post #190

Earlier quoted context omitted.

> Not knowing when to use a hash table instead of a nested-for loop On the flip side, the O(1) look-up nature of hash tables make them the no-brainer data structure to use, at least for passing programming interviews. Perhaps more interesting test questions would be when not to use hash tables.

Fully agreed. Most questions I got when I started out as a data scientist interviewing for jobs were pretty simple: "use a hash table to count stuff, join stuff, lookup stuff". However not once did I get asked, "why do databases not exclusively use hash tables if they're so good?" That's a much more interesting question, though perhaps out of scope for a data scientist. I'd add that I've never heard that question bei…

I actually got that exact question once, or pretty close to it. I'm paraphrasing, but the question was "Hash tables are cool, but what's a data structure they might use in a DB besides that?". This was pretty early in my career, so it stumped me, and he pointed out that a binary tree is used semi-often because of ordering.

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

#272

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

jorblumesea wrote: post #233

pmiller2 wrote: post #212

Earlier quoted context omitted.

The big difference is you pass the MCAT or bar exam once, then never worry about it again.

That's not true, not every state shares or accepts Bar results from other states, and Doctors have medical board exams that also need to be studied for. If you are a lawyer or a doctor and are moving to a new state, you probably need to study.

If you're a practicing physician and move to another state, you, in fact, probably do not have to retake licensure exams. Almost all states either have reciprocity agreements with at least a few other states, or will grant a license by endorsement to a physician who's licensed in another state and has practiced for a certain number of years. See http://www.visalaw.com/wp-content/uploads/2014/10/physicianc...

Board exams are the same as MCATs in the sense that you take them once and forget about it.

For lawyers, the situation isn't so rosy (which is to be expected, because law varies a lot per state), but there is quite a lot of reciprocity out there, and some states will offer an "attorney's exam" in lieu of a full bar exam. And, for some areas of law that are strictly federal, admission to the federal bar can be sufficient to practice in any state. It is not as hard as you make it out to be.

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

#273

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

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 a really interesting project I'd consider working for them. But I'm pretty lazy about redo-ing college algorithms class during my free time at home to go work there, so I probably won't.

There's an opportunity cost with interviews like this where an M.S. and long career of getting shit done counts for very little and memorization of undergrad level topics that you can look up in two minutes in Knuth if you have a problem that requires it can make or break an interview.

I've made a career fixing a ton of horribly shitty, inefficient code that's been produced exclusively by people who pass these interviews.

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

#274

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

whatshisface wrote: post #179

on_and_off wrote: post #161

Earlier quoted context omitted.

It is a perverse effect on the profession as a whole. In the silicon valley I have a fair amount of colleagues that expect of any dev to spend a fair amount of their free time grinding on even more dev. No surprise that there is a lack of diversity in the profession as a result.

Except for people over 50 who have probably realized there is more to life, why would some demographics be willing to grind less than others? Edit: By "over 50," I mean age demographics in general, which is the main thing that raises your family obligations. The only demographic division that I can think of that would reduce someone's willingness to abandon their personal life would be age.

Humans are social creatures; we can't live on code alone.

If you come from an underrepresented demographic or have interests or social preferences outside the mainstream of the profession, it will be harder to fulfill your need for social affiliation by participating in communities like HackerRank in your free time-- because it may be harder to find people who share your values, and that you can identify with on a social level.

In other words: the social component of "grinding" is more fulfilling for some demographics than others.

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

#275

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

PopeDotNinja wrote: post #110

> However, whether or not a candidate answers a question correctly is not the only source of signal during an interview. You can also evaluate their process by, for example, observing how long it takes them to finish, how clean their code is, and how much they struggle while finding a solution. Our analysis shows that this second source of signal (process) is almost as predictive as the first (correctness). I seem to…

As a frequent interviewer I will say that you are not alone in that: any interviewer that isn't following the above guidelines is unlikely to get a good signal from anyone.

To your final point about expectations: One question that we try to ask ourselves about any particular interview question is "how may bits of information are we getting out of this?" Trivia questions are usually less than 1 - you'll find out if they know some trivia, but you don't honestly really even care. The best questions are those that get you several bits over the course of the interview period, rather than a single yes/no answer at the end. Questions where there is no final end point or where we explicitly do not expect candidates to finish, are often the most effective; we can explore the pathways that are working, dive into side channels that seem interesting, and get data along the way rather than just a checkmark on some individually-useless problem.

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

#276

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

angarg12 wrote: post #223

I got my yearly review recently and I got very good feedback. At the same time I have been doing Leetcode at home for fun, starting with easy problems, and I get my ass handed to me. I find it hard to reconcile these two experiences. How can I thrive at a top tech company while failing to solve an 'easy' coding challenge. It makes me concerned about what would be of me if I had to look for a new job now.

Thats exactly what your top tech company wants. For you not to look for a another job. For you not to try to get a higher salary.

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

#277

Post by crispytx » Mon, Feb 18, 2019, 9:13 PM UTC

I took a technical interview today over the phone, and you know what, they were pretty fair with their questions. I don't know what kind of competition I'm up against for the position, but very fair questions.

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

#278

Post by mlthoughts2018 » Mon, Feb 18, 2019, 9:14 PM UTC

joshuamorton wrote: post #270

mlthoughts2018 wrote: post #104

Earlier quoted context omitted.

Probing someone with very technical conversation about past technical projects is a much stronger filter to prevent unqualified candidates than passing CoderPad tests, whiteboard algorithms, etc. The conditional probability you are hopelessly lacking software skills to do a job given that you nonetheless passed a TripleByte exam or something is quite high. Overfitting & memorization for the sake of the test is extrem…

I can, with quite a high level of competence, speak about projects I had no part in implementing or that don't yet exist. It's far, far easier to fake expertise when you have more context than the person asking questions. Technical interview questions make sure that the question giver has more context than the recipient, ignoring pathological cases.

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 certain decisions made or how were certain problems overcome.

It is precisely the situation when someone did not have to dig into the technical weeds of a project for themselves that they will not be able to fake or fast talk their way through this type of interview.

That is the number one, defining characteristic of this way of interviewing.

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

#279

Post by gonehome » Mon, Feb 18, 2019, 9:16 PM UTC

chooseaname wrote: post #177

gonehome wrote: post #94

Earlier quoted context omitted.

It feels very much like that to me which is why it’s strange there isn’t a Kaplan equivalent. There’s interview cake and leetcode, but I think people would pay $2k for a class that focuses on the questions and in person whiteboard practice. They could collect information about the interviews at the major companies and then use those to create the program. For payment could also help candidates negotiate and then take…

The only way I would consider paying for a course like this is if, upon successfully completing it, I would not have to do the technical portion of the interview at companies I applied to. They would accept this cert and just do the soft skills interview.

I think that’ll never happen because the incentives of the cert granting institution and the company hiring will never be aligned (or aligned enough to matter).

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

#280

Post by darpa_escapee » Mon, Feb 18, 2019, 9:16 PM UTC

paul7986 wrote: post #151

darpa_escapee wrote: post #115

Earlier quoted context omitted.

What, you couldn't derive a solution in a vacuum from first principles? I bet you think referring to API documentation isn't cheating, too!

Hmmm hard decipher your comment. But, that interviewer is the type of developer I don't want to work with. A know it all who only acts like he knows it all and uses Google secretly. Who puts others down to make themselves look good. AKA an insecure P word I want nothing to do with.

> Hmmm hard decipher your comment.

I'm being facetious and agree with your sentiment.