Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How to win the coding interview

blog.devmastery.com

Post reply on HN
Print view View original

181–190 of 305 posts

Re: How to win the coding interview

#181

Post by ori_b »

enraged_camel wrote: post #119
richforrester wrote: post #104

Earlier quoted context omitted.

Thank you, this was almost exactly what I was going to respond with. My only addition: "Alternatively, we can write/review some code on a whiteboard."

It's well documented that whiteboard exercises are terrible for evaluating candidates. A lot of people, developers especially, don't perform well under pressure (stress reduces cognitive ability). Not only that, but you will also alienate a great many experienced candidates. If you are OK with all that, fine I guess. But I thought it was widely agreed upon that the software industry needs better hiring practices.

> A lot of people, developers especially, don't perform well under pressure (stress reduces cognitive ability).

A lot of places value people who work well under pressure. (A bad push taking down all the server's I'd stressful)

Re: How to win the coding interview

#182

Post by ori_b »

kayman wrote: post #36

I'm tired of companies asking me to code at their interviews. I have 10 years experience with references. I have code that I've built, deployed to production still running today. I have cultivated my own clients, gathered requirements and built something that delivers business value. Instead of a coding interview, I'll make a counter offer. Why not hire me on a 1 week contract to come and do some real world work. Wor…

I have better things to do than spend a few months of PTO interviewing with multiple companies. This won't fly with me, and I doubt it will fly with many people that are currently employed.

Re: How to win the coding interview

#183

Post by agentultra »

What if I we start by writing an unambiguous specification and I walk you through the proof?

The pomposity of this post is ridiculous. I can't stand the, "I don't have time for you," type of thinking. It suggests that the author assumes they are smarter than the person they are interviewing. It elides the underlying complexities of every persons' lived experience and inner world. Does the author not realize that people are not dumb actors in their narrative? People are generally intelligent, creative, and highly adaptable.

All this post does is show how trivial some people treat the interview process. The real lesson here is that if you can learn to ask how high to jump when ordered to you can get anywhere.

Re: How to win the coding interview

#184

Post by p4wnc6 »

garrettgrimsley wrote: post #74
p4wnc6 wrote: post #54

Earlier quoted context omitted.

Regexes would not be a good way. Starting a pointer at the beginning and end and moving them toward each other is what I would suggest in an interview. If I was interviewing someone else, I'd also be impressed if they came up with the idea of sorting the string and counting characters (only at most one character could have at odd number of occurrences). Even though sorting and counting is nlogn and requires either st…

>I'd also be impressed if they came up with the idea of sorting the string and counting characters While that method would identify if a string has the necessary attributes of a palindromic string it is not sufficient to prove that a string is a palindrome. >This is the person judging the candidates on whether they are talented enough at computer science? Yikes. Right, anyone reading the OP would probably be better s…

You're totally right. I was confusing the stated problem with a common associated problem: whether a string is a permutation of a palindrome.

Re: How to win the coding interview

#185

Post by p4wnc6 »

jaredsohn wrote: post #68
p4wnc6 wrote: post #54

Earlier quoted context omitted.

Regexes would not be a good way. Starting a pointer at the beginning and end and moving them toward each other is what I would suggest in an interview. If I was interviewing someone else, I'd also be impressed if they came up with the idea of sorting the string and counting characters (only at most one character could have at odd number of occurrences). Even though sorting and counting is nlogn and requires either st…

If you use a bucket sort, your time complexity could be O(max(n,k)) and space O(k) where k is the size of the character set and n is the length of the string. Depending on the relationship between n and k, this could be faster than n log n. (But the pointers solution or even comparing against a reversed string seems better for both time and space.) Also, your solution is poor since it only tells you that a string is…

I assume the 'poor' solution you meant was the sort and count solution. You're totally right. I was confusing the stated problem with a common associated problem: whether a string is a permutation of a palindrome.

Re: How to win the coding interview

#186

