Enthusiasm: They are excited to be there and they are excited to learn. They want to do good work and they are inquisitive and not afraid to attack a problem. When things get hard they keep pushing forward and asking questions trying to figure out the problem. This DOES NOT mean candidates need to code outside of work. What candidates do with their own time is none of my business I just want to see that when they come to work they are ready to go and put their best foot forward.
Ask Questions: Rather than simply accepting that it "just works" they want to know why and how it works. They ask questions like what is happening under the hood here? This is good, but could it be better? What performance implications does this block of code I just wrote have?
Interview Process:
We do one of the two depending on the experience. A junior who might have a little professional experience(0-1yr) or just overall seems more comfortable we will do an in-person coding challenge. Those fresh out of bootcamp we will give a take-home problem. Often we will ask what they want to do.
Takehome problem: We have a take-home problem which is a skeleton application and we ask the candidates to fill out the logic. We expect it to take candidates an hour or two. We then use this code when the candidate comes in for an in-person interview. We ask them to discuss their code, why they made certain decisions and how they might improve it.
In-person Coding: A small ruby skeleton application where we ask the candidates to fill out the logic of one method based on a set of tests written for that method. No tricks, no one line answers, the problem is literally from our codebase. We have pry(Ruby debugging tool) in the project and candidates are encouraged to use it or print statements for debugging. They are encouraged to talk through their solution and google whatever they need to. The idea is to get a feel for how they approach a problem, communicate, and work through issues and less about the actual solution.
Resume Chats/Culture Fit: We always do interview chats and culture fit sessions where we just chat about what is on the candidates resume, what makes them tick, and more importantly, get a feel for what THEY want out of the job. Fit is a two-way street and we want to make sure we meet all the candidate's needs.
Howdy, I'm Bryan and I’m a fullstack developer who loves to hack in Ruby on Rails and JavaScript. I love swing dancing 🕺🏽and DnD and anything nerdy. I am a true Blerd!
this is a great interview process! One of my favorite interviews I've done was when they were more interested about company culture fit before even getting into a coding interview
The Takehome problem approach should be the way to interview everybody IMHO. Ask candidates to solve a problem in a job ad, use that code to continue the interview process. Instead of the usual hr_phone_interview-meet_manager-meet_team-code_test-meet_Some_VP-get-offer way
I think that would work until someone posts the solution online and everyone is submitting the same code, effectively turning it into an unscreened interview.
Of course, the next step is to do an in person interview and drill the candidates on their work and choices they made. It's very difficult to get through the second stage when the first one was accomplished by cheating.
Interesting that just a few weeks ago we had this exact situation. A candidate was copy pasting blindly some SO code verbatim. Now days, it's easy and fast to find out where the code is copied from :)
Finally, change the test projects with each hiring session so that they sufficiently different.
@molly_struve
and @rommik
: Finally, I find others on DEV who do the same thing I've been doing for years: a take-home coding challenge, which is further discussed in the final interview.
@etampro
I don't know about other teams, but I keep an archive of all previous solutions, and also do web searches. I have spotted copy/paste answers before. In any case, such applicant always falls apart when the final interview comes around, because they don't actually know the code well enough to modify it live.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
What I look for in Junior Engineers
Interview Process:
We do one of the two depending on the experience. A junior who might have a little professional experience(0-1yr) or just overall seems more comfortable we will do an in-person coding challenge. Those fresh out of bootcamp we will give a take-home problem. Often we will ask what they want to do.
Resume Chats/Culture Fit: We always do interview chats and culture fit sessions where we just chat about what is on the candidates resume, what makes them tick, and more importantly, get a feel for what THEY want out of the job. Fit is a two-way street and we want to make sure we meet all the candidate's needs.
Thank you.
From someone who will have to interview in a few months for a junior role, this seems like the perfect situation.
this is a great interview process! One of my favorite interviews I've done was when they were more interested about company culture fit before even getting into a coding interview
The Takehome problem approach should be the way to interview everybody IMHO. Ask candidates to solve a problem in a job ad, use that code to continue the interview process. Instead of the usual hr_phone_interview-meet_manager-meet_team-code_test-meet_Some_VP-get-offer way
I think that would work until someone posts the solution online and everyone is submitting the same code, effectively turning it into an unscreened interview.
Of course, the next step is to do an in person interview and drill the candidates on their work and choices they made. It's very difficult to get through the second stage when the first one was accomplished by cheating.
Interesting that just a few weeks ago we had this exact situation. A candidate was copy pasting blindly some SO code verbatim. Now days, it's easy and fast to find out where the code is copied from :)
Finally, change the test projects with each hiring session so that they sufficiently different.
@molly_struve and @rommik : Finally, I find others on DEV who do the same thing I've been doing for years: a take-home coding challenge, which is further discussed in the final interview.
@etampro I don't know about other teams, but I keep an archive of all previous solutions, and also do web searches. I have spotted copy/paste answers before. In any case, such applicant always falls apart when the final interview comes around, because they don't actually know the code well enough to modify it live.