DEV Community

Kurt Kemple
Kurt Kemple

Posted on

Should interviewees be allowed to search for answers?

I spoke with a colleague today about interviewing and we were both in agreement that not being able to look up answers/solutions to problems is not a good way to interview. Really takes away from the real-world experience of a developer. I wear out that Google search bar on a daily basis so why would we expect others to be able to recall information from their heads when it can easily be searched for.

On another note, should they be able to use pre-built solutions like libraries or frameworks to solve problems. Again, I'm of the yes attitude. Providing an existing solution is something we do all the time in our day-to-day jobs.

Can't wait to hear what you think!

Top comments (29)

Collapse
 
cher profile image
Cher

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.

Collapse
 
theworstdev profile image
Kurt Kemple

yeah! this was totally in regard to coding challenges, any type of whiteboarding, etc. I'm more a fan of behavioral style interviews like the STAR interviewing method.

Collapse
 
cher profile image
Cher

I haven't had any management training, but my preferred ways to ask questions (especially in a paired coding session) is to frame everything in a way that makes it comfortable for them to say they don't know something, or don't know how to do something.

We tend to feel more off about a candidate if they look like they are pretending they know something, which really sucks when they totally know it, but are getting into their own head.

My favorite interview experiences always are the ones where they say they are stuck/or they don't know, and a little nudge helps them find their way.

Collapse
 
cutiko profile image
Erick Navarro

Seriously? How many times at day do you write real code without using Google.

Thread Thread
 
binarypatrick profile image
BinaryPatrick

Plenty of times...

Thread Thread
 
cutiko profile image
Erick Navarro

Plenty of times is not the same than never, then an interview should simulate plenty of times rather than never

Collapse
 
shreyasminocha profile image
Shreyas Minocha

My thoughts exactly!

Collapse
 
darkain profile image
Vincent Milum Jr • Edited

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!

Collapse
 
gypsydave5 profile image
David Wickes

The best engineers are problem solvers, not fact memorizes

๐Ÿ’ฏ this

When I'm hiring I'm looking for the right attitude to solving the problem in hand, and a suitable approach.

For instance, I wouldn't instantly judge a developer if they didn't know how to create and use an HTTP client in a given language. But if they didn't know that they needed a client, or that it was called a client, I'd worry. If they don't know how to make a POST request to send a form, that's fine - but I'd want them to know that that's what they need to do, to tell me that, and then to search for how to do it.

What I look for is a developer who doesn't get stuck, doesn't panic, reads their stack traces, and does something rational as their next step (I loathe developers who just flail around changing things until it works). And searching for an answer on the web is a very rational thing to do.

Collapse
 
victorjperez profile image
Victor Perez

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.

Collapse
 
ahferroin7 profile image
Austin S. Hemmelgarn

Hiring the wrong person because they happened to know exactly the subset of information needed to pass the coding test part of the interview is arguably even more expensive of a mistake, especially when six months down the road you switch to a different platform and they aren't able to learn it in time to be a contributing member of the team.

Learning is a skill. Especially so when it's on-the-job with a deadline. I'd much rather have someone who knows hos to find the correct answer than someone who just knows it, because being able to find the correct answer is quite simpy much more useful long-term.

If I'm in an interviewing position, I'd let the interviewee search (and use an actual development system with proper tools), but I'd be making a point to pay attention to how they're going about completing the test, how they're searching, what they're searching for, whether or not they're cross-validating information, etc. From that, you can get a rather good idea not just of how knowledgeable they are about the subject area, but also how well they work in general, and how confident they are in their own knowledge (hiring someone who's overconfident in their knowledge of something is arguably worse than hiring someone who has no knowledge of it whatsoever).

Collapse
 
victorjperez profile image
Victor Perez

This is a good reply, I guess I didnโ€™t think about how much you can learn from seeing someoneโ€™s workflow. I wonder why more companies (correct me if Iโ€™m wrong) donโ€™t do pair programming or something similar to help evaluate that.

Collapse
 
__shadz_ profile image
Chardenal Matthieu

Making a good search is a skill imo, not everyone know how to search/use search engine :) don't think there is luck in that

Collapse
 
victorjperez profile image
Victor Perez

Also true! I'd consider it more of a general life skill however. There's lots of industries where being able to quickly look up exactly what you're looking for is essential, though it certainly is a big part of programming.

Collapse
 
cutiko profile image
Erick Navarro

Knowing how to search is also a skill

Collapse
 
danjconn profile image
Dan Conn • Edited

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.

Collapse
 
bhupesh profile image
Bhupesh Varshney ๐Ÿ‘พ

This ๐Ÿ˜ƒ
Although because of this I may not be able to get any Placements in my college :(

Collapse
 
bricegovin profile image
Brice Govin

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.

Collapse
 
xanderyzwich profile image
Corey McCarty

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.

Collapse
 
jckuhl profile image
Jonathan Kuhl

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.

Collapse
 
binarypatrick profile image
BinaryPatrick

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.

Collapse
 
sdesani profile image
Santosh Desani

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.

Collapse
 
jennrmillerdev profile image
Jen Miller

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.

Collapse
 
voluntadpear profile image
Guillermo Peralta Scura

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.

Collapse
 
_morgan_adams_ profile image
morgana

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.

Collapse
 
cutiko profile image
Erick Navarro

Algorithms, no
Coding, yes

Collapse
 
javierg profile image
Javier Guerra • Edited

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.

Collapse
 
massivebrains profile image
Segun Olaiya

This is interesting. i completely agree with you.