Live data from Hacker News

How to Pass a Programming Interview

blog.triplebyte.com

241–250 of 570 posts

Re: How to Pass a Programming Interview

#241

> This situation is not ideal. Preparing for interviews is work, and forcing programmers to learn skills other than building great software wastes everyone’s time. Companies should improve their interview processes to be less biased by academic CS, memorized facts, and rehearsed interview processes. This is what we’re doing at Triplebyte. Thank you! This is a good write up and just like it concludes it's far from ide…

  Honestly though my biggest issue with interviews is
  the lack of response with a negative result.
Exactly mine too. However:

  If something is wrong with a candidate and they don't fit that's perfectly fine.
  But please give them accurate and detailed feedback where possible.
Detailed feedback is hardly ever possible. Not only because of a fear of litigation (which is a big factor too) but also because the hiring decision is a matter of balancing so many different points.

Re: How to Pass a Programming Interview

#242

It seems like there is a large middle area of concepts in between low-level algorithms/data structures and high-level system architecture that are left out of many of these interview prep guides: * Principles and patterns of object-oriented (or functional) design * Relational (or NoSQL or analytics) database design * Unit, integration and system testing * Logging, profiling and debugging * Source control (e.g. branch…

Sure they do. "Model a parking garage in code" or "design a database with customers, orders, etc" are classic interview questions.

Re: How to Pass a Programming Interview

#243
post #131

Earlier quoted context omitted.

i often just refer to it as waterboarding.

Have you ever been waterboarded? Putting waterboarding on the same level as whiteboard coding interviews is minimizing the horrific experience of those who have been waterboarded.

Putting waterboarding on the same level as whiteboard coding interviews is minimizing the horrific experience of those who have been waterboarded.

I guess it is, if you read it literally. But I don't think people mean it literally when they joke about it, nor are they making a serious comparison between the two experiences.

Re: How to Pass a Programming Interview

#244

Being a good programmer has a surprisingly small role in passing programming interviews. And that just says it all, doesn't it? I agree that interviews should test candidates on certain basic skills, including (time/space) complexity analysis. But do you really learn anything by asking the candidate if they can recite the time complexity of a moving window average algorithm (as I was asked to do by an interviewer yes…

I personally also prefer take-home projects over being grilled on my ability to solve obscure algorithms problems under pressure. However, this second route also comes with a number of issues. The most annoying of which in my experience is the amount of time investment each interview requires from the candidate. At least in the traditional technical interview, interviewers and candidates tend to be roughly equally in…

Ironically enough, Triplebyte's own take-home projects were some of the worst I've ever had, and did a horrible job of respecting the candidate's time.

When I went through the their take-home interview process, there were 4 projects to choose from, with only one having anything remotely to do with my area of expertise (it was a multiplayer game, and I was looking to work as a web front-end/full-stack developer). For all their talk on how you should select a practical project to talk about because it correlates better to ability to get real work done, it's really rather ironic just how utterly academic and unpractical the projects they offered were (that game was literally the most practical one on the list).

Now they tell you that you're expected to spend at most 3 hours on the project. This might be true for some of the other more academic projects on the list if you had any expertise in the respective areas, but it definitely wasn't true for the multiplayer game project I chose, which had a non-trivial front-end and back-end component, for which testing alone could easily take 3 hours (Or maybe I'm just bad, which is definitely possible, but I've asked many of my more experienced peers how long they think a project like this might take for them, and the lowest estimate I got was a whole work day of 8 hours).

Now they also tell you that it's OK if you don't finish the project. There was also a second part to the interview where they may ask for extensions to the original project, where they'd give us more time to work on it, so I assumed if we don't finish, they'd ask for us to finish the original spec along with some extensions for the second interview. Since I had already finished the front-end component for the game, and had worked on the project for well over the expected 3 hours, I decided to call it a day and work on preparing for some of the other interviews I had that week.

However, that it was OK to not finish the project for the first interview might have been an outright lie. I won't ever know for sure because I was rejected after the first interview for not finishing the back-end as well as being unable to resolve some performance issues the interviewer pointed out (which at no point in the interview did he even ask for me to fix, so I assumed fixing that performance issue would also be a part of the extension). Incidentally, I went back to the project a while after the interview and resolved the performance issue in 5 minutes flat.

The whole process just left a rather bitter taste in my mouth, which was all the more disappointing because I went in with great hopes after reading all their great blog posts on HN. For anyone else considering Triplebyte, I'd highly recommend going with their traditional interview route until someone at Triplebyte can confirm the process has changed for the better. At least with that route, if you get rejected, you'd have wasted less time in the process.

Re: How to Pass a Programming Interview

#245

Earlier quoted context omitted.

I wrote some Ruby in an interview. It was so terse, I had to explain to the interviewer (who favored Java) what the code did, and why it was linear instead of O(n^2). That was actually kind of fun.

If your code is sufficiently terse that it's not very understandable (such that the complexity isn't very understandable) surely that's a realistic red flag?

