5 ms·

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

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 familiarity with python / python syntax), and ask them to work through the code and do a code review. There's some python specific quirks that I largely consider bonus points at best, but anyone with any appreciable familiarity with at least one language should be able to spot a number of things. As they call stuff out, I'll dig in (or not) as seems appropriate. So far it seems to be working out great for me as an interviewer. Candidates seem to be way less stressed than they are with a "whiteboard coding" exercise. Good discussions are showing me their development skills, etc.

bigbong 2y ago
Would you mind sharing it?
esperent 2y ago
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.
- phil-martin 2y ago
  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
naught0 2y ago
I'm dying to see this code
devjam 2y ago
As was also pointed out in the TFA, while you may not be "marking people down" because of unfamiliarity with syntax, an interviewee who has more experience with the language (and it's debugging tools) used in the interview will have an inherent advantage over someone who isn't as familiar.
deleted 2y ago
[deleted]
Borg3 2y ago
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.
- IshKebab 2y ago
  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/warning/redefined-builtin.html https://pylint.pycqa.org/en/latest/user_guide/messages/warni...
  - Borg3 2y ago
    Hmm, nice stuff.. Luicky, I avoid python, so case closed. Ruby is so much nicer for me.
    - IshKebab 2y ago
      Ruby is even worse in my experience, but I guess some people have strange priorities.
      - Borg3 2y ago
        Hehe.. Well, most importand is, use whatever language that makes you happy using it. I ve started using Ruby around 2006 I think. I was evaluating Python too, but syntax annoyed me and portability issues as well back then. I never regreted that I choosed Ruby. Its just solid for me :)
BodyCulture 2y ago
Please show some examples of such code, everyone will profit from this, no reason to hide it, thanks!
quectophoton 2y ago
Yes! I love these kinds of interview questions. For some reason these feel more like a "normal" pair programming (/ code review) session, and I totally forget I'm in an interview. 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.
xgb84j 2y ago
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<Session> 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"
- bilekas 2y ago
  I love the exception suppression via email. Sr.Dev : "UserSignup failed, ask tech support what happened in our code" Genius.
- actionfromafar 2y ago
  This is canonical Java. Commit and deploy!
- vaylian 2y ago
  > 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?
  - 2y ago
filcuk 2y ago
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.
deleted 2y ago
[deleted]
Pikamander2 2y ago
I wrote some entry-level PHP interview questions years ago and the number of people who couldn't spot simple syntax errors or identify the security hazard of echo $_GET['var'] was staggering.

bigbong 2y ago

Would you mind sharing it?

esperent 2y ago

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.

phil-martin 2y ago
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

naught0 2y ago

I'm dying to see this code

devjam 2y ago

As was also pointed out in the TFA, while you may not be "marking people down" because of unfamiliarity with syntax, an interviewee who has more experience with the language (and it's debugging tools) used in the interview will have an inherent advantage over someone who isn't as familiar.

deleted 2y ago

[deleted]

Borg3 2y ago

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.

IshKebab 2y ago
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/warning/redefined-builtin.html https://pylint.pycqa.org/en/latest/user_guide/messages/warni...
- Borg3 2y ago
  Hmm, nice stuff.. Luicky, I avoid python, so case closed. Ruby is so much nicer for me.
  - IshKebab 2y ago
    Ruby is even worse in my experience, but I guess some people have strange priorities.
    - Borg3 2y ago
      Hehe.. Well, most importand is, use whatever language that makes you happy using it. I ve started using Ruby around 2006 I think. I was evaluating Python too, but syntax annoyed me and portability issues as well back then. I never regreted that I choosed Ruby. Its just solid for me :)

BodyCulture 2y ago

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

quectophoton 2y ago

Yes! I love these kinds of interview questions. For some reason these feel more like a "normal" pair programming (/ code review) session, and I totally forget I'm in an interview. 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.

xgb84j 2y ago

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

bilekas 2y ago
I love the exception suppression via email. Sr.Dev : "UserSignup failed, ask tech support what happened in our code" Genius.
actionfromafar 2y ago
This is canonical Java. Commit and deploy!
vaylian 2y ago
> 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?
- 2y ago

filcuk 2y ago

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.

deleted 2y ago

[deleted]

Pikamander2 2y ago

I wrote some entry-level PHP interview questions years ago and the number of people who couldn't spot simple syntax errors or identify the security hazard of echo $_GET['var'] was staggering.