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

161–170 of 282 posts

Re: Bug squash: An underrated interview question

#161

Post by filcuk »

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…

I work it BI and am hoping to expand the team. Does anyone have a good universal SQL code for that?

In my interview, I was given a T-SQL code, where I did point out the mistakes, but was told my solution wasn't optimal, but that was because I've never used that flavour before (nor was it specified in the hiring docs), so I'd like to avoid doing the same to others.

Re: Bug squash: An underrated interview question

#162

Post by vaylian »

xgb84j wrote: post #154
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…

Great idea, that's exactly what I like to do as well. Because many people were interested in some actual code, here is an example that we used for Java: --- public class UserDao { private Provider sessionProvider; public UserDao() { this.sessionProvider = new DbSessionProvider(); } public boolean saveUser(User user, ApiConfig config) { try { Session session = sessionProvider.get(); session.save(user); System.out.prin…

> Booleans are not canonical Java as return value

What should you return instead? Or should the method return void and raise an exception on failure?

Re: Bug squash: An underrated interview question

#163

Post by serpix »

sk11001 wrote: post #100
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.

There’s no chance that I can come up with a good bug story on demand without any preparation.

compare this with the technical interview bomb of demanding you write a full blown program right fuking now, complete with tests. Which one do you prefer?

Re: Bug squash: An underrated interview question

#164

Post by haspok »

vaylian wrote: post #162
xgb84j wrote: post #154

Earlier quoted context omitted.

Great idea, that's exactly what I like to do as well. Because many people were interested in some actual code, here is an example that we used for Java: --- public class UserDao { private Provider sessionProvider; public UserDao() { this.sessionProvider = new DbSessionProvider(); } public boolean saveUser(User user, ApiConfig config) { try { Session session = sessionProvider.get(); session.save(user); System.out.prin…

> Booleans are not canonical Java as return value What should you return instead? Or should the method return void and raise an exception on failure?

You could return the saved User object, if `save` changes it in any way, to allow the caller to work with it functional style, ie. make it explicit that it is an updated object (or if it is immutable, although typical persistence frameworks expect mutable objects, "bean" style).

You could also go fancy and do it properly functional, so return something like an `Either` instead of throwing an Exception, but that's definitely not canonical Java...

Re: Bug squash: An underrated interview question

#165

Post by normie3000 »

vaylian wrote: post #162
xgb84j wrote: post #154

Earlier quoted context omitted.

Great idea, that's exactly what I like to do as well. Because many people were interested in some actual code, here is an example that we used for Java: --- public class UserDao { private Provider sessionProvider; public UserDao() { this.sessionProvider = new DbSessionProvider(); } public boolean saveUser(User user, ApiConfig config) { try { Session session = sessionProvider.get(); session.save(user); System.out.prin…

> Booleans are not canonical Java as return value What should you return instead? Or should the method return void and raise an exception on failure?

Probably boolean. If you don't see the difference, welcome to Java :D

Re: Bug squash: An underrated interview question

#166

Post by caseyy »

kenschu wrote: post #63
caseyy wrote: post #41

Earlier quoted context omitted.

So true. A test will only measure its set of criteria. What is a test for drive — desire to understand and learn? What is a test for how a person will respond to challenging and overwhelming prod scenarios? What is a test for if they will burn out in a month because they want to prove how rockstar of a programmer they are? My most successful hiring has always been based on a conversation with 3-4 practical questions.…

There's both culture and technical elements to consider in a potential hire. I don't think anyone would contest that vetting for the culture/drive of a candidate is important. But I do think the demonstration of skills is a necessary part of technical hiring, at least for non-senior positions.

I agree with that to some degree. But I do lean more into hiring on potential though, it has worked out for me.

Skills can be learned. Tools can be provided. But the employee’s personal values are very hard to change. These are core components of performance in some perf management theories.

I think context is important. If a company can hire on potential, I would say it will be a better hire in the long-term. But if employee turnover is high and tenures short, and you need work done now and not 6 months from now, I agree with you more.

Re: Bug squash: An underrated interview question

#167

Post by normie3000 »

xgb84j wrote: post #154
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…

Great idea, that's exactly what I like to do as well. Because many people were interested in some actual code, here is an example that we used for Java: --- public class UserDao { private Provider sessionProvider; public UserDao() { this.sessionProvider = new DbSessionProvider(); } public boolean saveUser(User user, ApiConfig config) { try { Session session = sessionProvider.get(); session.save(user); System.out.prin…

This code looks like normal enterprise Java ugliness to me - I object to it on principle, but apart from having to pass ApiConfig when saving a user I probably wouldn't identify any of the official problems you listed without familiarity with the rest of the codebase.

Re: Bug squash: An underrated interview question

#168

Post by steventhedev »

Having done nearly 100 technical interviews (with multiple questions each), the bug squash question gave us the biggest signal on candidates.

Our question was far simpler: it was a simple class (java + python variants, no fancy syntax) and ask them to describe what it does, then find the bug, and finally ask them what they would change.

It reflects a true test of what the day to day is, and whether or not the candidate would succeed in the role.

Re: Bug squash: An underrated interview question

#169

Post by whatever1 »

xgb84j wrote: post #154
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…

Great idea, that's exactly what I like to do as well. Because many people were interested in some actual code, here is an example that we used for Java: --- public class UserDao { private Provider sessionProvider; public UserDao() { this.sessionProvider = new DbSessionProvider(); } public boolean saveUser(User user, ApiConfig config) { try { Session session = sessionProvider.get(); session.save(user); System.out.prin…

"Don't write to stdout but to a logger."

Not great advice given the fact that a logger paged pretty much every SDE on this planet.

Re: Bug squash: An underrated interview question

#170

Post by Pikamander2 »

I've written some interview questions before and can confirm that having people find and fix simple issues in code is a surprisingly great way to weed out people who have no clue what they're doing.

> Cheating effectively is indistinguishable from debugging skill. Even with knowledge of the exact bug ahead of time, if you just open the file with the bug, barf out the code to fix it, and run the tests, you’re going to fail the interview.

Did you mean "distinguishable" here, by chance? The first sentence seems to contradict the second.

Post reply on HN