My shipping boxes hold an even number of widgets, but I "have to" sell odd quantities and those need expensive mil spec styrofoam peanuts added to fill the hole. Here, have an array of possible shipment sizes. Given that array, if its shipping an odd number of widgets I wanna add an additional half widget shipping charge.

newshipping = oldshipping.select{|i| i % 2 == 1 }.map{|i| i + 0.5 }

My ridiculous fictional writing about shipping widgets is way more confusing than the idea that you can select and then chain right into a map.

This probably looks really weird to a java guy but its not really all that mysterious. I wonder what that looks like in Java.

Re: How to Pass a Programming Interview

#246
post #14

What if designers had to go through a similar interview process? Here are some colors, please arrange them in palette groups that are color coordinated for a given visual effect? Why is red font on blue background bad, please justify? That would simply be hilarious.

You jest, but my family members in the restaurant industry asks similarly technical questions of a potential chef. Stuff they may not need to know on a day to day basis, but is the technical knowledge of their profession. I discovered their interviews and mine are largely the same. Technical questions, some time-management questions, and some soft stuff to make sure they'd fit in the team.

The typical Silicon Valley style interview equivalent for a chef would be to have said Chef participate in Chopped. Plenty of professional chefs do awful in Chopped, because the required skills have little to do with what you need, day to day, in a kitchen. However, it's easy to judge. What is missing is the correlation between a hard test and actually on the job performance.

Re: How to Pass a Programming Interview

#247

I look forward to seeing more articles that find ways to game the interviewing process. Perhaps showing interviewers how easily their hiring process could be gamed will 'inspire' improvements in interviewing.

Countless books have been written on this topic, so my money is on no.

Re: How to Pass a Programming Interview

#249
post #42

Is it weird that I find this entire blogpost eerily similar to PUA strategies? I think it ultimately boils down to confidence. To use the dating analogy, nothing drops the proverbial panties (or boxers, if you're into that sort of thing) faster than having confidence. Being physically attractive (i.e. fit and in shape) doesn't hurt either. Take my analysis with a grain of salt, though. I happen to be hilariously bad…

I can't tell you how much dating advice I've read that advises you to be sure you remember breadth- and depth-first search algorithms.

Re: How to Pass a Programming Interview

#250

I really wish that at some point during my CS education I would have realized how typical programming interviews worked and just how impossible they are for me. None of my internships had this sort of stuff and after a long string of failures interviewing after graduating, I can openly admit that being able to solve algorithm stuff just isn't in my blood. It doesn't matter how many books I read or questions I practic…

One thing that helped me was to actually implement things that made use of the "algorithm stuff." Not just practicing in front of a whiteboard, but real executable code! In particular, anything involving a Tree was never very intuitive until I tried implementing a script to search for files by name. Suddenly both the recursive and the iterative approaches made sense. I understood the trade-offs because they applied d…

> actually implement things that made use of the "algorithm stuff."

Part of the problem is that the overlap between "concepts used in technical interviews" and "practical things I would actually implement" is very small. So to take your approach, I'd have to go out of my way to implement something that, in the end, would have no utility to me.

Granted, there are developers out there who do take on really technical projects for fun. It seems like every language has at least one implementation of the GNU `coreutils`, which I'm sure requires at least some algorithm expertise. And there are, of course, jobs where the technical is really important (systems-level, research divisions, etc).

But for the most part, the types of interview questions they ask in no way correspond to the actual on-the-job requirements. I find it strange how common it is to interview web developers (or, engineers whose job will effectively be web development) as if they are C programmers.

Post reply on HN