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

How to get hired (or, 'The silly story of interviewing in the valley')

trapm.com

Post reply on HN
Print view View original

161–170 of 178 posts

Re: How to get hired (or, 'The silly story of interviewing in the valley')

#161

Post by eru »

gordonguthrie wrote: post #138
kamaal wrote: post #124

Earlier quoted context omitted.

The definition of gaming the system is different here. These days unless you are implementing a library yourself. You are probably never ever going to even reverse a linked list ever in your life. Or deal sit down with a math text book when you code. Those days are probably gone in the 80's. That means asking these questions is akin to you taking an approach to judge an candidate on things which have nothing to do hi…

As I read the article and the comments I thought "how would I reverse a linked list?" Turns out it is pretty straight-forward in Erlang: lists:reverse(List). Reading their contributions on github is a much better way to get a sense of someones capabilities.

You could just ask: How is lists:reverse(List) implemented in Erlang, or if you don't know it, how could it be implemented? What are the trade-off and limitations for different implementations?

Since most abstractions are leaky, you can make a good argument, that learning how libraries tick, even if you are never going to rewrite them, is a useful skill.

Re: How to get hired (or, 'The silly story of interviewing in the valley')

#162

Post by eru »

gordonguthrie wrote: post #139
AdamTReineke wrote: post #128

Earlier quoted context omitted.

Would the optimal solution be O(n*log(m)), where n is the number of IP addresses in list one and m is the number of IP addresses in list 2?

If it is a long list then the O of the algorithm matters a lot. If its a short list, who cares? If you care about it all the time then you a premature optimiser - basically a hand-grenade with the pin out. (by you I mean 'one' here - not you AdamT)

If you are implementing, than you are right. If you are interested in studying algorithms and how they work, asymptotic considerations can tell you a lot about the algorithm. You have to decide what you want to ask for in your interview.

Re: How to get hired (or, 'The silly story of interviewing in the valley')

#163

Post by eru »

thejteam wrote: post #105
lancewiggs wrote: post #96

Earlier quoted context omitted.

I've done the same - keeping on pushing until the candidate is on uncertain ground. (I interview for consulting/ analytic /business/ senior management roles.) As most of a job is about doing things that haven't been done before, getting the candidate into unknown territory is when you really find out how effective they will be. Some people just stop, others switch seamlessly into problem solving mode and come up with…

One of my favorite interviews was like this. The interviewer started by asking me some of the basic logic problems. I had heard most of these many years before. He actually appreciated it when I stopped him mid-question and finished the question for him. He asked another one, I finished the question for him. He saw that I had a math degree and asked about a particular problem involving infinity that he had heard abou…

That's why I always asked for dress code before the interview. You may feel slightly stupid when you ask, but you'll be dressed right when you come to the interview.

Re: How to get hired (or, 'The silly story of interviewing in the valley')

#164

Post by tptacek »

adam-a wrote: post #155
tptacek wrote: post #153

Earlier quoted context omitted.

"We" didn't know that already; there was an implicit argument that there might ever be a point to building a linked list in Ruby, which, no. Like I said, we're way off the rails here.

I probably shouldn't have replied and dragged it out, and I apologise for my tone but you seem to be almost wilfully missing the point. There are problems where a linked list is theoretically better suited than an array. Your test is a problem where they are theoretically evenly matched. The interesting question is: do the benefits of native code etc, that you get when using an array outweigh the costs that you incur…

I think we're not communicating well because we're deep in a tangential subthread.

I take your point that repeated insertion at a specific held reference to the middle of a list is faster than insertion into the middle of an array.

I'm just saying that in Ruby, where every list node incurs object overhead and where list iteration is done by tree walking and array referencing is done by pointer dereferencing in the background, lists underperform arrays even in cases where you'd expect the algorithmic complexity of a list to yield a big win.

Re: How to get hired (or, 'The silly story of interviewing in the valley')

#165

Post by tedunangst »

carlio wrote: post #147
gaelian wrote: post #132

Earlier quoted context omitted.

I was talking to a friend of mine about just this issue recently. He and I have been on both sides of the interview table at different times. I have gotten interviewees to solve toy programming problems and I've asked them the funny little logic problems, just as I have been asked the same sort of things in the past. But eventually I too came to the realisation that these kinds of things had little if any real signif…

I'm constantly surprised when I read articles like this one, or when I take interviews myself, that noone considers how the employee deals with a "project as a whole". Toy logic problems or algorithm optimisation tell you nothing about how good that person is at actually working as a software engineer. Do they care about code unit tests and code coverage? If they find a process missing - no continuous integration or…

Those are questions a manager should be asking, ie, outside the scope of the interview I'm conducting. They're also the easiest to fake. Everybody knows the answer is to say they write test cases for every change before they check it in. That's way easier to memorize than any coding puzzle solution.

I've had some frustrating experiences where the obviously talented candidate was nearly passed over because they didn't use the right software engineering buzzwords while at the same time the manager came close to overruling the technical veto because they felt some other idiot sounded like a good fit.

Teaching someone to write unit tests is, imo, far more likely to succeed than teaching someone to understand recursion.

Re: How to get hired (or, 'The silly story of interviewing in the valley')

#166

Post by rhizome »

gordonguthrie wrote: post #138
kamaal wrote: post #124

