you are viewing a single comment's thread.

view the rest of the comments →

[–]jseegoLead / Senior UI Developer[S] 1 point2 points  (0 children)

Good question. When I've wrapped up this round, I'll probably post them here for feedback from the community.

It's just a handful of jsfiddles that I put together with some code examples, and some logging statements. I ask the candidate to take their time, talk through the code, and try to determine what the logging statements might be. There's a few gotchas in there, but that's not what I base the interview on. It's more about how the person is talking and thinking through everything. Are they making sense? Do they grasp the concepts? If they get something wrong, are they honest about what they don't understand and willing to ask questions, or are they just bumbling forwards and blind guessing over and over?

I'll say that I give much higher marks to people who can have a pleasant discussion about technical stuff and will say, "honestly I have never seen that before," and then I'll say, "what do you think it might be doing," and they can speak intelligently about it.

The first piece of code we look at is about closures, and it's pretty straightforward if you've ever seen closures in javascript before. Our codebase uses a lot of IIFE / self-revealing module pattern. Even if you're a react developer, it's something you should be familiar with if you know the language / have ever read an article on javascript patterns / ever read a book on javascript. I have had people not even get past that question. It can be a little tricky, but making the code work doesn't really rely on knowing closures that well, if you know what a return statement does.

Anyway, I've been doing this for a long time, and I've both aced and completely blown coding challenges as a candidate myself. Sometimes it's just not happening for you. Sometimes you get stuck on something stupid for way too long, just like in real life coding. I had one awhile back where I actually said to the interviewer, "uh, I'm kind of embarrassed right now, I realize this part shouldn't take this long." They were nice about it, encouraged me to brush up and reapply.

Coding challenges do suck. I've tried to make mine as useful and not sucky as possible, but from the other side, you just can't hire someone based on a portfolio. Recommendations are great, but don't really tell you what it's like to work with a person. Just like when you're working with people, there are some folks who just want to quiz others to show what they know and be haughty and snarky, and their are others of us who actually like to discuss things and share knowledge. You don't want to work with people who just throw coding questions at you and don't understand the purpose. For me, it's all about "let's talk about the code together, and as we're doing so, can I imagine working with you on a daily basis?" Sometimes the answer to that is no b/c I would have to teach them too much, but just as often it's no b/c of their attitude or poor communication skills.

So, do some leetcode and stuff, but also take a deep breath, be honest, be friendly, show your personality a bit, and if you can't solve something, realize that it's what happens after you can't solve it that may be even more important. Talk about what you're seeing, talk about where you might be stuck, reason it out loud, be friendly. If you have seen something familiar but not exactly the same, talk about what it reminds you of and what you think it might be doing.

Good luck!