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

How to Crack the Toughest Coding Interviews

gklst.tumblr.com

Post reply on HN
Print view View original

121–130 of 144 posts

Re: How to Crack the Toughest Coding Interviews

#121

Post by pacaro »

seiko55 wrote: post #106
pacaro wrote: post #16

Earlier quoted context omitted.

I've interviewed a lot of people (at Microsoft). I don't claim to be good at it, I think that I do OK, but that's why one interviewers opinion should never be the be all. I've definitely encountered people who were clearly good, and equally clearly sucked at interviewing, as an interviewer I had to ask myself the question "why?" I encountered the following cases (among others)... The ill-prepared - This may come down…

ok, one question: certainly you guys are great coders to be in working in these companies, but is every single person there for sure going to give the best possible answer to these questions every single time if asked? Thanks

In a word: No.

Internal interviews can be a real eye-opener.

Re: How to Crack the Toughest Coding Interviews

#122

Post by jsolson »

pjscott wrote: post #108
Someone wrote: post #72

Earlier quoted context omitted.

"I vaguely recall counting lattice paths in 3-space being a wickedly hard problem with no known polynomial time solution." I think you can easily write the recursion: p(x,y,z) = p(x-1,y,z) + p(x,y-1,z) + p(x,y,z-1) Leave out the term with x-1, y-1, or z-1 for the edge cases for x, y, and/or z equal to zero. With that in hand, it is easy to compute all values bottom up, starting with those where x+y+z = 0, 1, 2, etc.…

You're assuming that all movement must be in one of three directions, but in general, you can go in six directions -- forward or backward along the x, y, and z axes. Your cubic-time DP algorithm doesn't solve the self-avoiding walk problem, which I think is what jsolson vagely recalls. http://en.wikipedia.org/wiki/Self-avoiding_walk

So, the professor in question was Dana Randall. I believe she was talking about this topic: http://en.scientificcommons.org/42983059

Basically, yes, self-avoiding paths.

This was basically a brief aside in her honors undergrad algorithms course, so the topic was a bit beyond what I was prepared for at the time :)

Re: How to Crack the Toughest Coding Interviews

#123

Post by what_ever »

theorique wrote: post #26
pacaro wrote: post #16

Earlier quoted context omitted.

I've interviewed a lot of people (at Microsoft). I don't claim to be good at it, I think that I do OK, but that's why one interviewers opinion should never be the be all. I've definitely encountered people who were clearly good, and equally clearly sucked at interviewing, as an interviewer I had to ask myself the question "why?" I encountered the following cases (among others)... The ill-prepared - This may come down…

In more recent interviews, companies I've worked at have had the candidate sit at a laptop and essentially pair program with the interviewer. This avoids avoid that artificial write code as fast as you can with a whiteboard marker situation. Granted, it's not their regular dev setup and it's probably an unfamiliar keyboard and trackpad, but it seems to be better than the alternative.

I interviewed with one of the company where the first two screening round consisted of pair programming (in person, on university campus) on my own laptop. I think that was the best way to conduct interviews. Much better than the phone screens.

Re: How to Crack the Toughest Coding Interviews

#124

Post by lcargill99 »

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…

Sounds like the process worked. interviewing is pretty much a lost art. So it goes.

Re: How to Crack the Toughest Coding Interviews

#125

Post by Evbn »

danielweber wrote: post #67
dabent wrote: post #6

A few other links for those wishing to get familiar with the process: From Google: http://www.google.com/about/jobs/lifeatgoogle/hiringprocess/ From MIT: http://courses.csail.mit.edu/iap/interview/materials.php Steve Yegge's well-known advice: http://steve-yegge.blogspot.com/2008/03/get-that-job-at-goog... Essentially it seems to build down to knowledge of data structures and the ability to use them in concert to dev…

> Steve Yegge's well-known advice: He says: Don't say "choo choo choo" when you're "thinking". God damn it. Now I'm going to have to fight the urge to do that during interviews!

