6 ms·

I’ve interviewed enough people to staff a company and I disagree. You really really need to go through an actual code exercise with them. It’s staggering how m

I’ve interviewed enough people to staff a company and I disagree. You really really need to go through an actual code exercise with them. It’s staggering how many people I’ve interviewed who can talk the talk but when confronted with with a 50 line class full of glaring issues for a code review exercise, they can’t find any of the actual problems. The great thing about it is that the good people will spot the super obvious ones in about 5 seconds and you can just move on from it very quickly. We’re talking c++ programmers with a decade of experience not spotting basic RAII, missing pointer checks and straight up logic bugs for the domain that we interview for and hire in (games).

dent9 1y ago
It sounds like you should just use better programming languages that don't break constantly.
Buttons840 1y ago
> when confronted with with a 50 line class full of glaring issues Would this work with any language other than C++? In almost every other language the only ways the code can actually be broken is if there's undefined variables or something. Sure, any language can have logic bugs, but that would require more than 50 lines to be certain of. I mean, even if the code says something like `total /= 0`, yeah, it looks wrong, but, I'm not 100% certain it's wrong with just 50 lines of context. Were these programmers lying about their decades of experience? Or did they really get by with writing broken C++ all those years without knowing the basics? What a language! I think C++ is a special case when it comes to interviews.
- maccard 1y ago
  It’s a self contained class that is littered with basic errors and doesn’t actually do what it’s supposed to do. There’s about 15 things wrong - missing pointer checks, uninitialised variables, public variables with private get/set functions, a memory leak, logic bugs that don’t do what the prompt says it’s supposed to do, subtle behavioural issues that come up in edge cases. We’re not looking for every single one, but there is an alarming number of people who cannot identify even the most glaring issues of “there’s a new in the constructor and not a delete in the destructor”. > Or did they really get by with writing broken C++ all those years without knowing the basics? Having inadvertently hired a handful of people, it’s this. They write shonky c++, it just about works, but they spend all their time patching up the mess they’ve left behind rather than doing it right in the first place > I'm not 100% certain it's wrong with just 50 lines of context. These are blatant issues that we would expect a reviewer to catch in isolation. It’s also an interview, we expect you to ask questions. You’re told as part of the brief to ask questions if you’re unsure. It’s not a trick, we’re looking to see if you can actually write the code or if you just can rattle off some of the rules. A good example is DIY. How do you install a shelf - you drill a few screws into the wall and stick a piece of wood on it. Being able to tell you that is very different to being able to do that level on a wall. I can tell you “use SQL to select the name of the users who have used X resource without any duplicates”, but I might not actually be able to write that query (“select name from table group by X where Count(X) > 1”) > I think C++ is a special case when it comes to interviews. I disagree. Give me a language and I can give you 50-100 lines of code that just about does what it’s supposed to do but is littered with issues. Offhand I could write the same thing for C#, go, python and SQL with very little issue.
  - Buttons840 1y ago
    Thanks for the additional detail. It sounds like a great interview question; it's both easier, and yet more real-life, than something like "write fizz-buzz".
- godelski 1y ago
  > even if the code says something like `total /= 0` In what context would this not be wrong? I mean... it might run or compile but our best case scenario is what, javascript where it returns infinity? But I'd certainly take issue with any program where I saw an explicit division by zero. If you were just trying to create an infinity there's got to be a good explanation for doing it that way.
  - Buttons840 1y ago
    It could trigger an exception which is caught elsewhere, or round the number to Inf or -Inf. It's a "clever" (aka, stupid) way to do these things, but it might not technically be wrong. It is possible to have well behaved and reliable code doing such a thing, unlike UB in C++.
OJFord 1y ago
I wonder how many of them would do fine not under pressure though. You're not (necessarily) weeding out experienced people who can't find actual problems in a 50 line class full of glaring issues, you're weeding out those who can't under pressure in an interview setting.
- maccard 1y ago
  I don’t necessarily disagree but anyone who is a c++ programmer and sees class foo { public: foo() { ptr = new other(); } ~foo() { } }; And doesn’t immediately question it doesn’t instil confidence. Interviews are inherently high pressure situations for the candidate, the only way to avoid that is to just let people try out on the job and fire them if it isn’t working out. That’s unfair to everyone.
  - atomicnumber3 1y ago
    Forgive me, I'm a Java programmer. The glaring bug here is that ptr is - or rather the object being pointed to is - on the heap and allocated in the constructor, but the deconstructor doesn't free it?
    - fake-name 1y ago
      - ptr isn't declared in the class body - ptr is not being deallocated in the destructor (personal preference - use of class member without explicit `this->`)
      - setr 1y ago
        If ptr is some kind of global, then it makes sense for it not to be deallocated by the destructor? It’s apparently not really managed by this class, so why would its lifetime be tied to it? I mean it’s psychotic to half-manage it like this but I don’t think the lack of a destructor is suspicious here; in fact I think it’s correct once the global pointer was introduced
