Earlier quoted context omitted.
> I don't care for popular people so, in fact, my bias might be the other direction It's not about someone being popular and you saying it just makes me more certain you don't realize the trap. People can have well honed social skills and not act like your standard popularity contest wining politician.
The most carefully honed social skills in the world won't help somebody plausibly answer a question like "What is the data type of this variable?" or "Show me the line where the null pointer dereference is happening." They can add all the smiles and chuckles and other social niceties they want, but at the end of the day, whether they come up with the right answer or not, their logic will tell you pretty clearly wheth…
Bug squash: An underrated interview question
151–160 of 282 posts
Re: Bug squash: An underrated interview question
#152I'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.
Unless it was literally a week ago, I work on too many things to ever remember anything, and for me it's just a fact of the work that I'll be fixing bugs or whatever the questions asks. Nothing stands out, because I don't consider any of them to be some sort of special occasion worth keeping track of
Re: Bug squash: An underrated interview question
#153My 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…
Still a tiny bit stressing at the beginning while I read the code for the first time and try to understand it because I worry that I might be taking longer than the interviewer expects, but if I'm thinking out loud then that helps both of us. After I get reasonable context I can then forget about the interview and just focus on the normal pair programming / code review.
Re: Bug squash: An underrated interview question
#154My 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…
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.println("User saved!");
return true;
} catch (DbException e) {
EmailUtil.sendEmail(config.getTechnicalSupportEmail(), e);
return false;
}
}
}---
"Solution": We always ask the candidate "What would you change about this code?" or something similar. We expect the candidate to come up with some selection of: - Database sessions should come an injected provider. - Configuration should probably be injected as well and not passed as a method parameter. - Booleans are not canonical Java as return value. - Don't write to stdout but to a logger. - Exception handling should probably happen outside the DAO. - Don't use static methods for sending Emails without good reason. Non-static methods are easier to test.
Finding these things is as important as being able to talk about them and give background on advantages / disadvantages of doing things different ways. With good candidates one can talk easily half an hour just about this example and adjacent topics (e.g. error handling).
---
Edit: Formatting
Edit 2: added "Solution"
Re: Bug squash: An underrated interview question
#155My 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…
Re: Bug squash: An underrated interview question
#156Re: Bug squash: An underrated interview question
#157I like this approach far, far more than coding tests! > It’s fun. It’s fun in the same way an escape room is fun. It’s fun because of the dopamine you get when the test suite blinks green. Keep in mind that for lots of people in a job interview setting (even excellent candidates) this is not fun, this is stressful. It may be fun on the job or at home, but the stress of a job interview both eliminates any "fun" aspect…
for me cracking the coding interview is stressful i prefer the bug squash question. i have 20 years of experience. i will probably do well. a fresh grad might fail. do i care? no. leetcode has benefited fresh grads and is being used to discriminate against those with anxiety and other disorders and those who are older. i think it is refreshing to try a different interview method, one that benefits those with experien…
I'm not older, but I was in the industry prior to the leetcode style interview. I've never sat down and "grinded" leetcode but I've also never had a problem with those styles of interview once they became common. Neither have my former co-workers. I have a few friends that are still working, past retirement age, that would crush any problem you threw at them.
In my experience, it's not much different than the whiteboard interview. Sure the presentation of a problem can stump you for a moment, but with a few good follow up questions a solution, however naive, becomes apparent.
I had a mentor early in my career that repeatedly said "There is no such thing as an unsolved problem in computer science". I think that mostly holds true, you either recognize the pattern and implement, or you learn and implement next time.
That all said, leetcode style interviews are the interview version of a "bad code smell" and I'd strongly prefer a bug-squash style, even if it was in a completely unfamiliar programming language. Actually, an unfamiliar programming language might make it fun.
Re: Bug squash: An underrated interview question
#158My 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…
Sr.Dev : "UserSignup failed, ask tech support what happened in our code"
Genius.
Re: Bug squash: An underrated interview question
#159Earlier quoted context omitted.
why do young programmers need to pass? nobody gives a shit whether experienced people pass leetcode so give me one good reason why you should rate young programmers differently.
Just because people in group A are treated badly, that's favoring group B, doesn't mean it's reasonable to do the reverse.
Re: Bug squash: An underrated interview question
#160Earlier quoted context omitted.
for me cracking the coding interview is stressful i prefer the bug squash question. i have 20 years of experience. i will probably do well. a fresh grad might fail. do i care? no. leetcode has benefited fresh grads and is being used to discriminate against those with anxiety and other disorders and those who are older. i think it is refreshing to try a different interview method, one that benefits those with experien…
What is wrong with capitals?