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

91–100 of 144 posts

Re: How to Crack the Toughest Coding Interviews

#91

Post by wting »

barbs wrote: post #68

Has anyone read the book put out by the blog post author? I thought the post was well written, and would like to know if the book is worth getting as well...

Her "Crack the Coding Interview" book basically is an expansion of that blog post, goes into more details, includes a lot of problem sets of different types and various strategies for attacking each one.

I like using it to study for interviews. It's not sufficient by itself, but will get you 75% of the way there.

*Disclaimer: I'm 3 degrees of separation away from the author. :p

Re: How to Crack the Toughest Coding Interviews

#92

Post by barbs »

wting wrote: post #91
barbs wrote: post #68

Has anyone read the book put out by the blog post author? I thought the post was well written, and would like to know if the book is worth getting as well...

Her "Crack the Coding Interview" book basically is an expansion of that blog post, goes into more details, includes a lot of problem sets of different types and various strategies for attacking each one. I like using it to study for interviews. It's not sufficient by itself, but will get you 75% of the way there. *Disclaimer: I'm 3 degrees of separation away from the author. :p

Sounds a like a good recommendation to me, thanks :). What would you recommend for the remaining 25% of the way?

Re: How to Crack the Toughest Coding Interviews

#93

Post by icelancer »

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…

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.

Re: How to Crack the Toughest Coding Interviews

#94

Post by icelancer »

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.

>How do you do ticketing?

Always a good one. I also like a variant on this if they profess to practice agile development:

>How do you implement the agile process?

More times than not, it's a waterfallesque implementation.

Re: How to Crack the Toughest Coding Interviews

#95

Post by icelancer »

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.

Alright. Let's assume we have this guy, we'll call him a... oh, I dunno, a salesperson. And there are all these cities he must visit to sell his wares. BUT, oh-ho, there's a catch! Let me tell you how many times he can visit each city...

Re: How to Crack the Toughest Coding Interviews

#97

Post by malyk »

mech4bg wrote: post #63
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…

As an interviewer, it always surprised me how little people would prepare for an interview. For every interview I have done as an interviewee I have studied what I am likely to be asked, what their interview technique is, boned up on the language(s) in question, and tried to think of some interesting questions to ask the interviewer (the last one also includes learning as much as I can about the company and its histo…

I've never studied for an interview. I guess I have some internal feeling that you should hire me based on what I know...not what I crammed for the night(s) before an interview.

Or maybe it's confidence? I don't know. I've been programming professionally for over 10 years. I think I should be able to sit down and work out almost any problem in an interview.

I've definitely been to interviews where I ran into issues and didn't get offers, but I've also been to interviews where I ran into problems and did get offers.

I guess, in my gut, I feel like studying for an interview is cheating a bit. It might not be the right outlook, but it's something I can't shake.

Re: How to Crack the Toughest Coding Interviews

#98

Post by blaines »

I've been doing lots of interviews lately. Most of the coding questions have been fun, and I've learned. Some have been just plain strange - they seem like well intended questions in a specific context (which I'm not aware of). Those are the hardest.

I've noticed the strange ones seem to be coming from people that aren't prepared to be interviewing. So just a word of advice (and I'll elaborate with a blog post soon) to interviewers, please prepare ahead of time. I'm interviewing you too.

Asking the most abstract or complicated question possible probably won't help you find the people you're looking for.

Re: How to Crack the Toughest Coding Interviews

#99

Post by robocop »

mrexroad wrote: post #48
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)?

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.

Re: How to Crack the Toughest Coding Interviews

#100

Post by mirkules »

hkmurakami wrote: post #47
kami8845 wrote: post #22

Earlier quoted context omitted.

You have to be more sneaky. Rather than asking something as generic as >What's it like working here? ask them >What do you like the most about working here? If they give you something like "the stability" or "the high pay" those are generally bad signs. Better signs would for example be "the great people I get to work with every day" or "the autonomy to get to choose what I work on".

You can probably throw the "If you could change one thing about the company, what would it be" type question as well.

That's a nice play on the "What are you biggest strengths and weaknesses" interview question, in reverse. The only problem with that -- as we've been conditioned over the years of being asked this stupid question -- is to list a strength as a weakness (http://jobsearch.about.com/od/interviewquestionsanswers/qt/w...) so you don't actually get much meaningful information (other than maybe subtle red flags, like "stability" or "benefits are good", as someone mentioned).
Post reply on HN