godelski 1y ago
I didn't say "no code" and I'm definitely not against some screener type of questions. But I am against having 6 rounds of interviewing and at least 3 of those being coding challenges where there's right answers to be gamified and made into a website or book for people to pay to memorize.
- maccard 1y ago
  My preferred loop is: 15m recruiter screen (1hr Take home goes here if you’re doing it) 30m hiring manager call 1hr tech interview 1hr team fit And a go/no go at that point. You can put the hiring manager call at the end if the hiring manager is a senior enough person that you need to protect their time. The tech test should be actual code, but not evaluated for syntax. I like a code review test but we’ve also done problem solving and writing pseudo code in the past. No let code, no algorithms and no tricky formulas. If you want one of those you should provide the formula. A good tech interview should be open ended enough that you can dig into whatever direction the candidate goes - if they go hard onto concurrency then follow that track, or if they go into testing then follow that track.
rstuart4133 1y ago
I came across a version of a "just talking" interview which did work. You asked them to provide bring in a representative body of their code to the interview. During the interview, you ask them to give you any overview of what the project was supposed to do, how well it worked, what they would change in retrospect. As they do so you're scanning it looking for interesting or quirky bits. Then you ask them to explain the reasoning behind those particular lines in detail. This lets you get a feel for their coding style, comments, unit testing and so on. The "explain why you did it the quirky way" is for proof of authorship. You may learn something from it as well. It's a bit of work for interviewer, but far less stressful for the applicant than coding tests. But it's easier for the interviewer in some ways too, as you don't need conversation starters - the "tell me about this project" step is a perfect way to find out about their previous experience. As you say, the charlatans are very good. I even tried bring in sales, with explicit instructions that their job was to spot the bullshitter. They were no better at it than we engineers.
- lisbbb 1y ago
  After about 150 interviews, I could do the "just talking" thing without needing any samples or anything else. If they were working on Java, I would ask what versions, what issues they had run into, what their experiences had been with various frameworks they mentioned on their resume, I would bring up recent events to see if they knew about them, just stuff like that could tell me whether someone was senior level or not.
  - SpicyLemonZest 1y ago
    Recent events in... Java? It seems entirely reasonable for a senior developer, at least in a company that's large enough they're not writing their own development environment, to not know what versions they've used or keep up to date with Java language news.
- SpicyLemonZest 1y ago
  Sounds like one of the many, many alternatives which "works" by just targeting a different subculture. This "representative body of code" idea is very strange to me - I don't have any such thing that I could bring to interviews, it's never occurred to me to write one, and my areas of specialization offer me no opportunity to generate one organically. If this were the standard interview process, of course, I'm sure I could figure it out. There would be a site called "Leetportfolio", and I'd prep for interviews by implementing dozens of Leetportfolio mediums, and people would come to HN to complain about the obnoxious companies that expect you to include some Leetportfolio hards. For me this sounds significantly more time consuming and no less artificial or frustrating than Leetcode grinding.
xiande04 1y ago
I like these types of interview problems. I did one in Python once. We also had it so that persistence to Postgres indicated that the DB was in a very de-normalized state, so they could comment on that for bonus points.
lisbbb 1y ago
I had one of those "spot the issues" quizzes on an interview once. I didn't do that well on it just because I was nervous as hell. In retrospect, it was a good thing they didn't want to hire me. But it was a dumb request to place on someone "hey look at this class from our codebase and tell us what's wrong with it!" I'm thinking: "Should I just praise how good it is? What are they asking me here?"
- maccard 1y ago
  > I didn't do that well on it just because I was nervous as hell. The problem is everyone gets nervous. The only way to avoid that is paid work trials and to decide whether you want to keep hem after 90 days. But that requires the person to quit their job. > "hey look at this class from our codebase and tell us what's wrong with it!" Ours is a self contained example, littered with absolutely obvious errors that anyone who has written the language being interviewed for (C++) should be able to spot a least 2-3 issues with. There are absolute glaring fundamental issues in about 50 lines of code and you are explicitly told there are numerous errors with it.
