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 equally okay if you pick nothing.
Last week I had an interview, let me quickly add; ( I am currently looking for a Front-end Developer role, remote or in Lagos, Nigeria)I had an interview with Interswitch, I was asked to come with writing materials because it was going to be a whiteboard test, more like white paper test because we did it on a white paper not board,
Let me also unashamedly admit that I’m not a fan of whiteboard tests so 2 week’s prior to the interview d I decided to practice at least one algorithm daily until the day of the interview.
I mastered few algorithms and techniques for solving algorithms. Then came the day, I walked into the interswitch office feeling confident as hell knowing I could solve any algorithm thrown at me.
The time came
Question: Given two arrays, Array A and Array B put them in a new Array but there is a twist the zero index of Array A should be the zero index of the new Array, the last index of Array B should be the one index of the new Array, then the one index of the Array A should be two index of the new Array, the penultimate index of Array B should be the three index of the new array and so on until the new array contains array A and array B. You have only 15 minutes to provide a solution and don't use any special array method.
This diagram gives a visual explanation of the test
When I first heard the question I was quite confident I could solve it but as you know being confident doesn't mean you are going to solve it. Long story short I failed the whiteboard test and I am still without job today. I spent the rest of that day, and the next three days thinking of how I was never going to be software developer. Well I was able to summon the courage to look at the question again and try to solve it, I came up with a solution with help from my friend @debugmonstar.
function interweave(array1, array2){
let newArray =[];
let longestArray = (array1.length > array2.length) ? array1 : array2;
let reverseArray = array2.reverse()
for(let i =0; i < longestArray.length ; i++){
if(array1[i]|| array1[i] === 0){
newArray[newArray.length] = array1[i]
}
if(array2[i] || array2[i] === 0){
newArray[newArray.length] = array2[i]
}
}
return newArray
}
let arrayA =[5,7,9,2,6,1,4,0,3]
let arrayB =[12,3,8,1,6]
let output = interweave(arrayA, arrayB)
console.log(output) //returns [5,6,7,1,9,8,2,3,6,12,1,4,0,3]
First we declare a new array called newArray.
Then we find the longer array between array1 and array2 so that we can know the maximum amount of times to iterate through to give us the new array.
Then reverse the array2 because it makes it easier to insert it into the new array.
We then start our iteration, first we check if index (i) exists in array1 or index i of array1 is equal to zero,if so we add it to the newArray then we do the same check for array2 then add it newArray and it continues until the iteration ends.
Then return our newArray.
One problem I struggled with when I was given this question during the interview was that I could not gather my thoughts quickly, different ideas were flying through my head and before I could put pen to paper to 15 minutes was over, So my advice for my future self and other people like me that have to deal with whiteboard test are:
First, stay calm because the question may look tricky initially, but it might be something you can easily achieve,maybe even in less than 10 lines of code.
Don't just jump into the code and start writing, first critically think about what the final result is going to be and how you can achieve it.
Finally failing a whiteboard test doesn't mean you are a failure or you are a trash programmer.
I Am Devloper@iamdevloper
First day of a new programming job, position yourself in front of the whiteboard with a fresh bunch of Sharpies
> judging from the interview, I just presumed this would be my desk11:03 AM - 26 Sep 2018
If you read this up to this point, I am glad the title didn't put you off and hopefully you learnt something. Also,. if you have a different or more elegant solution simply share by kindly writing it in the comment section.
Special Thanks to my friend Yinka Yomi-Joseph for helping me edit this Article
Top comments (4)
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