Live data from Hacker News

How to conduct a good programming interview

lihaoyi.com

71–80 of 188 posts

Re: How to conduct a good programming interview

#71

Earlier quoted context omitted.

> I completely understand the need for these technical interviews and weed out obvious bad programmers and get experts on board but sometimes from a business point of view it just doesn't make sense. The thing is that the main goal of the technical interview is not to hire all good candidates. The main goal is to avoid hiring bad candidates. A large high paying company like Facebook has plenty of candidates to choose…

>> The cost of failing to hire a good engineer is small I'm not so sure about that. https://en.wikipedia.org/wiki/Jan_Koum "In September 2007 Koum and Acton left Yahoo and took a year off, traveling around South America and playing ultimate frisbee. Both applied, and failed, to work at Facebook." "On February 9, 2014 Zuckerberg asked Koum to have dinner at his home, and formally proposed Koum a deal to join the Faceb…

But on the other hand if they had been hired, they just would be middle-level managers or second tier VPs and would not have created WhatsApp.

Re: How to conduct a good programming interview

#72

So reading over some of the questions posted on technical programming interviews I must say that I would definitely fail such an interview without studying for it for a month first. Having recently discussed job interviews of ex-colleagues that went to EBay, Facebook, Google, etc.. I wouldn't even pass the whiteboard test. However I'm shipping scaleable API's used by web and native apps, using Continuous Integration…

> I completely understand the need for these technical interviews and weed out obvious bad programmers and get experts on board but sometimes from a business point of view it just doesn't make sense. The thing is that the main goal of the technical interview is not to hire all good candidates. The main goal is to avoid hiring bad candidates. A large high paying company like Facebook has plenty of candidates to choose…

> Someone who is capable of learning what's needed to do well on a technical interview has demonstrated a fairly high level of competence, and is (relatively) unlikely to be a really bad hire.

Sure, as long as their only role is repetitive coding tasks that require limited amounts of broadening their experience beyond the DS&A trivia places like Facebook require.

However then Facebook ends up with stuff like their iOS app ("iOS can't handle our scale"), which had a lot of (probably) very talented CS folks putting together an app that was pure garbage (from an engineering and usability perspective).

The filter limits the applicant pool to that set of people uninterested in solving problems outside the scope of a CS textbook. Capability has little to do with it.

Re: How to conduct a good programming interview

#73

Earlier quoted context omitted.

So likely thinking of it in terms of checking a tree based on characters instead of hashes of full words. Which is more viable would likely depend on what kind of memory constraints and dictionary size was being considered. Also very implementation dependent, what's the size of the hashes generated? Edit: curiosity got me looking at this for Python, with an answer of "it depends, and both have correct aspects" based…

It's also possible the interviewer meant linear time as a function of the length of the word, which would be true. Regardless, not being able to express this clearly is a sign of a poor interviewer which unfortunately the candidate takes the hit for.

That was certainly not the case. Multiple times the interviewer "explained" that with my approach you have to run through every entry in the word list which is linear time. My guess is that the interviewer wanted me to mention a prefix tree of some type, and was completely blind to any other approach.

Re: How to conduct a good programming interview

#74