megamindbrian2 1y ago
[dead]

dent9 1y ago

It sounds like you should just use better programming languages that don't break constantly.

Buttons840 1y ago

> when confronted with with a 50 line class full of glaring issues Would this work with any language other than C++? In almost every other language the only ways the code can actually be broken is if there's undefined variables or something. Sure, any language can have logic bugs, but that would require more than 50 lines to be certain of. I mean, even if the code says something like `total /= 0`, yeah, it looks wrong, but, I'm not 100% certain it's wrong with just 50 lines of context. Were these programmers lying about their decades of experience? Or did they really get by with writing broken C++ all those years without knowing the basics? What a language! I think C++ is a special case when it comes to interviews.

maccard 1y ago
It’s a self contained class that is littered with basic errors and doesn’t actually do what it’s supposed to do. There’s about 15 things wrong - missing pointer checks, uninitialised variables, public variables with private get/set functions, a memory leak, logic bugs that don’t do what the prompt says it’s supposed to do, subtle behavioural issues that come up in edge cases. We’re not looking for every single one, but there is an alarming number of people who cannot identify even the most glaring issues of “there’s a new in the constructor and not a delete in the destructor”. > Or did they really get by with writing broken C++ all those years without knowing the basics? Having inadvertently hired a handful of people, it’s this. They write shonky c++, it just about works, but they spend all their time patching up the mess they’ve left behind rather than doing it right in the first place > I'm not 100% certain it's wrong with just 50 lines of context. These are blatant issues that we would expect a reviewer to catch in isolation. It’s also an interview, we expect you to ask questions. You’re told as part of the brief to ask questions if you’re unsure. It’s not a trick, we’re looking to see if you can actually write the code or if you just can rattle off some of the rules. A good example is DIY. How do you install a shelf - you drill a few screws into the wall and stick a piece of wood on it. Being able to tell you that is very different to being able to do that level on a wall. I can tell you “use SQL to select the name of the users who have used X resource without any duplicates”, but I might not actually be able to write that query (“select name from table group by X where Count(X) > 1”) > I think C++ is a special case when it comes to interviews. I disagree. Give me a language and I can give you 50-100 lines of code that just about does what it’s supposed to do but is littered with issues. Offhand I could write the same thing for C#, go, python and SQL with very little issue.
- Buttons840 1y ago
  Thanks for the additional detail. It sounds like a great interview question; it's both easier, and yet more real-life, than something like "write fizz-buzz".
godelski 1y ago
> even if the code says something like `total /= 0` In what context would this not be wrong? I mean... it might run or compile but our best case scenario is what, javascript where it returns infinity? But I'd certainly take issue with any program where I saw an explicit division by zero. If you were just trying to create an infinity there's got to be a good explanation for doing it that way.
- Buttons840 1y ago
  It could trigger an exception which is caught elsewhere, or round the number to Inf or -Inf. It's a "clever" (aka, stupid) way to do these things, but it might not technically be wrong. It is possible to have well behaved and reliable code doing such a thing, unlike UB in C++.

OJFord 1y ago

I wonder how many of them would do fine not under pressure though. You're not (necessarily) weeding out experienced people who can't find actual problems in a 50 line class full of glaring issues, you're weeding out those who can't under pressure in an interview setting.

maccard 1y ago
I don’t necessarily disagree but anyone who is a c++ programmer and sees class foo { public: foo() { ptr = new other(); } ~foo() { } }; And doesn’t immediately question it doesn’t instil confidence. Interviews are inherently high pressure situations for the candidate, the only way to avoid that is to just let people try out on the job and fire them if it isn’t working out. That’s unfair to everyone.
- atomicnumber3 1y ago
  Forgive me, I'm a Java programmer. The glaring bug here is that ptr is - or rather the object being pointed to is - on the heap and allocated in the constructor, but the deconstructor doesn't free it?
  - fake-name 1y ago
    - ptr isn't declared in the class body - ptr is not being deallocated in the destructor (personal preference - use of class member without explicit `this->`)
    - setr 1y ago
      If ptr is some kind of global, then it makes sense for it not to be deallocated by the destructor? It’s apparently not really managed by this class, so why would its lifetime be tied to it? I mean it’s psychotic to half-manage it like this but I don’t think the lack of a destructor is suspicious here; in fact I think it’s correct once the global pointer was introduced

