JavaScript for Dummies (Me): Part 5

Getting schooled in the mock-interview chair

5 min readJun 4, 2018

Last week the folks at Guru generously hosted mock interviews for our graduating class at New York Code + Design Academy. (Big thanks to Armard Bellamy and the others who participated and helped organize it!) It was an excellent opportunity to feel what it’s like to do an in-person technical interview, (since I have a non-technical background).

They also provided very constructive feedback. For me, on the technical side, I had difficulty answering ‘basic concepts’ in Ruby such as:

What is encapsulation?
What is the difference between symbol and string?

It was very humbling to have to say, for example, “Honestly… I don’t know what encapsulation is.”

It was even more humbling to be given a basic white-boarding problem to “reverse a string without using a built-in method” — something I’ve done numerous times — then struggle to work through it. I ended up needing a good deal of guidance from the interviewer.

When I received the written feedback the following day, I immediately wanted to make excuses (to myself) for not being up to snuff. Or to think, “I was just nervous,” or “Did I learn anything of value in the last three months?” But I quickly realized that’s not helpful.

Instead, I took some time to reflect on my strengths, weaknesses, and how to improve.

Everyone has a different learning style.

While I did give in to the thought, “I’ve been building applications that work, but I can’t answer the fundamentals without my computer!” a little too much, I realized I need to be generous toward myself in this process. We all do whenever learning something new because we can’t expect to master something in only three months.

A few months ago I read an article by Ralph Ammer titled, Seeing vs. reading: the key to creativity, in which he talked about the difference between rational and intuitive thinking.

I’ve always been more of an intuitive learner. In school, because the measure of our knowledge was based on our ability to regurgitate facts, I became good at memorizing information, only to forget it soon after the test.

It wasn’t until high school that I discovered my love for music. Studying piano required me to balance my rational and intuitive thinking, but again, the technical side (e.g., learning scales) was more challenging (and also less enjoyable) than learning the beautiful Chopin Etudes.

In other words, it’s possible to be good at something without understanding the technical details behind it.

That said, I’m getting into a technical field, and so, my technical skills have to improve.

So how can I improve?

I’m grateful for their feedback, as it gives me a more concrete awareness of what I need to focus on.

Growth only happens through persistence. So onward and upward!

One thing they recommended was to practice our coding challenges and ‘white-boarding’ skills using HackerRank and Codewars.

I’ve been working my way (slowly) through JavaScript exercises on CodeFights but decided to give Codewars a try this morning.

The problem

Create a function named divisors/Divisors that takes an integer and returns an array with all of the integer's divisors (except for 1 and the number itself). If the number is prime return the string '(integer) is prime.'Example:divisors(12); // should return [2,3,4,6]
divisors(25); // should return [5]
divisors(13); // should return "13 is prime"

My Thought Process

I started with paper and pencil this time, to imitate as best I could the feeling of working on a whiteboard. I figure, the more I can get familiar with that initial feeling of, “Oh my God, where do I start?” and move on from there, the better.

I generally start with writing out some questions on paper, then jump into writing and testing code. It’s rare that I try to work through the entire problem on paper. This time I forced myself to go as far as I could before turning to my computer.

The problem was simple, but it’s amazing how using pencil and paper seem to work different muscles in my brain! It’s a useful exercise.

I started by rewriting the problem. I find that doing so often reveals the next step or question to ask.
In this case, it became clear that I had to capture the integers between 1 and the given integer (parameter).
The main way I’m familiar with doing that is a for loop. So, “maybe…” I wrote, if i = 0; i < x; i++. Doing this was enough to get me on the right track.
I then wrote out as best I could, what I thought the code should look like, without touching my computer (a big step for me):

There are a few eraser marks because as I worked through it, I realized that I’d need to start the loop at i = 2, because the problem indicates the function should return the divisors “except for 1.” I also had some issues with how to write x % i === 0. At first I wrote: x / i % === 0. It’s so interesting how my brain processes differently with pencil and paper. Things that normally seem familiar on the computer become, well, unfamiliar. Perhaps writing it out on paper is exercising the rational side of my brain.

What I ended up doing preliminarily was the below:

arr = [];
function divisors(x) {
  for (var i = 2; i < x; i++){
    if (x % i === 0){
      arr.push(i);
    } else {
      console.log(`$(x) doesn't belong`);
    }
  } if (arr == []) {
  console.log(`${x} is a prime number`);
 } else {
  console.log(`${x} is not a prime number`);
 }
 return arr;
}

When I ran the tests, my issues were two-fold:

Because I was setting arr = [] outside the function, when the second test ran, it added the new integers to the existing ones. Instead, I needed to reset arr = [] after the start of the function.
By writing arr == [] I was trying to say “if arr equals an empty array…” I had to Google “how to check if an array is empty” to figure out what my issue was. An answer on Stack Overflow revealed that I could check to see if the length of the array was equal to 0, or arr.length === 0.

function divisors(x) {
arr = [];
 for (var i=2;i<x;i++){
  if (x % i === 0){
   arr.push(i);
        }
 } if (arr.length === 0) {
        return `${x} is prime`;
    } else {
        return arr;
    }
}

And thankfully it worked!

I’m looking forward to continuing these exercises and learning more as time goes on.