I am fairly experienced and I can simulate stuff in my head quite quickly but this often has a detrimental effect -- I get a few ideas, see all their flaws and get an analysis paralysis. I flunked one otherwise promising interview by doing this.
Sometimes you just freeze, you know. I have confidence of having excellent problem-solving skills but they are not always summonable on demand right at this minute.
I have a fairly successful -- if very rich on employers -- career so I should probably view the above as a personal weakness and not as something inherently bad, but I am not sure.
How do you feel about such people?
(I usually prefer a take-home assignment even if it's more work. It gives me a chance to show excellent craftsmanship and attention to detail, which I really want to demonstrate during the interview process.)
Since in the past few years I've only been interviewing freelancers for temporary positions on the projects I've worked on, I kept going with this simpler task. Now even with that, some people struggle. And I see that as a very bad sign. But I'm always giving hints and helping. I always start by saying that if you have any questions or feel like discussing an idea, feel free. And if they keep thinking and don't tell anything I'll start the discussion. (But that's part of the test, because, you know, things like this happen during real work: you get stuck, you don't understand the requirements, etc. And then I will want you to reach out and ask/discuss.)
Another task I do during the interviews is code review. Even if you do badly on the first one. The piece of code (now actually two pieces) has a lot of room for improvement, while only about 20 lines long. That's a totally different kind of task, less about problem solving and I guess less prone to cause anyone to freeze.
Oh. We kind of talked past each other then. Sorry!
Just today I had ~15 minutes to craft a basic SQL update statement generator based on an (almost) arbitrary JSON input. Save for me misunderstanding the requirements initially, I aced it and the interviewer was impressed.
General problem-solving and chatting about real problems that the company has I found to be the best format of technical interviews. One experienced programmer can extremely easily call out BS if the candidate is faking their expertise.
---
As for me freezing, yeah, it can happen but I accepted it. I can't have all the IT problem space in my head all the time. I expect the interviewer to be flexible in these cases. If not, oh well, life goes on.
What I would do during your interview is performance theatre and it would tell you nothing. I would lie to you about whether I have seen the problem you presented before, because I would only be there because I was on an interview-circuit with every interviewer that thinks they are so clever and hasn't changed their question for years and I recycle and adapt answers, and for you, the answer to your question is probably listed verbatim on Blind, Glassdoor or Leetcode forums about your company and role.
It felt pretty bad, because he knew there would be another, harder task and we knew that he had no chance, so what do you do. But again, the task is simple, you don't need an IDE, you don't need to use any API. Some people do the very obvious solution (though that never occurred to me until I saw someone going down that path) which does need maybe 1-2 calls to the stdlib. But I always tell them that syntax details don't matter, they can use any language, and if they want to use some lib or API then they can just say that and I'll believe the thing is there and the call does what they say it does. (Unless it's obviously not true then I'll say how I think it works.) But it's mostly theoretical, because as I've said you don't need any APIs (though some people sometimes ask about the exact semantics of some less common language features and then we just agree that it works the way they say it works). It may sound cryptic, but that's just because I don't want to give away the puzzle :). E.g. think about what happens when an addition (using the plus operator) causes an overflow in their language of choice. It's just an analogy and even the thing it's an analogy for (that came up during one of the interviews) is not needed, but given how some candidates solve it, it may come up. And then I'll ask what could happen then, how do they think it works. If I know how that works I'll tell them if not, I'll just believe it works the way they say. Doesn't matter.
It's not a theatre. The idea is to somehow simulate a situation similar to what you'd experience during work from the perspective of problem solving . E.g. you'd be surprised, but a lot of people just don't think about testing their solution. So if you are really testing habitually, then I'm pretty sure I'd see (hear) you walk through the code, and run your test cases in your head. Maybe you'd start with stating test inputs and expected test outputs. A few people I've seen actually did that. And of course, these all register and tell a lot about how you work and how you think.
>every interviewer that thinks they are so clever and hasn't changed their question for years and I recycle and adapt answers, and for you, > the answer to your question is probably listed verbatim on Blind, Glassdoor or Leetcode forums about your company and role.
1. My company is not on Glassdoor or Leetcode. It doesn't apply to small companies 2. The task is simple, it's not worth memorizing it. Actually it's so simple that if someone needs to memorize this, then they will have a problem memorizing harder puzzles for sure. 3. It's pretty easy to identify if someone knows the quiz (though, of course they can pretend that they don't, but that's borderline sociopathic) 4. I also use a code review challenge which is harder to reproduce, though some guy could be unfair and post it there 5. If this becomes a real problem for me, I'll probably add pair programming to the mix
I understand the motivation for some people to want to circumvent interviews, thinking those don't do justice for them. It's hard to tell. I've never been afraid of interviews, though I've never really interviewed to any job where I though I had to get in. The problem with posting questions and trying to circumvent is that the response will probably be that interviewers just keep changing the questions which will result in less predictable outcomes. Or everyone will just require a long, take-home project (though you can game that one pretty easily too) or throw more automation at you. (e.g. a 1.5 hours long HackerRank quiz just to get through to a human.) Seems like and instance of the prisoners dilemma to me.
Just by struggling with a (really not that hard) challenge tells a lot about how well someone is able to listen. E.g. when you try to give hints to them. It also shows a bit about their demand for producing quality work. (The first solution they provide is usually not bug free. They miss edge cases. Then they add conditions to check for them but those are not needed because the algorithm can be written in a pretty simple form. BTW, I've been using the same challenge for years. Whether someone is willing to simplify shows a lot about how much they care about the quality of their work.)
But yeah, I found that usual chit chat about technology with a few directed questions also help (and I use them).