Should interviewees be allowed to search for answers?

I never do coding challenges in interviews, so no need to look anything up.

I always ask, if candidates understood the technologies they listed in their CV.

I work for a University and we let people use outside resources if they get stuck. The task starts with creating something small that uses plain JS. If they are completely stuck we tell them they can use JQuery or something else from npm. The funny thing is most people we interview either don't need the help and quickly answer the questions, or never complete the task, regardless of what resources they're allowed.

I have similar opinion. But sometimes, I have observed even at good reputed companies, it’s not only the interviewer but the company itself as well. They force the interviewer to ask such coding questions which might not be even remotely related to the work the hiring team does. The change of mindset needs to happen at even the company level.

If a company is hiring software engineers they need to interview them on software engineering skills. Coding is part of it but not all of it. If a company is hiring just based on how well a candidate can reverse a string or linked list in place, then they probably are looking for hiring just coders and not software engineers.

I usually do interviews with pseudo code, I am more interested in the thought process than actual implementation. And usually don't do questions that have a single answer. I am more interested in understand the candidate from a human perspective that his capacity of store data.

This is interesting. i completely agree with you.

Yes. Coding isn't done in a vacuum. No one expects you to solve problems without finding help.

I mean if I give you a problem and you copy and paste a Stack Overflow answer, that's a problem. But if you're googling different array methods or something like that trying to find a solution, then that should be fine.

Algorithms, no

Coding, yes

Maybe it depends. If you're hiring a specialist in something and they have to google basics/intermediate stuff, it's a problem (e.g. security, networking, user experience design). I've never worked at Facebook, but graphs are a big deal over there and I hear their programming interviews revolve around graphs a lot. Even if it's not the case, it's an interesting hypothetical because they might need people who are skilled with working on graphs. They might favor candidates who can talk about data sets where graphs are the structure of choice at scale. That said, maybe they need to google a few specifics. Idk. I'm not a graph expert. I would have to Google that :D

If they're more of a generalist, they can usually talk about it even if they don't know specifics and if it takes them 5 seconds to Google it because they know what they're looking for, that may be a sign they do know what they're talking about. Some of these folks are the smartest people I know especially since they can tell you exactly how systems are put together.

I think it really depends on the role and what an employer is looking for in a candidate.

I believe that question and answer shouldn't include googling, but a code test is a different thing. I had a recent coding test where I was given the task (fairly simple), but it was in JS (a language that I didn't know well). He allowed me to type up some pseudo/near code and after he said that the algorithm was sound (and knowing that I had no experience in JS) he told me to use a browser and make the code work. He wanted to see my process of getting it fixed. He expected that I would be capable of doing the work once I had the opportunity to get into the language and whatever frameworks were necessary.

I totally agree with this. My best experience as an interviewee were those where I was faced with a problem similar to a real life one and where I was encouraged to face it with the usual tools I would use in real life.

Something that is nice to do is also ask high level programming questions. For example if you are interviewing for a JavaScript position it's not a bad idea to test about Event capturing and bubbling, lexical scoping, Promises, Event Loop, etc. You can even prepare your coding challenge with a DOM manipulation situation that would require basic understanding of the event propagation cycle. And even though it's searchable, if the candidate searches with the right words you know they are familiar with those concepts.

I recently did an interview that didn't even have programming challenges at all. It was mind blowing. They wanted to discuss past projects I had already accomplished, some of the issues faces, and how I resolved them. One of the people mentioned having my GitHub up, so I was able to directly reference projects in there so they could see my actual production quality code live, rather than a rushed mess that would have been created in an interview.

There was nothing to even look up in this scenario. Honestly, I think questions like this are only putting Band-Aids on the problems with interviews, instead of actually tackling their underling problems.

The best engineers are problem solvers, not fact memorizes. I'm still so thankful I found a great company that recognizes and respects this notion!

Gonna go against the grain and say no. Even if it reflects the real world experience better, it wouldn’t accurately reflect how proficient they are at the subject. Hiring the wrong person because they lucked into the right answer and managed to confidently sell it is an expensive mistake.

I would say the best coding challenges are where you ask them to work on a very small project that tests the skills you need. You should allow libraries and allow research. Give them a whole week to spend their time on it.

Hackerrank style tests only test their ability to competitive program. And while that is a skill, it's not one often needed in software engineering.

I would be interested in how readable they've made a solution, how they use comments, how they test something etc rather than how quickly they can encode a string to another string.

interesting,

While I agree with the concept that interviewers shouldn't just pepper the candidate with quiz like questions, I do think it ok to ask certain questions (even if they are easily searchable on google).

It's not about if they get it right or wrong, but could give some indication of depth or experience, especially if a candidate is claiming significant knowledge in a particular stack.

For example:

I interview many candidates using Java, Spring, and Hibernate. Though I wouldn't ask them to recite exact configurations for Hibernate's 2nd layer cache, I defiantly would expect someone calming years of experience to know of Hibernate's caching strategies.

I totally agree with you on what our day-to-day job is. I’ve always thought that preventing interviewees of using search engine and pre-built library is a bad way to make an interview.

Especially because the library we are using are most of the time optimized and that’s probably not the job we are applying for.

Actually, I don’t think this way of testing reflects the real potential of the candidate.

In my opinion, interviewers should ask people to solve a problem with all available means (even their own).

For example, having one or two hours to solve a problem in a totally new environnement isn’t a good way to test people.

Ok maybe we should be able to switch Dev environment easily but still it takes time to be used to se Dev env.

If the interviewees can look up the answers, you're asking them the wrong questions.

As for coding challenges, they should be free to do the work however they would do it in a real setting. So... yes.