Ok, but this is not really a puzzle. It looks like a rather trivial exercise just to see if you can write nested loops. I guess an average software engineer shouldn't have problems with this. Or I am missing something.
I don’t know why I can’t do it. I freeze up with analysis paralysis, or stage fright, or something. Maybe it’s because I have no clue what they’re looking for, and I’m so used to simplifying problems based on business cases and stakeholder feedback. Maybe it’s because I’m always thinking about production-grade code (I do try to avoid nested loops!). Maybe because I assume that the problem requires a specialized data structure, and so try to invent it on the spot. Or, it could be that I am old-school and like to solve problems on paper first before coding.
You may not believe me, but I code everyday. At every job I’ve held, I’ve been complimented as one of the best programmers. So, maybe I’ve only ever worked with C-grade developers? But, I’ve worked with 100s of people. How can that be?
But, let’s say that I really do suck at coding. Are all my other attributes, skills, and experiences valueless? Seems like such a waste.
Years ago, relatively early in my career, I went into management. But, I only did it for 2 years before going technical again. It just didn’t make sense at that time. Senior developers then made more than managers, and I enjoyed building things. Now, I really regret that decision.
Anyway ... I clearly can’t get a job. Anyone have any career ideas for a washed up software engineer?
Also, there are strategies for managing the time problem. 20 minutes is a bit fast for understand => ask questions => implement => test on this problem. But you can organize the code so that if you run out of time it's still clear you knew how to solve the problem and can code your way out of a wet paper bag. E.g., I would pass an answer that got everything correct but didn't get around to implementing isPalindrome() or isSoCS() before the 20 minutes was up, especially if the candidate could give a ~1 minute description of how to implement those functions. (I would also give more than 20 minutes.)
However, I haven't experienced repeated failure of a consistent type, so I'm not particularly motivated to worry about this sort of thing. I do know that different companies have radically different processes, so if someone tells you "you're not a good fit" it may be completely true and not a negative judgement at all (even if that's how they mean it).
It so happens that I got my undergraduate degree about ten years later than is typical, and thus I can pass for someone that much younger than me, at present. So in an interview, it is tempting for me to give away my age by reminiscing about computing in the 80s, and that could have caused me to be rejected a couple times but I will never know for sure...
I thought it was kind of silly but have you tried practicing on hackerrank or leetcode for the coding tests? Hackerrank feels pretty brittle but a lot of companies use it for timed screening so good to get a feel for the platform's ability to lose all your work in a non pressure situation, leetcode has very useful discussions about user supplied solutions.
This is an interesting list that has been posted here before:
- https://github.com/poteto/hiring-without-whiteboards
But if you want to work somewhere firmly in the whiteboard club - do regular practice on hackerrank and leetcode. Many interviewers will draw their questions directly from those sites (and some others, I'm sure).
(Personally, I honestly feel those exercises have improved my coding, so there's that too.)
You're not alone. I recently went thru this myself and wrote up my experiences here: http://fuzzyblog.io/blog/jobhound/2018/04/24/ten-things-i-le...
I hope that helps.
But a surprising number of applicants fail to pass a simple coding test, not even getting a naive solution.
One thing that really helps with perspective, whichever side of an interview you are usually on, is to have seen how radically differently different companies do things.
That doesn't necessarily mean that you should change your practices, but diversity in behavior exists because there are niches that can be exploited and trade-offs to doing so.