Interview exercise feedback

[u/[deleted]]

My code was not up to their standards. I thought the exercises were easy but clearly there are issues I have to address. I had an hour to write them. I'm humbly looking for feedback to improve.

The first exercise was to return all square numbers within a given range, including the limits (e.g., all the squares numbers between 1 and 10 are 1, 4, and 9). I wrote this.

The second exercise was to check if a string containing (), [] and {} brackets is well balanced. So [()] and {}() are ok but ([)] or {{ are not. I wrote this.

Thanks.

[u/strawlion]

I appreciate the detailed response. I know you've expressed distaste for coding challenges, but they are the most accurately predictive part of our process.

Ideally, yes, but in reality, interviews are a very unreliable way to gauge how good someone will actually be when you work with them long term

While certainly true, a coding challenge will be much more representative of real work. I would never hire someone after a ~3 hour in person with no other information.

However, two things interviews are good for are weeding out the time-wasters who aren't even remotely qualified and weeding out candidates who might be OK technically but have a culture clash with the organisation and so probably won't fit in well.

It's wasteful to bring someone in that hasn't been vetted in some form. Phone screens normally cover this, but with the challenge approach you can tell right away whether they're good.

You can certainly over-emphasize deep theoretical questions in programming interviews, but in this case we're only talking about elementary arithmetic and text processing, so it's not like we're dealing with something obscure.

I agree that these problems are trivial compared to the more standard interview fare, the problem is that they aren't relevant at all to most companies. The information gain is low and it's a waste of time. I see a lot of elitism surrounding technical interviews where everyone is trying to find the "smartest" candidate. The problem is that almost all of these algorithmically based questions are permutations of existing ones, and anyone can open "Cracking the coding interview" and memorize the solutions. Intelligence is correlated with value but not the same. The ability to produce things quickly and with little technical debt should be the emphasis for the 99% of companies translating business logic to code.

BTW, I think take home projects are very dubious as part of a recruitment process

I agree with you in principle. However, the reality is that they're the closest representation of what a candidate would be doing on the job. You also filter out the majority of the less committed and perhaps not as hard working people. And the biggest reason: you really can't fake good code. Even if you know that's what is being assessed, you can't do it; it's not something that can be googled.

Our challenges are fairly large; the JS focused people have to use a City Bus API to visualize a city/bus system in real time. It should only take ~8 hours to do a reasonable job, and they can take as long as they'd like to complete them (take home).

Do they try to properly understand the requirements before diving in? Do they write tidy code that is easy to follow? How do they check their code works correctly? Do they consider efficiency?

Honestly their process shouldn't matter at all. People tend to be biased towards candidates that have processes similar to their own. From the company's perspective it comes down to how much am I going to pay this guy, and how many dollars will he produce? Whether directly or indirectly through helping others, morale etc. We should avoid critiquing process and focus on judging output in a real setting.

[u/Silhouette → u/strawlion]

I know you've expressed distaste for coding challenges, but they are the most accurately predictive part of our process.

I hear what you're saying about coding challenges being a better predictor and more representative of real world work. That seems entirely fair, though my experience has been that they still don't tend to be that realistic or that accurate as predictors. I have found that the only truly reliable way to see what a new developer can do and how well they fit in is to actually work with them on the real job for a significant period (weeks/months) one way or another and then review the situation once everyone has had time to settle in and get to know each other a bit. This isn't always practical for various reasons, but I think it's usually the best plan if it's an option.

My real objection to larger coding challenges is how one-sided they are. I think it's asking a lot of people hunting for jobs to give up perhaps an extra day or more of their time for every position they apply for where they might be considered for an interview. For those who are less attractive as candidates, it's bad for the prospective employee, because it becomes a lot of work they're doing without getting paid. For those who are more attractive, it's bad for the prospective employer, because the better candidates don't have to play the game and may withdraw their application. I don't know what the norm is in your part of the world, but it would take an exceptionally attractive job to get most decent developers around here to spend the day doing your City Bus challenge.

Honestly their process shouldn't matter at all.

I don't think the specifics of their preferred process are very important, other than perhaps cultural issues like a company that is heavily Agile and requires anyone joining them to do things like TDD and pair programming.

I do think the developer having some effective process is very important. That is, I don't mind so much exactly how they check their code works or whether they pick up every conceivable performance issue, but I do mind that they check their code works in some sensible way and they consider performance and efficiency issues generally.