Hi ,
I'm a software engineer at Mojotech. It sounds like you might be a candidate for our (apprenticeship/internship) program after speaking with . I'd like to schedule an hour to interview with you.
Our interviews are a little different from what you may have experienced elsewhere. We're not going to do any coding exercises, algorithm theory, nor puzzles; so there is no need to worry about prepping for those. Instead, I'd like to spend the time learning about what you have worked on by reviewing some of your existing code with you. This would entail you sharing your screen with your preferred editor and guiding me through your code. I'll have questions about what your code does and why it does it that way.
I like to allow for 45 minutes for the code review and 15 minutes for any follow-up questions you may have for me. Let me know when you are available this week.
Regards, Introduction
I’ve been saying something along these lines at the start of the interview. I’m trying to clarify what I’m looking for right at the start.
We're going to be doing a code review. The goal is for you to explain the context and behavior of your application to me. I'm looking for you to help me comprehend your code base and your thought process arriving at this point, not judging your approach. I liken it to, we're not approaching the code base like an algorithms course would, looking for the big-o notation of an algorithm. Rather, we’re interested in what the algorithm does and, probably more importantly, why it does it. I'll have a lot of “what does this do?”, “can you tell me more about that?”, and “can we take a look at that method?”, kind of questions.
Pause here to see if they have any questions. If not, have the candidate start by sharing their screen and editor. Ask them to give you a high level context of what the application is, what the problem is and where you will be starting in the application.
Resist the urge to fix their code. This doesn’t really tell us anything about the candidate. If you see something like a race condition or a bug, pose the question for how they would handle the buggy scenario.
Follow along with the code. Ask them to stop and explain things you find interesting or confusing. See where they take you. Example, seeing a dbConnect parameterized query you can ask how that library works “is that string and value in an array a parameterized query?”. See if they identify the term and can make the leap to SQL escaping/SQL injection.
Joke, praise, have fun. This works best if the candidate is relaxed and is enjoying showing off their code.
Picking an arbitrary 1-5 scale here. We can adjust if we find we need more nuance when quantifying a category. General ranking is 1 - poor, 3 - average, 5 - exceptional with 2/4 for shades of gray in between.
Would you want to mentor/work with the candidate? Use this section as an overall rating of how well the candidate did and the following sections as the details.
- present (Something didn’t sit right with me)
- likeable
- technical (Seem like a nice person)
- articulate
- passionate (Please put them on my team yesterday)
What were you reviewing?
How well does the candidate communicate their understanding of the code to you.
- candidate either doesn’t understand their code or can’t explain what is happening beyond existing comments
- candidate explains their code well. Some prompting for technical jargon or clarification is necessary. Maybe some fumbling or examples of code copied from a tutorial or SO.
- candidate explains their code superbly. Knows where to look for any particular module/question. Libraries and examples are thoroughly understood before being added.
- going through the motions of a homework or coding camp assignment. No concern for quality or improvements
- decent size school or personal project. Notices areas of concern/improvement and desire to do so.
- Passion project that scratches an itch. Continuously improving and honing their skills.
- No interest in how the technologies/libraries in the project work
- Average understanding of the technologies used in the project.
- Deep understanding of the technologies used in the project and delving deeper into how their dependencies work or the possible alternatives to explore.
Need to consolidate these.
- Probably starting around mid-May, early June; let us know your availability and we'll have a more concrete start date later
- Usually goes until early/mid August; flexible
- Most folks usually work 9-5, but it's flexible; mostly concerned with getting work done
- Trust and trust-based time off
- Maybe check that they'll be local during that time; MT doesn't relocate interns
- Learn what it's like to be on a team of professional developers
- Give + get good code reviews
- Get proficient with git, and learn how to write reviewable code
- You'll get something to take away from the experience
- Open-source their project OR
- Do some paid work for a client OR
- Contribute to an open source project
- Space for personal/professional development
- Stipend for conferences + books + a great ebook library
- MojoTime
- Sane work hours
- Consultancy
- Work for hire; experts
- Regularly rotated onto different teams/roles
- Variation + new outlooks/perspectives
- Catered lunches Tues + Fri
- Downtown PVD; lots of food/drink options
- What do you know/what questions do you have about MT?
- What are your interests outside of coding?
- What are your short and log term goals?
- Is there any technology you really:
- Know?
- Love?
- Hate?
- Are confused by?