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...
For further actions, you may consider blocking this person and/or reporting abuse
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 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.
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.
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.
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.
Knowing how to search is also a skill
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 :(
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.
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.
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.
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.
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 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.
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
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.
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.