Here is how to do a good coding interview if you are a recruiter: 1. Do your homework: know what projects drive the interviewee (what kind of things she likes to code, what recent projects has she been involved in), make sure they are a match for your company projects and goals 2. Ask the interviewee for a git repository and take a careful holistic look at it (commit messages and code, timespan, branches, merges etc.…

I think you missed the part where the OP said not all candidates are willing or able to work on open source projects.

Well the .2 "Ask the interviewee for a git repository" can be a private repository. It is a very hard problem to solve if they have no visible code to show but it does happen in other areas. Imagine asking for a management candidate for the private e-mails he shared in certain tricky situations of previous jobs. Or even public e-mails. Or even to take 40 minutes to write in a whiteboard a team statement for a certain conflict scenario.

Trust is entailed when recruiting in most areas. But in programming not as much.

Re: How to conduct a good programming interview

#75
post #35

Earlier quoted context omitted.

There was no subtle argument. It only came up because I was on the whiteboard solving some simple word game that involved matching user input against a list of valid words (e.g. the Scrabble dictionary). When asked to explain the running time of the various operations, I said that we can store the dictionary in, well, a dictionary , and checking whether the user input is a valid word will be a constant time operation…

So likely thinking of it in terms of checking a tree based on characters instead of hashes of full words. Which is more viable would likely depend on what kind of memory constraints and dictionary size was being considered. Also very implementation dependent, what's the size of the hashes generated? Edit: curiosity got me looking at this for Python, with an answer of "it depends, and both have correct aspects" based…

Indeed, my best guess is that the interviewer had a mental check list and simply wanted me to say "prefix tree" or "trie" or similar. I suspect the debate over running time was just the interviewer's attempt to get me to say the magic word he wanted to hear. I also suspect the interviewer did not know much about hash tables or tries, or was so nervous and misguided about interviewing that the information was not readily recallable.

Re: How to conduct a good programming interview

#76
post #54

While there are a variety of ways you can conduct a programming interview, the goals typically are the same: Will the candidate be able to write working code if they join the team? Can the candidate discuss code and problems with the people they'll be working with? Can the candidate reason about arbitrary problems and constraints? Is the candidate someone we would enjoy working with? All of these can be solved direct…

This is an interesting candidate-first approach, but I have some concerns: This requires that candidates are experienced at the language or framework you use. Are you not prepared to take someone with different experience? What about graduates? What if their ability with one framework does not transfer to another that you end up assigning them to? Not all bugfixes are equal. If you haven't solved it yourself before,…

If the candidate isn't familiar with your particular language(s)/libraries/frameworks/etc, there may be a way where you can isolate a part of your process and provide a sample data set to the candidate and give them an operation to be performed on it.

Re: How to conduct a good programming interview

#77
post #6

Earlier quoted context omitted.

I also agree. As someone who has recently co-founded a startup, this is something my co-founder and I have spent a lot of discussing and exploring. My personal experience with this style of interview was that it really helped me to personally demonstrate my abilities. I was interviewing at a startup in San Francisco in 2012 who wanted me to do a quick version of "battleship" as part of their hiring exercise. I propos…

> They needed to "benchmark" me against other candidates, and the only way to do that was with a consistent "test". If your employer were ever sued by a candidate for discrimination and it came to light that you had received different treatment than other candidates, some very uncomfortable questions regarding the reason would be asked in the courtroom. An unfortunate bit of fallout from the litigious environment we…

Wouldn't it be (well, look) even worse if any number of the non-hires dud great on the battleship test?

Re: How to conduct a good programming interview

#78
post #23

So reading over some of the questions posted on technical programming interviews I must say that I would definitely fail such an interview without studying for it for a month first. Having recently discussed job interviews of ex-colleagues that went to EBay, Facebook, Google, etc.. I wouldn't even pass the whiteboard test. However I'm shipping scaleable API's used by web and native apps, using Continuous Integration…

While you can get away with only basic algorithmic skills and I also agree with your points about being able to ship/talk to users/etc I think that having decent algorithms & data structures skills is essential for a developer. For example I have worked on projects where people were not able to ship a product for a year with 10 people and our new 3-man team shipped within 6 months just because we figured out that an…

Counter-point: I am the technical lead on a team of 8. We ship a new data science product (or major enhancement to an existing product) about every 9 months, from inception through putting it in maintenance mode. Our products generate double-digit multiples of my team's costs in revenue and have a reputation for being the easiest to implement and most stable for our customers. We have one CS guy, who is a junior engineer, and he doesn't even have a Master's degree. I can't remember the last time an in-depth discussion about which data structures or algorithms to use actually came up in a design, or even mattered too much in the end.

The reason, as I see it, is simple: the engineering work the Principal Engineer and myself, with our juniors we mentor, do, is far more important than data structures and algorithms trivia. Once it gets to the point of deciding which of these to use the real problems have been solved already. Now, these choices aren't unimportant: the choice of a bad algorithm or data structure might cause problems, but they're choices that are in the main easy to understand and make when compared to the thought that goes in to the rest of the system.

Re: How to conduct a good programming interview

#79
post #20

Earlier quoted context omitted.

This may be like "approach anxiety" for when guys never strike up a conversation with a woman they are interested in because they think all women will reject them. Why not try and go on some interviews? How can you possibly know you will be rejected without even going on one interview? Do you think all companies are the same, and your competition is all prepared for whatever it is you imagine they are doing? You're s…

I believe your error here is "without even going on one interview". There are many developers who have proven their skills and abilities on the job, and also have a proven ability to repeatedly fail interviews. This is precisely why the developer interviewing process is such a hot topic here.

There's another aspect that I can speak to personally. My career never really got off the ground. For most companies I'd get through all of the technical phone interviews just fine and after the in-person interviews it was always a rejection. Coupled with my deteriorating financial situation that lead to a lot of depression and massive amounts of self-doubt.

To this day I still doubt my abilities quite heavily. Friends and coworkers say I'm smart and talented and whatever, but quite frankly I don't believe them. These interviews can be soul crushing to people with my type of personality.

Re: How to conduct a good programming interview

#80
> Hopefully in your realistic setting, the challenge comes from the difficult tasks you are given to solve, not some jerk that's sniping at you from the sidelines.

I wish I could say that's true. If you're getting sniped from the sidelines in your interview, it's probably a part of the culture where you are interviewing. So it's quite likely to be a non trivial part of the problem you're solving.

Post reply on HN