Live data from Hacker News

Coding interviews are stupid (ish)

darrenkopp.com

631–640 of 679 posts

Re: Coding interviews are stupid (ish)

#631

Earlier quoted context omitted.

> I'm not saying it should be mandatory, but they would have to show mastery some other way. Whiteboard? Live coding? Project? godelski said your resume should really be GitHub. You could have said this instead of sarcasm.

Typically the people without side projects also make excuses to not do those either. If I had a company I'd offer looking over an existing project or a project where you create a side project of your choice without any further direction. So not mandatory but the easiest way to go probably. Once you apply to my company you'll have one to show for next time at least. (If you want to write the project out on the whitebo…

Many people do not have side projects. Few people working as software engineers were not tested in some way.

I think it's more useful and more fair to give candidates some direction when I request something. What scope is enough? What tests are enough? We define side project differently or you would expect much more time from candidates than I do.

Re: Coding interviews are stupid (ish)

#632

Earlier quoted context omitted.

Some people genuinely freeze up or overthink to their detriment in an interview setting, despite being competent otherwise. Happened to me a couple of times back in university when I had to get an internship for one of the semesters.

This, I freeze up when put on the spot, otherwise I can actually code, but it doesn't seem like it when doing coding interviews.

I interview best when I'm relaxed and it doesn't feel like there's a lot riding on the interview. What has worked for me is to interview early (when I feel "maybe I should leave my current job", rather than "I have to leave this awful job ASAP or I'll lose my mind"). Even then, I've had bad interviews - where it's like forgetting your own phone number or PIN; It's hard to recover from your brain short-circuiting early on, I suspect my interviewers may have thought I'm a fraud too, but such is life.

Interviewing has plenty of randomness - on a few occasions, the stars were aligned and I solved sequences of very challenging technical questions much quicker than the interviewers had planned, which gave the impression that I'm some sort of genius. That performance was not representative of my usual capabilities, but I didn't tell them that (:

Re: Coding interviews are stupid (ish)

#633

Earlier quoted context omitted.

Do you think working at a FANG would make you a better developer? I’m sorry but I think that’s a bad expectation, hire from a startup if you want great developers, their span of control and influence is much wider. Most of us at FANG are pigeon holed into a very narrow topic, have to work with really annoying, slow and complex internal build systems. And write very little actual code. Also, unless you have global sca…

> Do you think working at a FANG would make you a better developer? No, but I do expect any reasonably competently run company to figure out that the person they hired isn't actually able to do their job, especially after 7 years. I was also under the impression that this company actually did coding challenges as part of their interview process, yet this person managed to slip through their interview process. On the…

> No, but I do expect any reasonably competently run company to figure out that the person they hired isn't actually able to do their job, especially after 7 years.

Oh, they did. This person probably did not get paid as much as their peers. A great deal of compensation is discretionary.

Whether any decision-maker actually stood to benefit from removing this person from their position is another matter, however. Firings seem very uncommon, and layoffs depend on business conditions.

Re: Coding interviews are stupid (ish)

#634

Earlier quoted context omitted.

Typically the people without side projects also make excuses to not do those either. If I had a company I'd offer looking over an existing project or a project where you create a side project of your choice without any further direction. So not mandatory but the easiest way to go probably. Once you apply to my company you'll have one to show for next time at least. (If you want to write the project out on the whitebo…

Many people do not have side projects. Few people working as software engineers were not tested in some way. I think it's more useful and more fair to give candidates some direction when I request something. What scope is enough? What tests are enough? We define side project differently or you would expect much more time from candidates than I do.

> What scope is enough? What tests are enough?

How each candidate answers each question themselves tells you about them.

Re: Coding interviews are stupid (ish)

#635

Earlier quoted context omitted.

The IT job market is a two sided lemon market, people may lie on their CV but companies can be very abusive as well. If you don't do what OP suggests, people will not respect you. I've had five developers join my interview call to see if I can implement a palindrome checker. This is proof that non of them bothered to read my CV and check out my github projects. This is not respectful, and you have to stand your groun…

Was it the task itself you feel was disrespectful or the way they ran it? Anyone can put up fake/inflated CV so it's not really proof they didn't bother to read it, GitHub can be easier or harder to fake/inflate depending on the projects. Doing something like a quick palindrome checker to show "Hey, yep - I'm real not some random inflated applicant you probably got 10 applications of alongside mine" seems more than r…

Why even show up with 5 people.

Re: Coding interviews are stupid (ish)

#636
post #356

Earlier quoted context omitted.

> Also if a senior person can't in 30/45 min of talking with someone figure out the general experience level then the problem is them, really. OK take it as read that your posturing has succeeded and we all agree that you're a brilliant interpersonal genius and the rest of us are all useless chumps. What then? The rest of us still need to interview and make hiring recommendations. Or are you suggesting that employers…

Why would you read that? I just mean that if you put 2 experienced people talking about a topic they both know, it should be pretty easy for both (or at least the interviewer) to get a rough understanding of the level of the interviewee.

> I just mean that if you put 2 experienced people talking about a topic they both know, it should be pretty easy for both (or at least the interviewer) to get a rough understanding of the level of the interviewee.

Well, in my experience it's not, at least not in a "hostile" context. Most technical people are used to assuming good faith in technical conversations, and there are some very smooth bullshitters around; it's easy to construct a verbal facade that only falls apart once you ask someone to actually code.

Re: Coding interviews are stupid (ish)

#637
post #356

Earlier quoted context omitted.

> Also if a senior person can't in 30/45 min of talking with someone figure out the general experience level then the problem is them, really. OK take it as read that your posturing has succeeded and we all agree that you're a brilliant interpersonal genius and the rest of us are all useless chumps. What then? The rest of us still need to interview and make hiring recommendations. Or are you suggesting that employers…

Why would you read that? I just mean that if you put 2 experienced people talking about a topic they both know, it should be pretty easy for both (or at least the interviewer) to get a rough understanding of the level of the interviewee.

It's not. You will find plenty of examples in this very thread.

Re: Coding interviews are stupid (ish)

#638

Earlier quoted context omitted.

Yeah I think that’s what I mean by “understand data structures and algorithms”. Or, I think your description is exactly what a useful working understanding looks like. You should know broadly what’s out there so if a problem comes up, you know where to look. (Would a hash table help? A priority queue? etc). And you should be skilled enough such that if you decide to use a red-black tree, you can find a good library o…

I agree that I think this is what most experienced people mean when they think of understanding data structures and algorithms. The problem is that this kind of understanding is very rarely what coding interviews check for. They either don't check for this at all - instead just making sure people can write simple code while reasoning through a simple problems under time pressure - or they check for whether people mem…

My recommendation is to have a lot of different stuff in an interview, so you aren't making a final judgement on someone over any individual part of the interview. That means the candidate can stuff up one or more parts of the interview, and you can still get good signal.

For example, do all the things you suggest. Get them to write some simple code. Talk to them about an algorithm problem. Also, give them some simpleish code with some failing unit tests and ask them to debug the code. (This requires some prep, but its a fabulous assessment to do.) Ask them about their prior work. Just do everything you can think of, and don't give any specific part of the interview too much time or attention.

In my experience, this gives candidates a lot more opportunities to impress me. I don't really care if one person on our team is particularly weak on data structures. Its kinda better if we have someone who's an absolute gun at debugging, and someone else who's amazing at data structure work. That creates a better team than if everyone is impressive in the same way.

Re: Coding interviews are stupid (ish)

#639
post #555

Earlier quoted context omitted.

In my case the processing was happening in our backend. I can't remember exactly why it couldn't be SQL, actually it's possible it could have been sql. But changing it to sql would have been a bigger change and this wasn't really the task I was working on, I just happened across it while doing something else. I have also seen and fixed similar travesties where someone iterates through a huge list making one query per…

Unsurprisingly we've now reached the perennial "is premature optimization actually premature" of it all :) Would it have been better for the person who originally wrote that just-iterate-the-list implementation to have been thinking about data structures and algorithms that would perform better? Opinions on this vary, but I tend to come down on the side of: Optimize for human productivity (for both the writer and the…

> Optimize for human productivity (for both the writer and the many future readers) first, then profile, then optimize any bottlenecks.

I don't agree. The problem with this approach is that there are some optimisations which require changes to how data flows through your system. These sort of refactorings are much more difficult to do after the fact, because they change what is happening at the abstraction / system boundaries.

Personally, my approach is something like this: Optimise first for velocity, usually writing as little code as possible to get something usable on the screen. Let the code be ugly. Then show people and iterate, as you feel out what a better version of the thing you made might look like - both internally (in code) and externally (what you show to humans or to other software systems). Then rewrite it piece by piece in a way thats actually maintainable and fast (based on your requirements).

Re: Coding interviews are stupid (ish)

#640
post #484

Classic mistake of overthinking it and failing to realize what interviewer really wants - which is to make sure the candidate can actually write code, like at all. The question itself doesn't really matter as much as it's just a pretext. I actually asked a variation of this question for many years at Google and it was clear within first 5 mins who has been writing code day-to-day and who's been mostly "brining key st…

>Classic mistake of overthinking it and failing to realize what interviewer really wants - which is to make sure the candidate can actually write code, like at all. What about the lad who develops homebrew who got rejected from Google because he wasn't able to invert a binary tree on the spot? Many Googlers use his software internally and externally. If the purpose of the interview is to make sure he can code why did…

Not even Max Howell thinks Max Howell has a great attitude. He's often a dick in his own words. Maybe Google would have found a different job for him if he wasn't.

He said 90% of Google engineers used Homebrew. Google engineers said it wasn't true.[1]

He said Homebrew using OS libraries saved a lot of pain. He presented it as an example of why Google should have hired him. Actually it caused enough pain Homebrew stopped it.

[1] https://news.ycombinator.com/item?id=23844936

Post reply on HN