Frontend Mock Interview #1: A Few Takeaways
I bombed it but I also didn’t?
Honestly, the jury’s out, still. And by “the jury” I mean my interviewer. He hasn’t provided feedback. Which maybe means I failed? I dunno. I definitely need more practice, so I won’t be crushed if it is a fail.
Anyway, let me back up. I had a frontend mock interview this morning, as part of my curriculum at Formation! This is the final fulfillment of the Frontend Web portion of training; over the past three or four weeks I’ve done loads of pair programming and mentor sessions and partially put together a bunch of HTML/CSS and JS/React projects with the help of my peers. I’ve passed two CodeSignal assessments: one covering HTML/CSS, and the other covering React & the DOM.
Now, all that remains is this big, scary pillar. Passing a mock interview.
So How Did It Go?
Well, okay. I didn’t go into the session feeling confident, which I told my interviewer, Erik, right off the bat. Actually, I used the word “terrified”. Accurate. I need…a bit more practice with React before I’ll feel ready for a frontend interview.
The actual prompt wasn’t difficult: create a credit card number input field that takes 12-16 characters, digits only. No submission button required, but when I asked about having a message under the field with less than 12 characters, he told me to go ahead and do that too.
I broke the prompt down into smaller parts before I jumped in. The steps:
- Create input field
- Create state variable that updates based on what’s being typed into the input field.
- Create validation function for the field — block typing if the character isn’t a digit, or if the state value is longer than 16 characters.
- Create conditionally-rendered message field below the input field that disappears when state value is 12 or more characters.
That was it! No messing around with styles or nothin’.
Unfortunately, I got snagged on #3. I’ll get into all that with…
What I Learned
- Store state value in an input field’s value attribute! Duh, Em. This is something I was just naturally including when copy-pasting all my code during my time at Catalyte. When I actually have to remember to do it? Woof. The problem is, I was reading the actual stored state of the input field when trying to validate it, so it was always slightly behind. This was fixed, when value got set to the state.
- Regex, man. Had to pull it out of nowhere after several months of not using it. ^ is the start of a string. $ means at last one occurence? $+ means one more more. $* means ZERO or more, which was handed to me, and was the fix to the final bug in the field. (You could backspace out until the final character, which would be blocked because validation was not letting typing happen for things that didn’t follow the regex, and the regex was saying that the value had to have at least one digit.) \d\ means any digit. So! ^\d\$* means “e.target.value must contain zero or more digits only.
- Write function calls like {this} instead of {(e)=>this(e)}, although I’m still not certain what one does over the other. I mean, I understand that that’s essentially the same, but {this} is apparently different than {()=>this} and I’m not certain how or why. So that’s my homework today. So far I’ve come to understand that the latter maybe prevents infinite re-renders?
The Takeaway
The takeaway is that I don’t feel like I utterly failed — I’ll learn! I rendered the component as requested, and I did a pretty good job of it, even if I had to ask for help along the way.
My next mock interview is on Monday, and this is because, urp, I have a real live pair-programming interview the following Monday.
So I need practice. And prayers. And probably loads of coffee too, because why not? This could happen. If it does, I’ll update accordingly. And then a brand-new journey will begin for meeeee!
mins
read
