Memory Recall: An Interview Thought

At least a few hundred JavaScript algorithm challenges after taking Harvard’s CS50 course, I realized that I use (my brain uses) a “trie” type of knowledge retrieval approach, as compared to someone who can do more of a “dictionary” type of memory lookup. That is, my recall works better when I’m creating and analyzing code (e.g., surrounded by context).

For instance, if I come across a need for the “spread operator”, I may need to look up a quick example for syntax reference, but I know I can use it and I will put it to use. Or I may devise another method that may work out better long term, considering the potential future expansion of that particular code. Or I may just prefer another approach (e.g., I prefer `slice()` and `concat()` for copying arrays (but would always go with whatever coding guide I’m working with, if any)).

Anecdotal disclaimer: Using unfamiliar functionality can take me a half dozen trial and error attempts, but I always figure it out for the better of the project.

In short, I recall and know code better when I’m working directly with code (and Dev Tools!); not when answering academia explaining what a spread operator is. I have used it; I have it in my code; let’s go take a look! 😀 
#693: <SettingsForm setTimer={this.setTimer} {...configSettings} /></SettingsForm> 
#904: this.state = { ...this.initialState()
#920: const newObj = Object.assign({}, {...this.state}, {...this.initialState()}) 
#990: <input type="text" name="entryTitle"
   autoFocus={(document.referrer !== '' && document.referrer !== '')}
   ref={(input) => { this.textInput = input; }}

I would like to devise an approach for delivering a similar level of knowledge sharing (for an interview) that can reveal my level of experience (and my particular code recall approach) is just as valuable (or perhaps revealing just as many pros and cons) as someone who has (or can feign) immediate (hashmap) recall.

For now, the only approach I can think of, is that I believe I could convey such an experience level by writing out my “From Scratch” GistBox project, while also explaining the `what’s` and `why’s` of my coding approach (although unfortunately, I do not use the spread operator in this particular project). (challenge #4: GistBox)

Keith D Commiskey

2 thoughts on “Memory Recall: An Interview Thought

  1. Recent Interview #2: The Technical Interview

    I couldn't answer, "what new features were added with ES6 and ES7?" I thought of fat arrows, but was reminded those were in ES5. D'oh! I recalled that a lot of prototypal objects had a lot of methods added to them, but couldn't recall any of the methods.

    When the interviewer spared me the agony of not being able to recall things of this nature off the top of my head, and I assured him if I'm in the code I can talk the talk… the instructor moved on, which is when I then recalled and stammered, "Async was in ES7… yes!?" He agreed, and added that promises were one of his favorite features. A modicum of redemption.

    I use ES6 features daily, yet have no idea what they're called. And although I don't know their names, I only need to look up the parameter options for .reduce() once in a great while (but even that is pretty straightforward).

  2. My conclusion and current motto:

    If you ask me for a list of methods, or what a method does, I will likely draw a blank.

    If you ask me to create a project, and in that project I determine I need one of those methods, my brain will draw that conclusion, then it will recall the method I need. Or, it will recall something in close proximity, and I can google it for an SO or MDN result.

    If it's arcane enough, this can take a few minutes, but if it's something I used a few weeks or months ago, I'll have it written out in a minute or two (obviously depending on the complexity of the method; although even a sort() doesn't take too long–just don't forgot to return that 3rd condition 😉 ).

Leave a Reply