I know the post’s title suggests a negative connotation but maybe after reading my story in this article you should learn something, but it’s e...
For further actions, you may consider blocking this person and/or reporting abuse
I'm so disappointed with companies who choose to interview this way.
I've also been in interviews where one is asked to write code (pseudo or otherwise) during the session. I believe these kinds of tactics and those which ask for many hours of personal time in advance to submit a solution are rubbish. (1) it's a tall order to ask so much of a person emotionally (in the interview) and physically (full weekend of work), and (2) it's a poor means to assess ones ability to solve real problems.
Now I admit that there are some dev jobs which require constant creation and improvement of algorithm-like solutions. But for most of us, building line-of-business or straightforward consumer applications, we don't face these challenges on a regular basis. So if you're in the latter camp (and a lot of us are) then right there it's a poor intersection of daily work and interview technique.
If you do happen to have this type of challenge on a regular basis, then for goodness sake, give the candidate an environment where they can write real code and not whiteboard things. This way you're really seeing what they can do and how they code. Maybe even make it a pairing exercise and try to help them feel safe and not stressed. Simulate your real team - in mine, this problem would probably be tackled by a group as I've found that the more complex a problem is, the better return on time you get when you add developers to the conversation. The paper and whiteboard abstraction, stress and chaos is not what you want your potential candidates to assess your working environment on. And if you really don't have this kind of daily work environment, then why simulate it for an interview!?
As many of you know, DHH/Jason are quite wound up about this "chaos development" subject which seems to be popular lately. It must have bothered them because they've just released a book about it. m.signalvnoise.com/the-calm-compan...
Great work Nero on your solution and please don't use a poor experience like this to measure your ability as a dev. You clearly know what you're doing!
Personally, I'd choose to do this with a peer, come up with something like your (very clear!) visual mapping, and then write a failing test. This way I have a clear path to the goal with the implementation code. Would you do it different? Great! That's fine. And I hope you'd be lucky enough to do it in some peace and quiet or with a trusted, and calm colleague.
The stress and pressure created by solving nonsense, unrealistic problems in interviews doesn't help anyone. Please stop it.
Thanks for sharing your story.
First of all, I hope you're not still worried that you'll never make it as a Software Developer. Most people I know have failed these kinds of tests. to be honest, I failed one pretty spectacularly about 8 years ago.
You are spot on with your advice. One thing I stress is to keep calm. Don't expect to be able to instantly solve any problem. Sit back, relax, and think about the "moving parts" of the problem. Then simply start talking about it. Ask questions. Model your thoughts on the whiteboard. If you start to see part of a solution, start talking about it. Normally these types of problems have specific twists that make them a bit harder. Start by ignoring that twist. Explain to the interviewer that you want to get some of the core mechanisms working first before tacking the harder problems.
In this case, I put myself into the interview position and started talking to my wall. the first thing I thought was "this is effectively an 'interleave' function with a couple of twists (reverse the second array, keep track of the longer of the two arrays, etc). Then I started solving the simpler problem on paper. My first attempt got thwarted and I scratched it and tried again. I didn't worry about trying to make the code really nice and clean - I just started by keeping a couple of variables as pointers into the A and B arrays and then did a simple for loop. I got the answer right after about 5 to 10 minutes. The important thing to remember is that if I was being interviewed, I would be talking the whole time. Basically, I'd be making light of the situation, having a laugh, being calm.
Anyway, I could keep talking but should wrap this up... Good luck! Work hard, keep learning. You'll make it.
Thank you for advice, hopefully I'd be able to apply everything you said in my next whiteboard interview.
Big ups big man