Live data from Hacker News

My Favorite Engineering Interview Question

skife.org

41–50 of 131 posts

Re: My Favorite Engineering Interview Question

#41
post #37

I love to ask something that is simple to start with, and then build on it interactively with the candidate. One of my favorite questions is - Give me a normalized database structure that you'll implement if you were to build gmail - incorporate conversations, messages, multiple message participants and labels. Then, depending on the candidate, I build upon the question,and go into various optimizations possible, the…

This. A million times this. I do the same thing starting with a simple kernel, but keep growing it, throwing in monkey-wrenches, see how the candidate reasons and adapts.

Good candidates will start recognizing and acknowledging trade-offs, whereas bad candidates will settle on one clear path.

Good candidates will speak about the ideas they're trying to get across, whereas bad candidates will drop into talking about specific brands of technologies.

Re: My Favorite Engineering Interview Question

#42

Why have SSDs killed this question? Seems like you could tweak the amount of data on disk and/or the size of the values and/or the requests/second requirement and keep using it. Also, there are no 1TB SSDs available at this point, so you'd still have to assume spinning platters for this, no?

This may come as a shock, but you can put more than one SSD in a server :-P

I think that the parent thought that the system had to use a single SSD. The first time I read the question I thought that I had to use the hard drive that the data came on, and that it was all I was allowed to use. I didn't realize that the point was to design a system to simply serve the data that was given to us. After reading it, it becomes pretty clear that a simple raid5 with a few SSD's makes this problem moot.

Re: My Favorite Engineering Interview Question

#43
post #34

My favorite: "Write a script that will save you one minute of time every day" closely followed by "Draw a picture of your job/Facebook/the future /whatever"

A picture? Are you hiring artists? Seriously. What do you get out of that?

A picture is a useful abstraction of reality. It forces people to think about what they'll 'answer' before they do. Some people might draw a diagram, some might draw a story, who knows. It tells a lot about people and how they think.

For some people this may seem like a fun task and they'll get excited about it, some may not find it useful and argue about it and others (the ones you want to avoid) will frown upon it and say 'Fine. I'll do it anyway'.

Most of the people I've interviewed are well accomplished engineers, but that doesn't always mean I want to work with them.

Why do you think it is NOT useful to draw a picture?

Re: My Favorite Engineering Interview Question

#45

Why have SSDs killed this question? Seems like you could tweak the amount of data on disk and/or the size of the values and/or the requests/second requirement and keep using it. Also, there are no 1TB SSDs available at this point, so you'd still have to assume spinning platters for this, no?

Amazon seems to disagree with you.

http://www.amazon.com/OCZ-Express-Solid-Z-DRIVE-OCZSSDPCIE-Z...

Re: My Favorite Engineering Interview Question

#46
These types of questions are terrible interviewing techniques. An interviewer who, even jokingly, goes into the room with an interrogative mindset is fundamentally failing at the core purpose of interviewing: finding good talent, preferably relatively undervalued talent. An interviewer should not be looking for someone who mirrors their way of thinking or or their approach to solving a problem. They should be looking for people with skills that complement the team, not duplicate it. Questions like these are typically signs of bad interviewing technique, but not always depending on how they are presented.

More often than not, however, people "design" interview questions to cause problems for prospective employees. You might think this is clever. You might think this helps weed out people who don't possess the ability to think quickly or react to feedback on their feet. All you really are doing is artificially limiting the prospective candidate pool.

Every dork with a chip on their shoulder can manufacture an a question to be unanswerable. Deep down inside what most of these bad interviewers really want is to design a question that creates one of two atmospheres in the interview room: (a) a submissive one, where the candidate is forced to placate the interviewer and reinforce their apparent intellectual superiority; or, (b) a confrontational one where the candidate and interviewer battle it out for dominance as alpha-geek. Either (a) or (b) can be seen as a positive depending on the type of interviewer that goes in. Ultimately, any interviewer that uses this technique is a bad one and any input they make into the hiring process should be seriously discounted.

The interviewer should adapt their interview style to the candidate based on reading their body language, communication skills, and overall demeanor in the interview room. Its the interviewer's responsibility to create the best interview experience possible. Some people are nervous; some don't think on their feet well; most rely on Google heavily to point them in the right direction; lots of them know more than they can demonstrate in the 5 minutes you give them to react to your stupid question.

Your job is find diamonds in the rough. People who are the best, not people who act, think, behave, or answer the way you think they should. Questions like the one in this blog post are tell-tale signs of alpha-geek interview dominance gone wild, and out of that you'll typically only get one style of candidate that makes it through the gauntlet, certainly guaranteeing you're not getting the best talent available.

Re: My Favorite Engineering Interview Question

#47

Earlier quoted context omitted.

Asking relevant questions at an interview is a good idea, but I've noticed that a lot of technical interviewers ask questions it took them weeks to understand and fix when they use this approach. Understanding a problem is often more difficult than solving it ... knowing that the interviewer understands the problem and constraints is even more of a challenge. I once had an interviewer give me the kobayashi maru witho…

Can you describe your kobayashi maru question? I'm curious.

Remember the "unwinnable" test in the recent Start Trek movie that kirk wins by cheating?

Re: My Favorite Engineering Interview Question

#48
post #20
post #7

I'm interested in why he's so against the "custom solution". Almost everything a DB will try and add in for key-value lookup is predicated on the idea that the requests aren't randomly distributed. The DB index will probably be based around b-trees, which will do a logarithmic-time search for the top few levels cached in RAM, but will fall over fairly miserably with multiple seeks as it has to page in leaf nodes and…

I have gotten solutions which implement custom stores which I have had faith that the candidate could build, but not many. I am not dead set against it, but I will press for an estimate and a good explanation of it if they want to go down that route. I try to emphasize that I want to know what they would actually do, on the job. Other questions (typically other interviewers) will explore algorithmic stuff, and folks…

How often do you decide exactly what you're going to do to solve a problem for your job in the span of one hour? Oh yeah, and make sure you provide an estimate and a good explanation, within that hour, as to why you've made that decision. Give me a break man, you're looking for people who tell you what you want to hear because then you've found someone who thinks like you--and that, in your mind, is the only correct answer.

Re: My Favorite Engineering Interview Question

#50
Easily solved with SSDs. Sort the keys, value is stored right after the key.

On each request do a binary search. It takes 32 seeks in the worst case.

Even current consumer level SSDs can handle 45K IOPS, so you'd get 1400 complete searches/sec from one SSD.

You might need to spread your data over 4 SSDs, but you can search in parallel, so it will even be faster.

If you want more speed, replicate your drives and load balance.

There are better ways (with perfect hash functions), but this is the easiest, and requires no additional storage.

Post reply on HN