Earlier quoted context omitted.

The definition of gaming the system is different here. These days unless you are implementing a library yourself. You are probably never ever going to even reverse a linked list ever in your life. Or deal sit down with a math text book when you code. Those days are probably gone in the 80's. That means asking these questions is akin to you taking an approach to judge an candidate on things which have nothing to do hi…

As I read the article and the comments I thought "how would I reverse a linked list?" Turns out it is pretty straight-forward in Erlang: lists:reverse(List). Reading their contributions on github is a much better way to get a sense of someones capabilities.

My interview strategy as a Rails dev: reversed = File.open('list.txt').gsub(/[\n\r]/'').split.reverse

I don't need to write Ruby in C.

Re: How to get hired (or, 'The silly story of interviewing in the valley')

#167

Post by jarek »

jrockway wrote: post #135
jarek wrote: post #119

Earlier quoted context omitted.

What's your definition of "programming a computer"? Personally, I always have to wonder how often someone programs a computer if they don't know how a four-state branch predictor helps their CPU.

The key insight that relates to the analysis of merge sort is that solving problems with computers always goes better if you divide them in half a few times. This comes up again and again; binary trees, binary search, and all the n log n sorts. Branch prediction is a little different; it's an optimization engineered into modern processors. Splitting problems into two is a fundamental property of the Universe. Therefo…

I concede that your example is more applicable. Perhaps something relating to L1/L2/L3 caches and memory might have been more suitable as mine.

I'm still not fully onboard with your general claim though. Someone building the most brilliantly simple, computationally simple Android calendar/planning/todo application might not care about dividing in half when all they have to do is Collections.sort(). Someone building a CRUD web app might see their most significant performance issue in HTTP throughput or latency. You'll be wondering how often they program a computer.

Re: How to get hired (or, 'The silly story of interviewing in the valley')

#168

Post by russell »

shard wrote: post #136
russell wrote: post #27

I use a similar approach. I spent 20 years as a consultant, so I did a lot of interviews. I would send out lots of emails. I didnt do many tailored emails, but I did a carefully tailored cover letter designed to be amusing to the HR ladies. You have to get by them first. I figured the first few interviews were throw-aways, just to get my interviewing skills back up to speed and to find what this years interview quest…

What did you do in your cover letter to amuse the HR ladies? Please share.

Do you remember the Johnny Cash song "I've Been Everywhere... Chicago, Reno, Fargo"? Sometimes I think my resume reads like that.

After I added those lines, I got a 25-30% increase in responses.

Re: How to get hired (or, 'The silly story of interviewing in the valley')

#169

Post by eru »

steve8918 wrote: post #60
eru wrote: post #51

Earlier quoted context omitted.

You just have to make the problems so diverse (not necessarily hard), that genuinely understanding the solutions is the easier strategy than rote learning.

Can you give me an example of a question that isn't located in glassdoor.com and is "diverse but not hard". As far as I'm concerned, the bar is already ridiculously high to the point where I feel like the only people that get jobs are the ones who randomly get lucky enough to get 3 or 4 interviewees that ask easy questions. There are people I know personally that have gone through every single one of the 1000+ Google…

> Can you give me an example of a question that isn't located in glassdoor.com and is "diverse but not hard".

Sorry, `diverse' is an attribute of the distribution of questions you ask. Not of any single question. If for each interview you take a random question from glassdoor.com (and perhaps even tweak it a bit, if you feel like it), that might even meet the definition of a diverse but not too hard selection. (Unfortunately, I know almost nothing about glassdoor.com, and what kind of questions they have.)

Re: How to get hired (or, 'The silly story of interviewing in the valley')

#170

Post by spiffytech »

huhtenberg wrote: post #91
timr wrote: post #3

"Then, acting as though this was the first time I'd seen this problem, I would ask if it was ok if I thought aloud as I worked my way through the problem on the board. I'd mumble to myself about moving-this-piece-over-here and-now-we're-going-to-get-this, and lo-and-behold, I accidentally solved it in constant memory space, in C - a language I didn't even claim to be particularly good at! Only someone with amazing pr…

Going through the details is the way to estimate candidate's true knowledge of a subject. Ask an easy question, then ask a very hard one, repeat depending on answers, i.e. basically do a binary search: - Do you know what SSL/TLS is? general - What's the maximum size of SSL protocol record? specific - What's a cipher suite? general - How is DH-anon suite is set up? specific ... - What is a linked list? - What is offse…

I recently interviewed for a position with this sort of technical interview. I felt it worked very well. The interviewer was able to cover a wide range of topics in varying depth, and could see what I could easily recall and what I struggled with.

With the right set of questions, and some hints when the candidate struggles, you can very effectively gauge a candidate's limits on a subject, and see how they try to puzzle things out when they don't know an answer but know enough to take a good guess.

The key distinguishing factor of this method, IMO, is a candidate cannot memorize enough answers to bluff their way through a good questions list. If a candidate really is an N out of 10 with technology $FOO like they claim, they should have no problem answering most/all of your 50+ N/10-level questions for $FOO (my technical interview consisted of ~2 hours of this sort of interrogation for a straightforward junior web dev position. Interview length, in this interviewing style, is important for ensuring you've exhausted a candidate's book knowledge).

Post reply on HN