Indeed. When I was interviewing candidates, one of my goals was to get the candidate to respond along the lines of "I don't know.", to which I would follow up with, how would you find out? No engineer knows everything. I also don't want a candidate that is going to try and bullshit me. Admit to me you don't know, but then tell me how you would rectify that. Google SO, MSDN, man pages, whatever, I don't care so long as you can admit you don't know and have an idea about how to correct that.
Personally, I'm doing mostly Python & C++ development at my new job (4 months in) after not using either for 2 years plus. I'm mostly fine with syntax for both, but constantly have my browser open for documentation, mostly for library related info.
In the interview for my first job after university I was asked a Unix trivia question. I said "Oh, I dunno... Most of my Unix knowledge is swapped out to the man pages!"
The company I'm at does two coding interviews for potential developer hires.
The first is kind of a standard phone interview with a Google Doc. There is no expectation that the code you write would actually compile or run. When I conduct this interview I'm always sure to explicitly say that it's not a test of memory and they shouldn't worry about remembering specific standard library functions, etc. If they need something that they know exists but they don't remember the specifics, I encourage them to make up something that seems reasonable and just go with it.
The second is an onsite interview where we plop them at a desktop machine, give them a relatively simple programming task, and ask them to produce a runnable program. They have access to the internet and really the entire machine. They can Google whatever they want and even use Stack Overflow. Nobody is standing there hovering over their shoulder. This interview gets weighted more than the previous one.
Within these restrictions, I don't think they expect your written code to compile. They just want to ensure the integrity of the test itself. Is it worth the invasion of privacy? Personally, I don't think so.
About 8 years ago, I interviewed w/ Amazon & I chose to do my interview in C++. Although there was no actual compilation, I did get called out for small pedantic syntax errors. Maybe it depends on the individuals that are interviewing you.
Well if you participate in an on-site test which the person was willing to do you are essentially tested under the same conditions, so I'd not really consider this to be a privacy invasion.
You're presumably giving them a view into your home and its location. You'd potentially be required to change security settings on your computer, to re-enable things that had been explicitly disabled. You're likely to also want to close whichever browser tabs or open programs that might be deemed unprofessional.
Those are all things that I'd consider invasive that I don't have to deal with during an in-person interview. And the wording is just creepy anyhow.
True enough, but not everybody actually lives in places where on-site testing is an option, and they'd probably prefer cleaning their room up to not having the ability to apply for a job.
And given that all of this happens voluntarily, and assuming that Amazon isn't going to infect you with malware(which seems very unlikely) this kind of testing is a great opportunity for people who have the resources or time to show up in person.
There's some kind of privacy chauvinism involved in these discussions that ignores the realities of people who don't live next to the Amazon HQ.
What I wrote was just a reaction to when you said that the arrangement wasn't a privacy invasion. I don't have any problem with off-site testing, just this particular implementation of it, which seems uncomfortably distrustful, like a harbinger of what working there would be like.
> And given that all of this happens voluntarily
There's voluntary in the sense of willingly (I have no reservations about doing this; heck, I'd offer even if you didn't ask me to), there's voluntary (I choose to do a thing that sucks because I don't seem to have another choice), and there's everything in between. My problem is when the "voluntary" action is more on the negative side of that scale, which it often is when someone's looking for a job.
I'm not trying to criticize candidates' choices. I'm trying to criticize Amazon's implementation of their hiring process. The point isn't that "candidates should be principled enough not to stand for it", but that Amazon should decide "this way sucks, let's find something better".
> assuming that Amazon isn't going to infect you with malware(which seems very unlikely)
True, they just have you voluntarily install someone else's malware.
There's different types of coding. Using xyz UI framework or fancy runtime environment will of course require reference.
Sorting a list of points or finding a simple pattern in an array will not. If you need SO to answer the types of questions they ask, you probably shouldn't be seeking an engineering position at a software company.
I know I might get shit for it from HN, but I don't remember jack shit about specifics of implementing sorting algorithms or how to invert a binary tree, because I don't need it right now. I know some of the ideas about why and when you need some sorts over others, but the ins and outs I can get if or when I need them.
Currently I could talk you damn ear off about 9 different ways of doing a topological sort (and which ones you can use if it's guaranteed to be a DAG, etc...), but that's only because I spent my last few days working very closely with stuff like that. Ask me in a month and I'll be back to knowing jack shit about the specifics.
I'm terrible at these kinds of interview questions, but I feel I'm a productive developer.
The last time I screened with Amazon, they wanted me to have a notebook handy, write down the code in the notebook with a pencil, and read it back to them over the phone. That's just how they roll there so unless you can implement linked lists, sorts and the like from memory, don't work for Amazon.
Exactly. When I was doing this, one of the questions required the use of a custom comparator. I spent the remaining 20 minutes of the challenge trying (and failing) to remember the correct syntax for writing a comparator until it timed out.
I also did that question. You had access to the full Java docs.
I left a nice note explaining how I spent a lot of time trying to do it with the language feature, but couldn't due to runtime restrictions, and gave them a working non-optimized solution.
I was emailed to schedule an interview the next day.
That's why they won't expect anything useful from that process. They will most likely expect some basic programming knowledge and ability to reason about made up problems.
I hear this a lot and it always pisses me off. Part of what I believe gives me value is that I can recall from memory most of what I do day to day without looking it up. I have coworkers who are good, but possess terrible memories. Most are semi impressed with I rattle off a shell script and all the flags needed to get it to work on the first try.
I think the anger comes because I see it as a cop out, and I feel I get the short end of the stick in interviews because of it.
If I had to code purely from memory, without the benefit of language or library docs, I would not be able to write anything of use.
Personally when hiring, I'm not interested in a candidate's memory recall, but the ability to use resources when faced with a new challenge.