Giving JavaScript Technical Interviews

As part of being a Hacker in Residence at Hack Reactor, a coding school/bootcamp, one my of roles is technical interviewing (Oh, joy. No, it’s actually AWESOME). Prospective students and applicants for Hack Reactor come to me potentially as their first point of contact and it’s my job to be friendly and positive while introducing them to the program. Of course, the main point of the job is assessing technical skill and communication. Because Hack Reactor curriculum’s focal point is interaction and pair programming, the ability to create rapport with me and any other interviewer as well as explaining complex thought processes demonstrates an applicant’s potential success in the program.

I can be a pretty nit-picky, overly analytical person at times. It’s one of my weaknesses that I openly admit. But for interviewing, this makes me not easily swayed and able to systematically and fairly judge a prospective student.

Can’t share, won’t share

Of course, you might be here somehow researching the Hack Reactor technical interview for insider tips, tricks, and content of the interview. No no no, that I can’t share. Sharing insights into the content or structure of the interview defeats the purpose and ruins the integrity of the screening itself.

Interviews are flawed

Yes, a lot of technical interviews in the software industry and other engineering industries are flawed. There’s been a rising outcry of explanations on how balancing a binary tree or creating an elevator in the object-oriented programming model isn’t indicative of how you’re going to build a consumer or user-facing web application. This, I get totally. It seems almost comical making me grin as I type it out.

These toy problems, whiteboarding, interview questions are questions to test your algorithmic thinking. Whether or not you can do them aren’t surefire indicators especially as you get more experienced.

Fundamentals, though

However, for JavaScript fundamentals and basic programming knowledge, what the Hack Reactor interview tests, is a pretty good example to use a conventional technical interview style. Giving prompts and problems of fundamentals ARE useful because developers are using the things we test for day-to-day.

Challenges

One of the personal challenges I face when interviewing is squirming in my seat when an applicant struggles (figuratively, I can’t imagine what I would look like if it was real). This is compounded when they become stone-faced and silent. Learning to not help is hard, especially since I have a background of teaching music (piano) and currently teach JavaScript. :(

Another challenge is staying engaged and excited to do the job. Consistently interviewing day-to-day (sometimes up to 3-4 a day) is draining. I have to constantly pep myself up, but I’m definitely improving and think to myself how I could best demonstrate the great community that Hack Reactor staff, students, and alumni are.

What I get out of this

Other than getting paid and having something to put on my resume with this technical interviewing position, I’m actually improving myself. Although giving interviews and taking interviews are quite different beasts entirely, being at this side of the table currently gives me an opportunity to see what a potential interviewer is looking for. I’m the type of analytical thinker that gets the problem solved but perhaps doesn’t give off the most glowing first impression. But knowing to develop that rapport and first impression with your interviewer makes me strive to improve.

I’ll be completing my residency at Hack Reactor in a few weeks. I hope that when I’m on the flip-side, job searching myself, I can be the candidate that I myself would hire!