Last week I had my first onsite technical interview. Though I’ve been job hunting throughout the summer, I’ve spent the majority of my time trying to meet people in the industry and learning new technologies while practicing ones I’m familiar with. As a result, I haven’t actually applied to an exorbitant number of jobs. Everyone has a different approach, of course, but I personally don’t believe that strongly in cold applying and only occasionally do it. So it’s taken some time to finally see a bit of ROI for my work and with the contacts I’ve made. The upside to this approach is that I’ve made a lot of really great, and authentic, connections in the industry. The downside…not much actual tech interview practice and being a liiiittle bit rusty on solving/talking about my code out loud.
Uuuummmm…
So I was incredibly nervous when it came time to interview. I don’t necessarily have any tips on how to reduce anxiety other than what plenty of other people have mentioned: prepare, practice and get experience. Well for that last one, you can’t get experience until you get a chance to get experience so…here was my first chance. While I had tried to not elevate any expectations regarding this position, it’s sort of inevitable that you become a little hopeful when you’re in a position to potentially land a job. I mean, it’s just human nature, right? On top of that, I had spent the past month teaching myself Java so when I got the notification on Wednesday afternoon that I was scheduled for Friday morning, I started to panic a little. I used the evening and following day to brush up on JavaScript, React, Redux, and some other fundamentals, trying to cover as much ground as possible.
I expected there to be some stumbles along the way, but I didn’t expect it go as badly as it did. And by badly, I mean my opinion of my performance. The interview itself was an enlightening and informative experience (I mean, hey, I’m writing a whole blog post about it!). The technical assessment was a series of problems regarding two separate arrays of objects. The solutions required different functions to extract and/or manipulate certain pieces of data from one or both of those arrays. Simple enough, right? Sure! Except…I froze. These weren’t problems that were beyond my understanding or ability to solve, but the pressure of live-coding really took it’s toll. I wanted to make sure I was talking about my thought process aloud while attempting to solve, as nearly every source of advice I’ve received along that way had mentioned that one thing. But as I talked out loud, I started questioning everything I was saying. I started questioning my approach. I started questioning my code. I started questioning my ability. I got through the first two questions well enough, but the third question got a little messy, and by the time I got to the fourth, one of my interviewers was basically walking me through it. Again, not one that I wouldn’t ordinarily be able to solve, but of course now I was also hyper aware of the fact that I was being walked through it, which only added to my nerves.
I’m usually a pretty confident person and I love talking to people. Plus, my interviewers were incredibly nice and I’m so grateful for their patience and compassion in that situation, without which, I’m sure, would’ve made for a far worse experience. However, by the time we got to the question and answer round with no code, I was so discouraged I didn’t even feel like I could speak effectively (again, my perception of myself in the moment). When it was all over, I just wanted to go home and cry and sleep and cancel a call I had at 4:00. I got on the train, closed my eyes trying to keep my composure, and listened for my stop.
But about halfway through the train ride, when I was going over the Brooklyn Bridge, I decided I at least needed to talk to someone about this experience. I wanted to vent to a friend, someone who I already knew and trusted well enough to confide in on a personal level, but also someone who works in or at least in proximity to the tech industry. Someone who would *get it*. I was blanking until I remembered I knew someone from college working as an engineer in Charlotte (we initially just had mutual friends from school but started corresponding over the course of my career transition). I felt close enough to text her and in a stroke of luck, she responded that she was available right then. As soon as I got home I called her and explained what happened. She told me she actually didn’t think what I described sounded that bad, that she’d interviewed people who’ve done far worse, and lamented the excruciating process that is technical interviewing in general. So I felt a little better — I know I tend to have really high expectations/goals for myself and can tend to think I’ve failed something if I haven’t met EXACTLY those standards (which is not always an indication of failure). She gave me some great resources and also offered herself and one of her friends to potentially help me practice. After that, I felt a lot better and was in a much better state for the 4:00 call, which went great.
I was also really proud of myself for choosing to be proactive in this situation, rather than isolate. I wanted nothing more than to just hole up in my room and have a little pity party, thinking about all the ways I bombed that morning. But instead, I chose to get right back on the horse, view the morning as practice and a great learning experience, and explore options to get better for the next time. And hey, at least I had gotten my first technical interview out of the way — an accomplishment and immediate weight off my shoulders in and of itself!
I wanted to dedicate time over the weekend to focus on a function that was discussed at length toward the end of my interview: reduce. I’ve worked with reduce before, I mean Redux alone is essentially built off of reducers, but it had been a while. I realized I needed to revisit the basics of it, to really go back and explore what’s going on under the hood and in doing so, I was able to see with fresh eyes the real power of this function. It can do nearly anything! I read some documentation, watched a few YouTube videos (which I sometimes find more helpful), and decided to work on some sample problems specifically using reduce. I’ll leave you with some code I was playing around with (for simplicity, this is the second version with everyything in one .js file, as the first pulls in data from a .txt file), plus the final takeaway from that code (and a philosophy I live by):
Given the following array of strings:
technicalInterviews = [
"handling criticism 90 true feel good about",
"thinking out loud 45 true need to work on",
"object-oriented programming 85 true feel good about",
"functional programming 85 true feel good about",
"data structures 55 true need to work on",
"algorithms 50 true need to work on",
"javascript 80 true feel good about",
"ruby 80 true feel good about",
"communicating approach 55 true need to work on",
"passion, drive, and determination 95 true feel good about",
"react and redux 75 true need to work on",
"arrow functions and 'this' 70 true need to work on",
"syntax and semantics 65 true need to work on",
"high-level understanding 80 true feel good about",
"iteration and interpolation 75 true feel good about",
"using optimal functions 60 true need to work on",
"callbacks 65 true need to work on",
"open-mindedness 95 true feel good about",
"live-coding 50 true need to work on",
"eagerness to learn 100 false feel good about"
]
We’ll reduce it:
var prepAndPractice = technicalInterviews
.map(line => line.split(' ')).reduce((ability, line) => {
ability[line[3]] = ability[line[3]] || []
ability[line[3]].push({
skill: line[0],
proficiency: line[1],
canImproveUpon: line[2]
})
return ability
}, {})
var priority1 = prepAndPractice['need to work on']
var priority2 = prepAndPractice['feel good about']
console.log(`PRIORITY ONE (need to work on): ${priority1.length} things -- \n`, JSON.stringify(priority1, null, 2))
console.log(`PRIORITY TWO (feel good about): ${priority2.length} things -- \n`, JSON.stringify(priority2, null, 2))
And see in the console:
PRIORITY ONE (need to work on): 10 things --
[
{
"skill": "thinking out loud",
"proficiency": "45",
"canImproveUpon": "true"
},
{
"skill": "data structures",
"proficiency": "55",
"canImproveUpon": "true"
},
{
"skill": "algorithms",
"proficiency": "50",
"canImproveUpon": "true"
},
{
"skill": "communicating approach",
"proficiency": "55",
"canImproveUpon": "true"
},
{
"skill": "react and redux",
"proficiency": "75",
"canImproveUpon": "true"
},
{
"skill": "arrow functions and 'this'",
"proficiency": "70",
"canImproveUpon": "true"
},
{
"skill": "syntax and semantics",
"proficiency": "65",
"canImproveUpon": "true"
},
{
"skill": "using optimal functions",
"proficiency": "60",
"canImproveUpon": "true"
},
{
"skill": "callbacks",
"proficiency": "65",
"canImproveUpon": "true"
},
{
"skill": "live-coding",
"proficiency": "50",
"canImproveUpon": "true"
}
]
PRIORITY TWO (feel good about): 10 things --
[
{
"skill": "handling criticism",
"proficiency": "90",
"canImproveUpon": "true"
},
{
"skill": "object-oriented programming",
"proficiency": "85",
"canImproveUpon": "true"
},
{
"skill": "functional programming",
"proficiency": "85",
"canImproveUpon": "true"
},
{
"skill": "javascript",
"proficiency": "80",
"canImproveUpon": "true"
},
{
"skill": "ruby",
"proficiency": "80",
"canImproveUpon": "true"
},
{
"skill": "passion, drive, and determination",
"proficiency": "95",
"canImproveUpon": "true"
},
{
"skill": "high-level understanding",
"proficiency": "80",
"canImproveUpon": "true"
},
{
"skill": "iteration and interpolation",
"proficiency": "75",
"canImproveUpon": "true"
},
{
"skill": "open-mindedness",
"proficiency": "95",
"canImproveUpon": "true"
},
{
"skill": "eagerness to learn",
"proficiency": "100",
"canImproveUpon": "false"
}
]
*Not sure my appetite for learning can ever be satiated 😉🙃
NO MATTER HOW SKILLED YOU ARE, OR THINK YOU ARE, AT SOMETHING, YOU CAN ALWAYS IMPROVE.
BUT STICKING WITH IT IS KEY.
:max_bytes(150000):strip_icc()/1442501489740-58b8e7763df78c353c2556e2.jpeg)
H^2 