re: How to approach solving a challenge during a coding interview VIEW POST

TOP OF THREAD FULL DISCUSSION
re: Out of curiosity, how would it end up looking if you'd clearly solved the problem before and are simply typing in the solution? I was given this t...
 

Hello and thank you for the great question. I have been itching to do actually a full article on this particular subject and I think it's time to put it together, so coming up soon.

In the meantime, I want to take a second and state that having someone who has been exposed to the problem before is not a bad thing at all. It simply shows someone who is well prepared or who has experience.

Now, if they pretend that they have never seen it and 'fake' their way to the solution, I personally feel like that does not reflect as an honest trait of character and any savvy interviewer will not be fooled by it.

I personally think that an interview shouldn't be a disconnected exercise or a trivia showdown of things that have no connection with something that a candidate has been doing long enough to have proficiency in it.

It should be expected that the canditate has seen or been exposed to a similar exercise before. Now it's up to the interviewer to craft a good exercise with the right follow up questions that can reveal depth, understanding, style and culture. For that to happen though the interviewer has to be solid and knowledgeable on the discipline. Sometimes, unfortunately, that is not the case..

Let me finish off with a somewhat relatable example. Let's say you are a private cab company that wants to hire a professional driver that knows the city well and can find the best routes to optimize travel time.

Let's say Main Street and 1st is the most impossible intersection at certain times of the day, but there are ways around it. I'm pretty sure that a savvy local driver might've encountered it many times before. Why wouldn't I want to hear his take and experience about it? I probably would ask them about how they would navigate from certain points without GPS. Essentially I would ask them about what they know and what they have been actually challenged and solved for.

The above example might be a stretch, but I honestly believe that it does not matter at all. I'm even an advocate of having the candidate review all the possible questions that I would evaluate him/her before coming on site. I think that they will be more relaxed which is a win for everyone. The 'depth' conversation will even be richer from that perspective.

 

Thanks for the response! With regards to your cab analogy, it seems the best approach would essentially be to write down said cleanest solution and while doing so, discuss why it was chosen over other approaches and the possible pitfalls, and how one would circumvent them if they were included in the scope of the question.

I guess it can be an opportunity to show that you're capable of seeing how your solution may need to adapt to slight changes in requirements - I believe the way I solved this in Ruby would have failed with numbers where the length exceeded that of the "Fizz/Buzz" and I'd imagine addressing this while writing the solution would demonstrate a good ability to criticize one's own code.

Appreciate the response - opened my eyes to a different way to approach already known solutions!

Yes, the whole point is to dig as deep as possible to assess levels of understanding. I, for example like the formulation of "How would you explain the concept of closures to a junior developer and to a non technical person?" versus "What is a Javascript closure? Provide some examples"
I think the first one is more prone to reveal depth in understanding than the second formulation which by the way is the most popular screening question in Javascript.
Thank you for adding to the discussion, I surely appreciate the comments.

code of conduct - report abuse