How to Crack the Toughest Coding Interviews • Hacker News Board

Re: How to Crack the Toughest Coding Interviews

#111

Post by monksy » Sat, Oct 27, 2012, 2:00 AM UTC

tjdetwiler wrote: post #90

stcredzero wrote: post #37

I think I've been a victim of ageism here in the SF bay area. One member of a group met me in person, and we had a positive experience during the coding interview. (I look young for my age.) I gave him some Python code that solved his problem, as well as a version optimized for common prefixes and another that gave the same tally by user as well as the total aggregate. Note I am not primarily a Python coder, and it's…

I've been in interviews where I felt like the interviewer went a little power-hungry with the situation. For example: Interviewer: "How you implement this calculator program?" Me: "Well I would try to read a number...." Interviewer: "HA! You cannot assume the type of input" Me "Okay, fair enough... does the input reflect a valid math expression?" Interviewer: "Of course, why would you ask such a question." In the mom…

I've been on interviews like that. Its a double edged sword. if you assume the worst about the input in the first place you're screwed. If you don't they'll bring it up later.

Re: How to Crack the Toughest Coding Interviews

#112

Post by abecedarius » Sat, Oct 27, 2012, 2:08 AM UTC

JoshTriplett wrote: post #54

abecedarius wrote: post #27

Earlier quoted context omitted.

Hm? Hashing is O(N) unless it's oblivious to some bits. Though the prefix tree part is optional, yes. :-) Better luck next time. (For some reason programmers really love tries / prefix trees when answering on stackoverflow and such. I'd like to understand why -- tries are neat, but you don't see them nearly as much in actual use.)

> Hashing is O(N) unless it's oblivious to some bits. O(N) only makes sense when you agree on what N means. When using big-O notation, always make sure you agree on the base N values you want to work with. In this case, it sounds like you interpreted N as the number of bits to hash, in which case yes, any sensible hash algorithm has to look at all the bits so it'll use an O(N) algorithm. However, the post you replied…

The post I replied to said N is the length of the key.

Re: How to Crack the Toughest Coding Interviews

#113

Post by dbecker » Sat, Oct 27, 2012, 2:16 AM UTC

stcredzero wrote: post #37

I think I've been a victim of ageism here in the SF bay area. One member of a group met me in person, and we had a positive experience during the coding interview. (I look young for my age.) I gave him some Python code that solved his problem, as well as a version optimized for common prefixes and another that gave the same tally by user as well as the total aggregate. Note I am not primarily a Python coder, and it's…

You say you are a victim of ageism, but I don't see much in this story to support that conclusion. The interviewer apparently thought you were cheating... or at the very least he was incompetent to recognize the quality of your code. But those are totally different from discriminating against you because of your age.

Re: How to Crack the Toughest Coding Interviews

#114

Post by Jach » Sat, Oct 27, 2012, 2:20 AM UTC

maeon3 wrote: post #109

Jach wrote: post #36

Earlier quoted context omitted.

Here's a list of 100 questions applicants should consider asking a subset of during the interview: http://www.basilv.com/psd/blog/2009/100-interview-questions-...

Joel test is far more revealing: http://www.joelonsoftware.com/articles/fog0000000043.html

The 100 questions article does mention Joel's test. I think the Joel test is mostly obsolete (it is 12 years old after all), but the obsolete parts of it can usually be fixed with either a more precise or more fuzzy question that the 100 questions may offer you so you don't need to come up with it on your own. e.g. on hallway usability tests, I think you learn more from a general "do you test the UI for usability?" which may indicate hallway tests, A/B testing, alpha or beta users, or even a response of "No, we know what works and the user will love it (and bend to our will if they don't) and companies that imitate us will get sued".

Re: How to Crack the Toughest Coding Interviews

#115

Post by dspeyer » Sat, Oct 27, 2012, 2:24 AM UTC

softbuilder wrote: post #61

glaak wrote: post #21

Earlier quoted context omitted.

Consultants are asked case studies. Writers are asked to write something (or submit writing samples). Actors are asked to audition. And programmers are asked to program. Why shouldn't you validate if a programmer is, in fact, a good programmer (which is a mix of many things, including intelligence)?

>And programmers are asked to program Programmers are almost never asked to program. They are asked to solve 50-year old CS problems on a whiteboard.

At Google, at least, we try to make up new questions frequently and retire old ones.