It is the only socially acceptable bigotry. Something JS to be the scapegoat....

Re: How to Crack the Toughest Coding Interviews

#126

Post by Evbn »

dspeyer wrote: post #115
softbuilder wrote: post #61

Earlier quoted context omitted.

>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.

There aren't enough problem in the world for that to be possible, ignoring extremely superficial differences.

It always comes down to exercises from CLR lightly dressed up.

Re: How to Crack the Toughest Coding Interviews

#127

Post by Evbn »

robocop wrote: post #99
mrexroad wrote: post #48

Earlier quoted context omitted.

whiteboarding perfect syntax, delving into absurd language minutia and "gotchas", f'ing around w/ brain teasers while an interviewer introduces behavioral stressors (sighs, ticks, etc.) to see how i problem solve "under pressure" ...is all bullshit. so yeah, ask me to program. i mean, srsly program. let's hack together for an afternoon; hell, let's do a full day of paired programming to knock out a small bug in your…

I don't think this approach would scale, due to the time investment required. It also suffers from making it hard to compare one candidate to another in a fair way, unless you have everyone fix the same bugs. Having a bunch of canned bugs to be fixed doesn't seem much better than asking a CS puzzle.

I Lways ask people to slave a simplified version of an actual problem I have worked on recently. Some times I even learn some thing.

Comparing candidates is irrelevant. You just want N hires that can contribute in your environment.

Re: How to Crack the Toughest Coding Interviews

#128

Post by Evbn »

famousactress wrote: post #79
Zenst wrote: post #5

Interviews work both ways - what questions do you ask them? One I used to ask was do you have IS9002/BS5750, but that was 15 years ago and there are better questions to ask. A good question is also sometimes better than a good answear as it shows you understand things from another perspective and have the ability to ask questions instead of blindly accepting what you are told all the time if your unsure. So what are…

I ask some questions about test coverage, coding standards, code reviews.. I'm sometimes more interested in whether I get the same answers from different people or not than the particulars. I always ask for an example of a technical or tools decision that was made. I'm usually looking to see whether decision-making is well distributed or things get bottlenecked by a manage or lead. Probably most of all I pick at how…

What company do you like that has no sales team?

And did you miss a negative in your last question?

Re: How to Crack the Toughest Coding Interviews

#129

Post by Evbn »

Swizec wrote: post #9
Zenst wrote: post #5

Interviews work both ways - what questions do you ask them? One I used to ask was do you have IS9002/BS5750, but that was 15 years ago and there are better questions to ask. A good question is also sometimes better than a good answear as it shows you understand things from another perspective and have the ability to ask questions instead of blindly accepting what you are told all the time if your unsure. So what are…

In order: Do you use git? How do you do ticketing? What's it like working here? In my experience engineers at big companies will not give you an answer to those, but canned marketing responses. I don't know why.

Git chauvinism is ridiculous. Git is great for bazaar style open source. It isn't important for small teams or large coordinated teams.

Every big company uses Remedy. Some just dress it up a little.

Re: How to Crack the Toughest Coding Interviews

#130

Post by codex »

nandemo wrote: post #46
drivebyacct2 wrote: post #33

Earlier quoted context omitted.

>And if you cannot come up with an optimal algorithm for a given problem, all of the items mentioned in the article (communication, clear coding, testing) don't really matter. That's just not true and if any company is only interested in whether or not I can generate a correct answer under pressure in 20 minutes, then I'm not interested in working for you.

You seem to be disagreeing with something I haven't said. I'm simply describing my experience interviewing at Google: I didn't give an optimal solution to a couple of problems, and didn't get an offer. So I infer that the other items mentioned in the article don't matter as much for getting a job at Google .

It's not uncommon for interviewers to ask a few warm up/intro questions and then proceed to more advanced questions--so if you didn't get a few questions right, you may simply have missed some easy ones, so they didn't ask you the hard ones. This would leave you the impression that you "almost" made it, when in fact you may not have come close.
Post reply on HN