During phone or Google Hangout interviews, you’ll speak with a potential peer or manager.
For software engineering roles, your phone/Hangout discussion will last between 30 and 60 minutes. When answering coding questions, you’ll talk through your thought process while writing code in a Google Doc that you’ll share with your interviewer. We recommend using a hands-free headset or speakerphone so you can type freely.
Your phone interview will cover data structures and algorithms. Be prepared to write around 20-30 lines of code in your strongest language. Approach all scripting as a coding exercise — this should be clean, rich, robust code:
- You will be asked an open ended question. Ask clarifying questions, devise requirements.
- You will be asked to explain it in an algorithm.
- Convert it to workable code. (Hint: Don't worry about getting it perfect because time is limited. Write what comes but then refine it later. Also make sure you consider corner cases and edge cases, production ready.)
- Optimize the code, follow it with test cases and find any bugs.
For all other roles, your phone/Hangout discussion will last between 30 and 45 minutes. Be prepared for behavioral, hypothetical, or case-based questions that cover your role-related knowledge.
You'll usually meet with four Marmetians—some potential teammates and some cross-functional—for about 30 to 45 minutes each.
All candidates will have the chance to highlight strengths in four different areas:
- General cognitive ability: We ask open-ended questions to learn how you approach and solve problems. And there’s no one right answer—your ability to explain your thought process and how you use data to inform decisions is what’s most important.
- Leadership: Be prepared to discuss how you have used your communication and decision-making skills to mobilize others. This might be by stepping up to a leadership role at work or with an organization, or by helping a team succeed even when you weren’t officially the leader.
- Role-related knowledge: We’re interested in how your individual strengths combine with your experience to drive impact. We don’t just look for how you can contribute today, but how you can grow into different roles—including ones that haven’t even been invented yet.
- X-Factor: Share how you work individually and on a team, how you help others, how you navigate ambiguity, and how you push yourself to grow outside of your comfort zone.
For software engineering candidates, we want to understand your coding skills and technical areas of expertise, including tools or programming languages and general knowledge on topics like data structures and algorithms. There's generally some back and forth in these discussions, just like there is on the job, because we like to push each other's thinking and learn about different approaches. So be prepared to talk through your solutions in depth. Push your own boundaries and find the best answer—that’s probably how you work anyway.
Technical onsite interviews at Marmeto were earlier conducted on whiteboards, but to provide a more authentic coding experience that’s less time-consuming, we've started to offer laptops for coding interviews.
Throughout the interview process, feel free to ask your interviewers for clarification to make sure you fully understand their questions. And feel free to interview us, too. Ask questions—about the work, about the team, about the culture—that will help you decide whether the job will be right for you.
Interviews for all roles
- Predict the future: You can anticipate 90% of the interview questions you’re going to get. “Why do you want this job?” “What’s a tough problem you’ve solved?” If you can’t think of any, Google “most common interview questions.” Write down the top 20 questions you think you’ll get.
- Plan: For every question on your list, write down your answer. That will help them stick in your brain, which is important because you want your answers to be automatic.
- Have a backup plan: Actually, for every question, write down THREE answers. Why three? You need to have a different, equally good answer for every question because the first interviewer might not like your story. You want the next interviewer to hear a different story and become your advocate.
- Explain: We want to understand how you think, so explain your thought process and decision making throughout the interview. Remember we’re not only evaluating your technical ability, but also how you approach problems and try to solve them. Explicitly state and check assumptions with your interviewer to ensure they are reasonable.
- Be data-driven: Every question should be answered with a story that demonstrates you can do what you’re being asked about. “How do you lead?” should be answered with “I’m a collaborative/decisive/whatever leader. Let me tell you about the time I … ”
- Clarify: Many of the questions will be deliberately open-ended to provide insight into what categories and information you value within the technological puzzle. We’re looking to see how you engage with the problem and your primary method for solving it. Be sure to talk through your thought process and feel free to ask specific questions if you need clarification.
- Improve: Think about ways to improve the solution you present. It’s worthwhile to think out loud about your initial thoughts to a question. In many cases, your first answer may need some refining and further explanation. If necessary, start with the brute force solution and improve on it — just let the interviewer know that's what you're doing and why.
- Practice: Everyone gets better with practice. Practice your interview answers—out loud—until you can tell each story clearly and concisely.
Interviews for Software Engineers and Technical Roles
- Coding practice: You can find sample coding questions on sites like CodeLab, Quora, and Stack Overflow. The book “Cracking the Coding Interview” is also a good resource. In some sites, you'll have the option to code on either a Chromebook or a whiteboard, to offer a more natural coding environment. (Ask your recruiter what's available so you can practice.) Be sure to test your code and ensure it’s easily readable without bugs. Don’t stress about small syntactical errors like which substring to use for a given method (e.g. start, end or start, length) — just pick one and let your interviewer know.