godelski 1y ago

I didn't say "no code" and I'm definitely not against some screener type of questions. But I am against having 6 rounds of interviewing and at least 3 of those being coding challenges where there's right answers to be gamified and made into a website or book for people to pay to memorize.

maccard 1y ago
My preferred loop is: 15m recruiter screen (1hr Take home goes here if you’re doing it) 30m hiring manager call 1hr tech interview 1hr team fit And a go/no go at that point. You can put the hiring manager call at the end if the hiring manager is a senior enough person that you need to protect their time. The tech test should be actual code, but not evaluated for syntax. I like a code review test but we’ve also done problem solving and writing pseudo code in the past. No let code, no algorithms and no tricky formulas. If you want one of those you should provide the formula. A good tech interview should be open ended enough that you can dig into whatever direction the candidate goes - if they go hard onto concurrency then follow that track, or if they go into testing then follow that track.

rstuart4133 1y ago

I came across a version of a "just talking" interview which did work. You asked them to provide bring in a representative body of their code to the interview. During the interview, you ask them to give you any overview of what the project was supposed to do, how well it worked, what they would change in retrospect. As they do so you're scanning it looking for interesting or quirky bits. Then you ask them to explain the reasoning behind those particular lines in detail. This lets you get a feel for their coding style, comments, unit testing and so on. The "explain why you did it the quirky way" is for proof of authorship. You may learn something from it as well. It's a bit of work for interviewer, but far less stressful for the applicant than coding tests. But it's easier for the interviewer in some ways too, as you don't need conversation starters - the "tell me about this project" step is a perfect way to find out about their previous experience. As you say, the charlatans are very good. I even tried bring in sales, with explicit instructions that their job was to spot the bullshitter. They were no better at it than we engineers.

lisbbb 1y ago
After about 150 interviews, I could do the "just talking" thing without needing any samples or anything else. If they were working on Java, I would ask what versions, what issues they had run into, what their experiences had been with various frameworks they mentioned on their resume, I would bring up recent events to see if they knew about them, just stuff like that could tell me whether someone was senior level or not.
- SpicyLemonZest 1y ago
  Recent events in... Java? It seems entirely reasonable for a senior developer, at least in a company that's large enough they're not writing their own development environment, to not know what versions they've used or keep up to date with Java language news.
SpicyLemonZest 1y ago
Sounds like one of the many, many alternatives which "works" by just targeting a different subculture. This "representative body of code" idea is very strange to me - I don't have any such thing that I could bring to interviews, it's never occurred to me to write one, and my areas of specialization offer me no opportunity to generate one organically. If this were the standard interview process, of course, I'm sure I could figure it out. There would be a site called "Leetportfolio", and I'd prep for interviews by implementing dozens of Leetportfolio mediums, and people would come to HN to complain about the obnoxious companies that expect you to include some Leetportfolio hards. For me this sounds significantly more time consuming and no less artificial or frustrating than Leetcode grinding.

xiande04 1y ago

I like these types of interview problems. I did one in Python once. We also had it so that persistence to Postgres indicated that the DB was in a very de-normalized state, so they could comment on that for bonus points.

lisbbb 1y ago

I had one of those "spot the issues" quizzes on an interview once. I didn't do that well on it just because I was nervous as hell. In retrospect, it was a good thing they didn't want to hire me. But it was a dumb request to place on someone "hey look at this class from our codebase and tell us what's wrong with it!" I'm thinking: "Should I just praise how good it is? What are they asking me here?"

maccard 1y ago
> I didn't do that well on it just because I was nervous as hell. The problem is everyone gets nervous. The only way to avoid that is paid work trials and to decide whether you want to keep hem after 90 days. But that requires the person to quit their job. > "hey look at this class from our codebase and tell us what's wrong with it!" Ours is a self contained example, littered with absolutely obvious errors that anyone who has written the language being interviewed for (C++) should be able to spot a least 2-3 issues with. There are absolute glaring fundamental issues in about 50 lines of code and you are explicitly told there are numerous errors with it.

megamindbrian2 1y ago

[dead]