Re: How to Crack the Toughest Coding Interviews

#116

Post by krickle » Sat, Oct 27, 2012, 2:32 AM UTC

stcredzero wrote: post #37

I think I've been a victim of ageism here in the SF bay area. One member of a group met me in person, and we had a positive experience during the coding interview. (I look young for my age.) I gave him some Python code that solved his problem, as well as a version optimized for common prefixes and another that gave the same tally by user as well as the total aggregate. Note I am not primarily a Python coder, and it's…

It sounds like you had interviews from irritating doofuses that thought they were brilliant. I don't know if it was ageism, but it sounds like could have been that you weren't doing things exactly as they were so they were unable to recognize your talent. (And they were to arrogant to look at it from another viewpoint.)

Re: How to Crack the Toughest Coding Interviews

#117

Post by icelancer » Sat, Oct 27, 2012, 2:46 AM UTC

famousactress wrote: post #110

icelancer wrote: post #93

Earlier quoted context omitted.

I don't agree with: >Do you have a sales team? If customers need to call in and speak to engineers or other non-business people to negotiate sales, that sucks. Having inbound sales people is a vital part of any good mid-sized company.

If you need humans to sell things, then of course I agree that you ought to have a sales team. I would just rather work somewhere that doesn't need humans to sell things. The problem I have with sales is that they're often very good at what they do. Once you have sales, you have two products. Your sales folks, and the thing people think they're paying you for. It gets hard to know which one is failing, or worse.. suc…

At some point if your company is any good, you WILL need humans to sell things. People will want to call in for more information, and the job of the person taking that informational call is to convert them. Unless you're Google where you don't give a hoot.

Not everyone is secure with a "F you, sign up online or else" policy. Good salespeople with domain expertise can be exceedingly helpful at introducing direction to the company - not just automatons who sell things.

Re: How to Crack the Toughest Coding Interviews

#118

Post by pjscott » Sat, Oct 27, 2012, 2:51 AM UTC

wting wrote: post #85

I'm kind of surprised at some of the negative comments people have towards these styles of interviews. I'm a current student still going through the interview process with Seattle / SV / Austin companies (big and small). Every interview is the same: - review resume - 0-2 behavioral questions - 1-3 technical questions covering design, data structures, algorithms, sometimes language specific (usually pointers) Here are…

> 1. How would you detect the largest sub array (i.e. max sum of adjacent numbers) given an example array:

That's a fun one. The obvious solution is O(n^2), but there's a less obvious way to do it in O(n). (I'm not giving spoilers, because this actually is fun to solve.)

Re: How to Crack the Toughest Coding Interviews

#119

Post by pjscott » Sat, Oct 27, 2012, 3:01 AM UTC

account_taken wrote: post #70

Man, I wouldn't do well in these interviews except for the tinyurl.com question. Who thinks at the level of binary tree implementations? I know what they are and how to use them and I had to could remember and implement one, but I don't remember having ever needed to implement one from scratch. The interview questions I ask are more around problem solving and thinking out of the box but I deal at the web application…

The binary tree thing is simpler than it sounds; don't be faked out by the fact that it involves binary trees. You can traverse a binary tree from the root to any node, and record the nodes on that path. Do so for each of the two nodes, then compare the two sequences, looking for the first node that is common to both of them. You can do this in O(lg n) if the binary tree is balanced, or O(n) if it is not. And if this sounds complicated in words, just draw a picture and it'll suddenly look simpler.

Re: How to Crack the Toughest Coding Interviews

#120

Post by pjscott » Sat, Oct 27, 2012, 3:07 AM UTC

jsnk wrote: post #49

glaak wrote: post #21

Earlier quoted context omitted.

Consultants are asked case studies. Writers are asked to write something (or submit writing samples). Actors are asked to audition. And programmers are asked to program. Why shouldn't you validate if a programmer is, in fact, a good programmer (which is a mix of many things, including intelligence)?

I am not saying that programmers should not be validated. Interview questions that are like IQ tests that depend heavily on single spark of inspiration are poor validators of determining productive programmers.

Actually, how well people do on one of these questions seems to correlate strongly with how well they do on others, so saying that each question depends strongly on a single spark of inspiration is kind of misleading. Where do those sparks of inspiration come from? And why do some people seem to vary so much in their ability to conjure them up on demand?