5 ms·
I recently had an interview at google which I did not pass. The problem I did the worst on was finding the median of two sorted arrays. If I had 5 minutes with
by johnswamps 16y ago
I recently had an interview at google which I did not pass. The problem I did the worst on was finding the median of two sorted arrays. If I had 5 minutes with my favorite editor and an easy way to run unit tests, I could have easily written a correct version of the algorithm. It's not a hard problem, and a lot easier than many of the algorithms I write every week.
Instead, I spent a long time erasing what I had written, running out of room on the edge of the board, staring at the board, thinking about off by one errors, etc. Just looking at code on a computer screen is a lot easier. You're used to seeing code in a nice monotype font with syntax coloring, not some scribbles on a board. And if the interviewer had just left the room for 10 minutes and let me write it on the board by myself I think I would have done a lot better.
- AngryParsley 16y agoIf I had 5 minutes with my favorite editor and an easy way to run unit tests, I could have easily written a correct version of the algorithm. If you did have your preferred development environment in front of you, your interview questions would likely be harder. I see two possible solutions to this problem: 1. Interviewers: Change the interview process so that candidates are expected bring their own computers to write code on. Increase the difficulty of the questions. 2. Candidates: Practice interviewing, including writing code on a whiteboard. Have a friend pretend to be the interviewer. BTW if you ever interview at Google again, I suggest reading http://steve-yegge.blogspot.com/2008/03/get-that-job-at-google.html http://steve-yegge.blogspot.com/2008/03/get-that-job-at-goog... . It definitely helped me. Actually, I suggest reading that before you interview anywhere.
- barrkel 16y agoThe nice thing about harder questions is that you can be sure that flakes are more likely to fail at them. Bring on the hard questions, I say, so long as they are not "trick"-based.
- AngryParsley 16y agoInterviewers would have to spend a lot more time thinking up questions, so the cost-benefit analysis heavily discourages that. There's also the status-quo bias to deal with. I don't understand why people don't practice interviewing. It's worth your time to spend a few hours practicing something that could determine your future for years. Employers will change their interview process some day, but until then, if you want a good job you sometimes have to jump through stupid hoops. Of course, I'd like interviewers to practice as well. When I interview someone, I want to get some idea of the candidate's skills. I seriously doubt my hastily-thought-up questions are anywhere close to optimal at achieving that goal.
- stretchwithme 16y agousually, they've got tough problems they need solved, so thinking up tough questions isn't really necessary send your best people to startup weekend and similar events. It should take only a few hours to identify the top people and establish a rapport that may lead to a successful hire.
- blizkreeg 16y agoI completely agree. I once asked an interviewer to leave the room and come back in 5 mins. Another time I asked him to just continue doing his work while I work away at the code. Both times I produced near perfect code. On other occasions, the result was somewhat disappointing. I think (may be because it applies to me) an interview is not quite an accurate predictor of performance on the job. I for one, have no interest in remembering arcane sorting algorithms or how to implement a red black tree. Yes, I've done it in school and when I need them, it usually only takes an hour tops to figure it out and write at least the skeleton code for them. I consider myself a good s/w engineer, perhaps not great, but good. I personally know people at Google (friends from college, more than a few) who were average at best in college or grad school. But they seem to do well in interviews (much of it I attribute to preparing well) and hence are now Googlers. I know I suck at interviews but have performed very well in my job working on distributed systems software. I think the worst part I hate about interviews is some guy sitting there judging my capability. Perhaps, that is why I need to be my own boss (I'm usually very harsh on myself) =)
- Keyframe 16y agoCan you write code on paper? Pseudocode or something resembling it. When I was a kid it was a bit of a luxury to own any kind of computer and I wanted one so bad that I basically learned programming (in C) from books and wrote my code on a piece of paper all the time so that once I get access to computer or parents buy me my own I would already be "prepared". As it turned out this helped me along the way to clearly present ideas to others on whiteboard or paper (code, that is). However there is still that bit of "experimentation" with code even on paper. Heck, I don't know anyone that can write code perfect from one go, you have to dance around an idea a bit first before you get what feels right to you. tl;dr; Paper/Whiteboard is just a different IDE you have to get used to.
- jimfl 16y ago"I will be happy to do this, once you produce a whiteboard which allows me to insert a line between two others."
- jemfinch 16y agoI recently had an interview at google which I did not pass. The problem I did the worst on was finding the median of two sorted arrays. If I had 5 minutes with my favorite editor and an easy way to run unit tests, I could have easily written a correct version of the algorithm. For decades ordinary computer scientists wrote algorithms on pen and paper, translated them to punch cards or switches, and ran them on computers with no screens. Is it really so inconceivable that a company might expect you to understand and write code on a whiteboard?