Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Bug squash: An underrated interview question

blog.jez.io

Post reply on HN
Print view View original

141–150 of 282 posts

Re: Bug squash: An underrated interview question

#141

Post by strken »

b20000 wrote: post #119
strken wrote: post #118

Earlier quoted context omitted.

A) I, and a lot of other people, do give a shit whether experienced candidates pass leetcode, and try not to give leetcode interviews unless forced to by HR fiat B) As an industry and as a society, it's not a good thing to refuse to hire new grads, since that leads to the kind of labour shortages we see in e.g. medicine and pulls up one of the best ladders for wealth mobility. Tech therefore needs some kind of funnel…

it’s not a good thing to refuse to hire older people and most older people do not pass leetcode without significant grinding

I agree. It's not a good idea to refuse to hire either young or old candidates. It's also not a good idea to refuse to hire experienced or inexperienced candidates.

These candidates have, as groups, different characteristic strengths and weaknesses. You need to give them multiple tests to see those. Leetcode is not a good test, but you do have to test a new grad on something, which might mean a vaguely leetcode-adjacent test like "go print this json tree of directories to the console then tell me what you did in your third year of uni".

Re: Bug squash: An underrated interview question

#142

Post by phil-martin »

esperent wrote: post #94
Twirrim wrote: post #91

My favourite thing to do for "coding" interviews is to give the candidate a piece of absolutely awful python code that a friend of mine came up with for use for interviews. There are code smells, side effects, errors, confusing syntax, a whole slew of things in it. I give them the code, tell them I'll help with every bit of python syntax (and really emphasise that I don't mark people down _at all_ for any lack of fam…

It does seem a bit unfair - ok sure, anyone familiar with C-family syntax should be able to work through it and spot errors. But anyone already familiar with Python would be able to do so a lot faster. I think the idea is good, but to be equitable it should be given in a language the person claims to be already familiar with. Or alternatively, only give it to people in a language they are not familiar with.

If the goal was to objectively evaluate ability in a broad population, I 100% agree. However, if my dev shop primarily uses Python then selecting for people familiar with Python is pretty reasonable.

Thankfully there is a giant corpus of terrible code out there for any language. Especially that code written by the most evil terrible coders of all time: past-self :D

Re: Bug squash: An underrated interview question

#143

Post by IshKebab »

Borg3 wrote: post #132
Twirrim wrote: post #91

My favourite thing to do for "coding" interviews is to give the candidate a piece of absolutely awful python code that a friend of mine came up with for use for interviews. There are code smells, side effects, errors, confusing syntax, a whole slew of things in it. I give them the code, tell them I'll help with every bit of python syntax (and really emphasise that I don't mark people down _at all_ for any lack of fam…

Right... Python.. Its syntax is so ugly. So I guess you can have really awful gems there with hidden bugs :) I myself, shoot myself in a foot once doing Python code. I declared variable called 'len' and boom! What an interesting failure mode the script had. Took me a while to figure it out.

When I write Python it's an absolute hard line requirement to run it through Pylint and Pyright. They catch sooooo many issues you'd have to be a complete idiot not to do this (many people are unfortunately).

In this case Pylint will tell you about this mistake:

https://pylint.pycqa.org/en/latest/user_guide/messages/warni...

Re: Bug squash: An underrated interview question

#145

Post by eru »

gecko6 wrote: post #108

I have an interview question: step 1: the candidate is shown the specification for a method and the results of running the test suite on an obfuscated version of the method. All tests pass. The test suite is minimal, and test coverage is abysmal. step 2: the candidate is asked to come up with more test cases, based on the specification. The code is run against the updated test suite - most new tests will fail because…

Do you allow property based testing?

Re: Bug squash: An underrated interview question

#146

Post by IshKebab »

vandyswa wrote: post #18

I've done the equivalent of this by asking them to describe an interesting bug they've encountered in past lives; how it came up, how they hunted it, how they fixed it. By listening to them describe the work, asking questions, and following their thought processes, you can come to a fairly good hire/no from this single walk-through. I know, it's short and humane, so not a good fit for current Sillycon Valley culture.

Ugh "tell us about a time" questions. I'm so glad the tech industry generally doesn't do that nonsense.

If you do get asked these questions just lie.

Re: Bug squash: An underrated interview question

#147

Post by ZaoLahma »

marginalia_nu wrote: post #123
bawolff wrote: post #82

Earlier quoted context omitted.

> How frequently do people interview in a language other than their "main" one(s)? I would say most of the time. However i still think debugging is a core skill you should be able to demonstrate in languages that aren't your main one.

In Java, would you catch that these two snippets of code do different things? List l = new ArrayList (); l.add(1); l.add(2); l.add(3); l.remove(1); // invokes List.remove(int) System.out.println(l); // [1, 3] Collection l = new ArrayList (); l.add(1); l.add(2); l.add(3); l.remove(1); // autoboxes 1 and invokes Collection.remove(Object) System.out.println(l); // [2, 3] Bugs very often lurk in language specifics. Pytho…

I once interviewed (and got the job) for a java dev position with a mostly C/C++ background.

One of the issues to solve during the tech interview was fixing a bug in a fairly involved web app with a java backend. Long story short, it boiled down to "==" being used to compare two strings instead of ".equals" somewhere deep in their class hierarchy.

I found it and fixed it, even though I was not familiar with the reference vs value equality difference in java. General debugging skills acquired over years should allow you to track down exactly where things go more wrong than expected, and then help you reason about why it goes wrong.

Re: Bug squash: An underrated interview question

#149

Post by lmz »

saagarjha wrote: post #137
b20000 wrote: post #119

Earlier quoted context omitted.

it’s not a good thing to refuse to hire older people and most older people do not pass leetcode without significant grinding

I don't think replacing an interview that fails older people that instead fails younger people is a good solution.

I thought the point of affirmative action was that being unfair is ok if it is to compensate for a prior unfairness.

Re: Bug squash: An underrated interview question

#150

Post by BodyCulture »

Twirrim wrote: post #91

My favourite thing to do for "coding" interviews is to give the candidate a piece of absolutely awful python code that a friend of mine came up with for use for interviews. There are code smells, side effects, errors, confusing syntax, a whole slew of things in it. I give them the code, tell them I'll help with every bit of python syntax (and really emphasise that I don't mark people down _at all_ for any lack of fam…

Please show some examples of such code, everyone will profit from this, no reason to hide it, thanks!
Post reply on HN