Post by [deleted] »

sundvor wrote: post #4

Very interesting article, thanks for writing! I have but one, eh, comment: > Your code should be commented Sure.. but: > * @param {string} stringToTest - the string to test. > // make sure we have a string. > if (typeof stringToTest !== "string") { > > function isPalindrome(stringToTest) { > ... > // if we get here, it's a palindrome > return true; Do we really need to explain that stringToTest means string to test?…

[deleted]

Re: How to win the coding interview

#187

Post by bithub »

sekasi wrote: post #89

Solving that code test in a more effective manner? :) replace non alpha/spaces, lowercase it, then compare value.reverse() == value

Shorter yes, but reversing the whole string and comparing it with the input value is actually slower/less efficent than the algorithm shown in the article. Sorry for my nitpicking ;)

Re: How to win the coding interview

#188

Post by vkjv »

BinaryIdiot wrote: post #130
hvidgaard wrote: post #102

Earlier quoted context omitted.

I've had students that did this. It's a real pain to read code like that, and the 2nd time they handed it in, it was an automatic fail. Comments explain assumptions, and often "the why", never "the what" unless it's obscure because of optimizations.

> It's a real pain to read code like that, and the 2nd time they handed it in, it was an automatic fail That seems incredibly heavy handed and not helpful in the learning process. I was a professor's aid for several programming courses and many students simply made comments like that constantly because it helped them drill it into their head what it did. It's a little annoying but it doesn't hurt the readability. Aut…

While I might not agree with the GP that this should be an automatic failure, I do think it is very important to emphasize to students that when the code is working, they are not done. They still need to go back, re-format, clean things up, and possibly add tests.

Working is the lowest bar of quality.

Re: How to win the coding interview

#189

Post by crispyambulance »

BinaryIdiot wrote: post #130
hvidgaard wrote: post #102

Earlier quoted context omitted.

I've had students that did this. It's a real pain to read code like that, and the 2nd time they handed it in, it was an automatic fail. Comments explain assumptions, and often "the why", never "the what" unless it's obscure because of optimizations.

> It's a real pain to read code like that, and the 2nd time they handed it in, it was an automatic fail That seems incredibly heavy handed and not helpful in the learning process. I was a professor's aid for several programming courses and many students simply made comments like that constantly because it helped them drill it into their head what it did. It's a little annoying but it doesn't hurt the readability. Aut…

I think folks are getting hung up on nitpicking the comments. I never heard of anyone getting rejected strictly because of a stray unnecessary comment in a code test for hiring.

Any interviewee is going to make assumptions about what the interviewer wants. Some of these assumptions will be wrong and some will not be worth the time to ask about (like commenting style). If the interviewee solved the problem and/or displayed a desirable level of competence that's good enough. Interviewers do the coding exercise merely to screen out people that have grossly misrepresented their skills.

On the internet folks like to imagine they're in a position to "immediately reject" a job applicant because of a single "red-flag" that indicates some profound shortcoming. This is rarely the case.

Re: How to win the coding interview

#190

Post by jameshart »

verroq wrote: post #60
scishop wrote: post #18

On the flip side of things, I might prefer to see a candidate come up with something like this as first stab rather than that 35-line mammoth of an isPalindrome() function in the article. function isPalindrome(str) { return (str.split("").reverse()).join("") == str; }

I'd expect to see this (assuming that this guy is a Javascript shop). function isPalindrome(str) { for (let i = 0; i Quick check list: 1. Knows about es6 2. Knows about === and !== 3. O(n) efficiency with no memory bloat 4. Didn't write 30+ lines on a trivial function I won't even add a comment about unicode since it should be your default assumption when working with javascript that multi-byte characters and surroga…

5. Didn't meet the specification.

You need to ignore white space and punctuation.

6. Didn't include any tests

7. Bonus! This function also returns true if you pass it a palindromic array! Er... Maybe it shouldn't do that.

Post reply on HN