Live data from Hacker News

Coding Interview Cheatsheet

github.com

81–88 of 88 posts

Re: Coding Interview Cheatsheet

#81

Earlier quoted context omitted.

Because then it is hard to have a consistent and fair method of judging candidates.

Seems like you can’t compare even if you stick to one method. Some people have performance anxiety or social anxiety and can’t do 1. Others thrive on 1.

You might want to filter out those people.

Re: Coding Interview Cheatsheet

#82
post #5

> Defensive coding. Check for nulls, empty collections, etc. While this is important to avoid bugs in your algorithm, I've had candidates who spent way too long on this and it comes across as inexperienced. I don't really care that you know how to check null-ness, if you just mention "assume the parameter is not null", it's more than sufficient to me.

>if you just mention "assume the parameter is not null", it's more than sufficient to me. I am the same way. But some ppl seem to care about that stuff. Perhaps, asking in advance may help. not sure.

I usually am explicit in saying something along the lines of "Can it be assumed that I know how to do argument null checking, if possible, and not pollute the whiteboard?" and I've gotten a "Yes" and then after writing the function on the whiteboard: "Well what about ?"...so you should ask but YMMV

Re: Coding Interview Cheatsheet

#83
post #58

Earlier quoted context omitted.

Speaking as a person who could have gone down the path of becoming an accredited engineer but chose physics, and who has a number of friends who chose the accreditation path, I disagree.

Could either of you expand on your stances?

Accreditation in engineering is about certifying some level of competence according to the industry standards and practices. To the extent the accreditation is trusted, it means a person so accredited has already been vetted for some level of proficiency in the field.

There are plenty of CS degrees with ABET accreditation, for example. There are comparatively few for Software Engineering. The two are different disciplines. The friction in this context is that many companies wanting software engineers of varying levels of experience structure their interviews to test CS degree trivia. For whatever reason the basic competence of an accredited degree is simply ignored in the interview process.

My friends who graduated from accredited engineering programs and became Professional Engineers after don't have to prove to the satisfaction of some individual contributor that they did so by white boarding crap from their undergrad days: the certificate and accreditation is their proof.

As they gain experience, if they look for other jobs (which happens infrequently, actually: the culture of real engineer disciplines is different from computer based ones), that experience is trusted. They don't have to re-live it, so to speak, five times to five different people looking for anything to nitpick.

It's not perfect. But it makes me wonder why the CS and SE accreditations seem to have so little weight in this industry.

Re: Coding Interview Cheatsheet

#84
post #58

Earlier quoted context omitted.

Speaking as a person who could have gone down the path of becoming an accredited engineer but chose physics, and who has a number of friends who chose the accreditation path, I disagree.

Could either of you expand on your stances?

I learned to program at 8. My last 15 years of professional work have been in software development. I've led teams, spoken at major conferences, made significant contributions to open source software. I have never taken a CS course for college credit.

I've been a licensed attorney for most of that time. All it required was me being willing to spend 3 years in school, then sitting in a room and writing for 3 days to pass the bar. Since then I spend one weekend a year listening to audio books for continuing legal education, and don't otherwise practice aside from minor advice at work.

Which job would you be more likely to hire me for today? It'd be borderline irresponsible to hire me as an attorney, but I've proven myself time and again as a competent programmer.

By contrast, I've interviewed people with master's degrees from reputable CS programs that couldn't explain what the Big O complexity of an array index operation was. I've known attorneys who fundamentally did not understand the purpose of their work.

Accreditation is just a measure of someone's ability to pass accreditation, not their ability to do the job.

Re: Coding Interview Cheatsheet

#85
post #72

As far as a general behavior checklist, this one is fairly accurate in my interviewer experience. It is surprising how often candidates do many of the "Don'ts" in the list. In the end, I'm looking for candidates I can see myself working with. If we were to pair up on a task or project, I want to be reasonably sure I'm not going to dread the event; I should look forward to it. One example was a candidate from one of t…

I wonder if that's the reason why he wasn't at one of the big 4 anymore :)

But he did end up there somehow in there first place. What was his interview them like, I wonder?

Re: Coding Interview Cheatsheet

#86
post #66

"Ask about your interview performance. It can get awkward." Maybe it's just me, but I always find that to ask for/give feedback is better(if asked), as recruiters almost never respond if you have not cleared the round and if there is opportunity to give feedback so that candidate has an idea on what to work on. Also I have found that when asking for feedback, it can lead to interesting discussions which might make th…

One of the problems is you are not likely to get truly honest feedback. That opens things up to dispute, and that puts the interviewer in an awkward position: if they cannot articulate a point properly, even if valid, the interviewee is left feeling they should have "passed". In the worst case, they could claim the interviewer was prejudiced against them and file a labor dispute or lawsuit.

It's also often highly subjective, for example:

"I don't think you demonstrated the depth of knowledge in (technology x) we're looking for in this position"

"Well I've developed several applications that work, so clearly I do know it"

What you can do along the way is ask questions like "Would you like me to elaborate on that?" or "did I answer your question adequately?" if you get the sense you may not have. For code, the list on the page is actually decent - ask up front about the assumptions, how much you should focus on defensive coding, etc.

Re: Coding Interview Cheatsheet

#87
post #15

I can’t think of any other field where highly paid adult professionals willingly submit to interviews that treat them like autistic 15-year-olds. Makes sense for the companies, of course.

> Makes sense for the companies, of course.

It seems to select for poor candidates.

Re: Coding Interview Cheatsheet

#88
post #83

Earlier quoted context omitted.

Could either of you expand on your stances?

Accreditation in engineering is about certifying some level of competence according to the industry standards and practices. To the extent the accreditation is trusted, it means a person so accredited has already been vetted for some level of proficiency in the field. There are plenty of CS degrees with ABET accreditation, for example. There are comparatively few for Software Engineering. The two are different discip…

> It's not perfect. But it makes me wonder why the CS and SE accreditations seem to have so little weight in this industry.

That's easy, you can thank people like ESR and the hacker mentality and meritocracy myths for this. I appreciate the underlying idea, which is the same in every skilled based profession, which is that self learning and good skills are more important than formal education and accreditation. However, the two are not mutually exclusive.

Post reply on HN