Hacker News Reader

> 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.

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.

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

  > 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.

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++.

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.

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.

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?

- 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->`)

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

IMHO, there are two review branches to discuss in this example:

First, if `ptr` is declared in the translation unit before and outside defining `class foo`, then there is no check for previous initialization and thus is likely a run-time defect.

Second, if `ptr` is not declared in the translation unit before and outside defining `class foo`, then it is likely a missing member definition and is a compile-time defect.

> "ptr isn't declared in the class body"

I would assume the interviewer messed up and forgot to declare it and if I just not pretend to assume it was "left out for brevity" I would fail the interview as a smart ass.

There are so many layers to interviewing and you kinda need to guess what the intervoewer wants to hear.

In my defence, this is a HN comment thread and not an actual interview. I wrote that on my phone at 6pm on a Sunday.

We have an actual question, a snippet of code that is copied and shared to the candidate, and everyone who asks this question has undertaken this exercise. The interviewer has the list of (known) issues and a handful of stylistic things that can be talked about too. If we actually did share this snippet with someone and they said "should this be declared in the class body", I would say "oops yeah, thanks for catching", and update our template.

>you kinda need to guess what the intervoewer wants to hear

Interviewers are human, and I've done tech screens for probably 250 candidates over the past few years, and I've designed tech screens that have been used for probably 5x that. We have good days and bad days, and it's super tough to give an evaulation of someone in an hour. The main thing I'm looking for (and I tell people this) is someone that I think would be a good fit on the team. To me that means that their own read on their level is roughly equivalent to my read on their level (a senior engineer who says they understand concurrency but doesn't understand what a mutex or atmoic is is a fail, for example), and that they're not a giant pain in the ass. If you've managed to annoy me in an hour by assuming every single thing I do is an attempt to catch you out, we're not going to get along and I'm going to pass on you for that reason.

Does this example even compile, given that ptr is not declared anywhere?

>Does this example even compile, given that ptr is not declared anywhere?

that comment was not a comment but an interview. and you just failed it.

Nope, I also missed a semicolon at the end of the class definition. But I wouldn't ding someone for that in an interview.

How could you ever know whether that’s the case? Obviously it makes sense to try to conduct the interviewer with a low-pressure tone, and perhaps make accommodations for people who seems especially nervous, but at the end of the day I don’t think a job interview has meaningfully higher pressure to perform than, say, the first few months of a new job.

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.

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.

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.

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.

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.

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.

>If this were the standard interview process, of course, I'm sure I could figure it out. There would be a site called "Leetportfolio"

It's called Github.

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.

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

> 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.

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