101–110 of 225 posts
Twitter interview went sideways, I got one shot with a question (that I won't share) that required finding Hamiltonian path in a tree, over the phone of course. I am not sure what is the mindset of the interviewer. I am hiring engineers (systems, software and security) in the last 5 years, got trained up on recruiting by Amazon, so I would say I have a pretty good understanding on hiring. The right approach with thes…
This passage gives me a good idea: The OPower guy said they had a ton of problems where they will be using Scalding, so I asked him what they are doing in its absence. He said Oh we pojo it. Then he said pojo this and pojo that, and soon I was drowning in pojos, so I asked, Sorry, what exactly is a pojo ? Now, bear in mind I am a Scala programmer and haven't touched Java in ages, and they knew that. Their whole pitch…
I was once caught out by that tactic. The interviewer asked if I would use such-and-such algorithm to solve their problem, and I said sure, whatever. I was just thinking to myself, give me the job and I'll research it and make it work. It wasn't until much later that I realized the possibility that such-and-such algorithm didn't really exist, and that I had failed the weeding-out question.
A lot of these posts don't actually address the problem of hiring and filtering people. If you think whiteboard tests or logic puzzles are not effective, why do you think this and what is a better alternative? I personally think they are ok, but should more be a means to test if the candidate can reason intelligently and it shouldn't matter much if the end answer they get is correct or not.
Work sample tests, of course. Basically everybody who read the literature knows what is the better alternative.
I enjoy the challenge of programming interviews. When I interviewed in Mountain View, I thought it was just super cool to have been invited. It was like the mother ship had summoned me home! I was mega-underwhelmed when I botched the last session, though. And after doing so poorly, no one escorted me out or summed things up. Efficient, I suppose -- I'd met with the recruiter at the beginning of the day and there was…
Nice attitude! The fact that your curiousity drove you to figure out the problem long after its solution had immediate utility...that's always a good feature for a programmer.
Earlier quoted context omitted.
This might be viable if you do it remotely: let them take their time to understand the project, understand the task, find the relevant section of the project, find the relevant section of code, understand the change they need to make, set up the development environment, and make the change. That's at minimum a day's work for most tasks, and sometimes two if setup or debugging turns out to be more difficult than expec…
I personally wouldn't be willing to spend 8 or even 16 hours working on an interview question for the chance to receive an offer. I'd take the one hour whiteboard dance.
My three favorite evaluation processes so far (from the POV of the interviewee):
1. Quick phone screen with someone technically competent enough to call me on my BS if it were painfully obvious, followed by a "come in and let's get you working as a contractor".
I went through this scenario twice, and both times it worked out rather well. Of course, there was risk involved with both parties, but it seemed to work fine for both a 5-person startup and 100-employee agency.
2. Phone call to talk generalities and big picture, followed by a lunch meeting that doubled as a conversational technical interview, followed by a take-home exercise on a paid-for-time-if-no-offer basis.
I went through this scenario once, and liked it even better. The idea behind paying me if no offer follows was that I could be (and was) given a real problem the company needs solved (small, fairly standalone feature in my case) that I could work out for them for a reasonable fee. They'd get full rights to the work, I wouldn't feel like it's a waste of my time if nothing comes of it, and it would all be nil and void if I were offered a job in the end.
3. Quick 30-minute phone call with a few team members to get a sense for what the position, team, and I are all about, followed by a 5-hour marathon in-person interview, but broken up into more digestible chunks: 45-min chat with one of the leads, 45-min chat with someone more on par with the position, 45-min whiteboard problem, 45-min session of actually solving problems at a real computer (while being encouraged to do it the way I would, using Google, Stack Overflow, asking them things as I would ask coworkers, etc.), etc.
This last one was at a BigCo in the Valley and I felt was a pretty damn solid way to go about it. I actually basically bombed the whiteboard problem, but didn't feel like it was an unfair question to ask me, as the single interviewer present was more interested in my process than my reciting a memorized answer.
Earlier quoted context omitted.
I was once caught out by that tactic. The interviewer asked if I would use such-and-such algorithm to solve their problem, and I said sure, whatever. I was just thinking to myself, give me the job and I'll research it and make it work. It wasn't until much later that I realized the possibility that such-and-such algorithm didn't really exist, and that I had failed the weeding-out question.
Well, someone failed, but I don't think it was you. Unless you actually lied about knowing it.
Anyone know what a dag is? Seems like a term from finance, but it is literally unGoogleable.
Anyone know what a dag is? Seems like a term from finance, but it is literally unGoogleable.
Anyone know what a dag is? Seems like a term from finance, but it is literally unGoogleable.