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!
Oldest comments (29)
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.
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.
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.
Seriously? How many times at day do you write real code without using Google.
Plenty of times...
Plenty of times is not the same than never, then an interview should simulate plenty of times rather than never
My thoughts exactly!
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.
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 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.
This 😃
Although because of this I may not be able to get any Placements in my college :(
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.
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
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.
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).
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.
Knowing how to search is also a skill
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!
💯 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.
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 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.
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.
Algorithms, no
Coding, yes