In the competitive landscape of engineering talent acquisition, the interview process stands as a critical juncture where decisions made by both employers and potential employees can have far-reaching implications. However, navigating this process is often fraught with challenges, leading many organizations to inadvertently undermine their efforts to secure the best candidates. Drawing on my experience of over 13 years of interviewing and being interviewed by a wide range of companies, from small-scale startups to large organizations, this article delves into prevalent missteps in interviewing engineers and proposes strategies for refinement. The insights and examples shared here are distilled from a career spent on both sides of the interview table, offering a unique perspective on how to enhance the efficiency and effectiveness of the engineering interview process.
The Pitfalls of Engineering Interviews💥:
1. Lack of Interviewer Training📚:
Untrained interviewers can struggle to evaluate candidates effectively, often leading to a focus on irrelevant criteria. Organizations must invest in comprehensive interviewer training, emphasizing technical assessments, soft skills evaluation, and creating a positive candidate experience. A common pitfall is when interviewers, lacking proper training, press candidates on highly specific or outdated technical details, which can lead to unnecessary stress and a misrepresentation of the candidate’s actual skills.
Example:
Interviewer: “Do you know how continuation works in Kotlin suspend functions?”
Candidate: “I think it should be some sort of suspending at some point and continue/resuming later, but it’s been some time since I read this thoroughly when suspend functions were introduced.”
Interviewer (in a more stressed tone): Asks deeper questions around continuation.
Candidate: “I’m not sure as it’s been some time since I looked into that, but I am working with suspend functions every day.”
Interviewer: “But, …,” and asks even deeper questions around the first question.
This scenario highlights the need for interviewers to be trained not only in the technical aspects of the roles they are hiring for but also in effective communication techniques. It’s essential to recognize when to probe further and when to move on to different topics that may better showcase the candidate’s strengths and current expertise. Focusing on overly specific or advanced technical minutiae, especially in a manner that increases pressure on the candidate, can lead to a poor assessment of the candidate’s overall abilities and negatively impact the interview experience.
2. No Clear Agenda📋:
Without a structured interview format, sessions can become disorganized, failing to cover essential topics. Implementing a clear agenda ensures that all relevant areas are addressed systematically, preventing the interview from devolving into a series of unstructured, “wing-it” questions that can confuse candidates and fail to accurately assess their skills and fit for the role.
Example:
Interviewer: “So what can you tell us? What do you know?”
Candidate: (A bit confused about what the question is asking) “Can you please elaborate a bit more?”
Interviewer: “Yeah, like, I mean, (silence), what is your tech stack, what do you think about the current state of Android?”
Candidate: Explains his recent tech stack.
Interviewer: Continues with more “wing-it” questions…
The interviewer’s vague initial question and subsequent lack of focus can lead to confusion and prevent a meaningful assessment of the candidate’s experience and viewpoints. By contrast, a structured interview with prepared questions tailored to the role ensures a productive dialogue that accurately gauges the candidate’s qualifications and potential fit with the organization.
3. Improper Introductions👋:
The absence of proper introductions can make the interview feel impersonal and stressful. Initiating the interview with a brief introductory phase can significantly set a welcoming tone, fostering a connection from the outset. Asking ice-breaking questions, such as where the interviewee is based, can create a bond and reduce the stress on both sides, making for a more relaxed and productive conversation. These initial moments are crucial for building rapport and setting the stage for a positive interview experience, rather than rushing straight into the technical aspects.
Example:
(Candidate joins the meeting 1 minute earlier)
Interviewer: “Oh hi, let’s get started. Can you please share your screen?”
Candidate: “Yeah sure.” (While thinking, “Who are they? What do they do?”)
This example highlights the awkwardness and confusion that can arise from diving straight into the technical part of the interview without proper introductions. It’s essential for interviewers to introduce themselves, outline the interview process, and briefly describe the role and company. This not only puts the candidate at ease but also promotes a more engaging and productive interview environment.
4. Inadequate Assessment Methods:
Relying on subjective evaluations or irrelevant questions can skew the assessment of a candidate’s suitability. Adopting structured interviews and practical coding tests can offer more objective insights into a candidate’s capabilities.
Example:
Interviewer: “So let’s do some self-assessment!”
2 other interviewers: (Silent, but look very confused)
Candidate: With a confused tone, “Alright, what do you want me to do?”
Interviewer: “So how do you assess your Kotlin knowledge proficiency from 1–10?”
Candidate: “I have been working with Kotlin every day since 2016. Usually, try to keep myself updated with recent changes and trends. I have used it in many projects, so maybe a 9 out of 10?”
Interviewer: (Starts staring at the screen for a while, looks like he is Googling “Hard Kotlin interview questions”) “OK, can you tell me what [very deep concept in Kotlin underlying mechanism that has nothing to do with daily Android Development] does? Explain how it works.”
Candidate: (Thinking, “Oh boy, I should have said a 1 out of 10”), “I think that concept is related to… which I work with every day, but I don’t have all the literature with me now.”
This scenario underscores the issues with subjective self-assessment prompts and diving into overly technical or niche questions that do not align with the candidate’s day-to-day responsibilities. Such approaches can lead to misjudgments about a candidate’s real-world capabilities and create unnecessary stress during the interview. A more structured method, focusing on practical skills and relevant project experiences, would provide a clearer, more accurate picture of the candidate’s proficiency and how they might perform in the role.
5. Irrelevant and Product-Specific Questions:
Questions that delve into highly specific product knowledge or expect candidates to guess proprietary solutions are counterproductive. Instead, focusing on fundamental skills and problem-solving abilities is more indicative of a candidate’s potential contribution.
Example:
Interviewer: “We want you to write a code that refreshes this list every X second, you can use RxJava or Kotlin Flows.”
Candidate: “It’s been some time since I’ve worked with RxJava. I know I can do an ‘interval()’ function and get a callback every X second. I could also do a ‘postDelayed()’ on a ‘Handler’. I have also recently read on Android Documentations about using ‘while(true)’ with Flows at Android Developer Documentation. I remember reading this article on Medium around this topic but don’t have the syntax with me. I’ll start with the flow solution.”
Interviewer: (Silence)
Candidate: Implements what he has read on Android’s official documentation, runs the app. It works, but the interval is sometimes not equal to X seconds due to the collector not consuming it at the same rate.
Interviewer: (Silence) and after a few seconds: “As you can see it’s not working properly, fix it!”
Candidate: “Yeah, I thought so too. I need to Google and R&D around this a bit to come up with some buffering mechanism or something.”
Interviewers: “You can only open Android official documents!”
in this scenario, a great chance for hints was missed. The question posed was a use case specific to the product, likely requiring extensive collaborative effort among engineers to devise an optimal solution. Expecting a candidate to deliver a flawless solution on the spot, within a constrained timeframe, and with limited resources, is not only unrealistic but also overlooks the collaborative and iterative nature of engineering work.
A more effective approach would involve offering hints or guiding questions that steer the candidate toward potential solutions, reflecting the collaborative problem-solving process typical in real-world scenarios. This not only aids in evaluating the candidate’s problem-solving approach and adaptability but also simulates the supportive environment they would experience as part of the team. Expecting instant perfection under pressure fails to acknowledge the complexity of the work and the value of a thought-out, researched solution.
6. Negative Interviewer Attitudes:
Interviewers who express dissatisfaction with their organization or display sarcasm towards certain technologies can deter talented candidates. Maintaining professionalism and demonstrating respect for all technologies and methodologies are crucial.
Example:
Interviewer: (While discussing the role and company) “Honestly, the organization’s direction has been a bit chaotic lately, and the workload can be pretty hectic and disorganized.”
This kind of comment can significantly impact a candidate’s perception of the company and their interest in the position. While transparency is important, focusing on negative aspects without providing a balanced view of the challenges and opportunities within the organization can discourage candidates from pursuing the opportunity further. It’s crucial for interviewers to communicate potential challenges in a constructive manner, emphasizing the support and growth opportunities available to employees, rather than leaving candidates with a solely negative impression.
7. Interviewer Silence During Collaborative Tasks:
Complete silence from the interviewer, especially during live coding tasks, fails to simulate the collaborative nature of real-world engineering work. Encouraging interaction and feedback during these exercises can provide a more realistic assessment of a candidate’s abilities.
Example:
Candidate: (Shares his screen for a live coding task and starts coding while explaining his thought process) “So now, I’m implementing this feature using a standard approach that should handle our requirements efficiently.”
Interviewers: (Complete silence)
Candidate: “Excuse me, are you there? I cannot see you while I am sharing my screen.”
Interviewers: “Yeah, we’re here.”
(After a few more minutes of silence from the interviewers)
Candidate: “Excuse me, are you still there?”
This scenario underscores the discomfort and confusion that can arise from a lack of feedback or signs of engagement from the interviewer(s) during a task that is inherently collaborative. Such silence can make candidates question whether their explanations are clear or if they are even on the right track, adding unnecessary stress to the situation. It’s crucial for interviewers to remain verbally engaged during live coding exercises, providing feedback, asking clarifying questions, or even just acknowledging the candidate’s explanations. This not only aids in evaluating the candidate’s communication and technical skills but also creates a more interactive and less stressful interview environment.
Jobs
8. Lack of Communication on Live Coding Expectations:
Failing to communicate the specifics of live coding tasks can disadvantage candidates, especially those proficient in modern frameworks but expected to work with legacy code. Transparent communication about the coding environment and expected tasks allows candidates to prepare and showcase their skills more effectively.
Example:
Recruiter: “You will have a live coding interview with our Android Engineers.”
Live coding task: “Improve the existing code and suggest performance improvements on this legacy code.”
Candidate: “It’s been a while since I have worked with XML views and RecyclerView adapters. I have been using Jetpack Compose every day for the last year, and I will do my best to remember what I knew before.”
Interviewers: (Not making any comments)
Candidate: “OK, I remember calling ‘notifyDataSetChanged()’ is a bad practice. We can use ‘notifyItemRangeChanged()’ here.”
Interviewers: (Silence)
Candidate: (While not 100% sure if it is what they want) “I think we could also refactor from using RecyclerView.Adapter to ListAdapter.”
Interviewers: (More silence)
This scenario highlights the misalignment between the candidate’s recent experience and the expectations set for the live coding task. As development practices evolve, such as the pivot towards Jetpack Compose in Android development, it becomes increasingly important for recruiters to align with engineers to set clear expectations for candidates. This alignment ensures that candidates can adequately prepare for and demonstrate their capabilities in the context of the interview, rather than being caught off guard by outdated or irrelevant requirements. Providing candidates with a clear understanding of the technologies and methodologies they will be expected to work with during the live coding session can lead to a more accurate assessment of their current skills and how they might apply to the role in question.
9. Ensuring Code Review Post-Interview:
It’s vital that the code produced during live coding sessions is preserved and reviewed by the interviewing team. This practice allows for a more detailed internal discussion, avoiding potential biases and ensuring a fair evaluation process.
Example:
After a challenging live coding interview:
Interviewers: “The time is up. Thank you for this session, and we wish you luck.”
Candidate: “Thanks for having me. Bye.”
Candidate (after the interview): “Wait, they didn’t ask me to commit the code somewhere or send them the project source code.”
Candidate (thinking more): “The result looks quite satisfying. Although I did not get much feedback or hints, I think I did a good job. Maybe they were already satisfied, so they did not bother asking for the code.”
The day after:
Recruiter: “We’re sorry, the technical interview did not go well…”
This scenario highlights a missed opportunity for both the candidate and the interviewing team. Having the candidate’s work stored and accessible for a detailed review can help overcome potential biases and allow the technical team to assess the work more thoroughly. Furthermore, it provides a tangible record that can be referenced in internal discussions, ensuring that the evaluation is based on the candidate’s actual performance rather than on immediate impressions or incomplete recollections. This practice not only supports a fairer assessment process but also enables candidates to understand how their work was evaluated, which can be invaluable for feedback and growth.
10. Permitting the Use of Resources During Interviews:
Expecting interviewees, especially at senior levels, to recall every detail without the opportunity to look up information is unrealistic and does not reflect real-world working conditions. Permitting the use of resources like Google during interviews can provide a more accurate assessment of how a candidate solves problems and learns on the job.
Example:
Candidate: “I know how to collect from a flow in a Fragment. They have this not-so-easy-to-remember syntax, something like ‘repeatOnLifecycle’ function. I have this nice extension function with the help of Kotlin’s Context Receivers to collect from flows, but I don’t remember what it was right now. Can I quickly Google for it?”
Interviewers: “Yes, you can only open Android Developers’ official documentation.”
Candidate: (Googles how to collect flow from Fragment, the first record is the medium.com article from Googlers that describes this
repeatOnLifecycleAPI, but he’s not allowed to open that. The second result, Google’s official documentation at https://developer.android.com/kotlin/flow, unfortunately, has nothing about collecting there.)Interviewers: (Silence)
This scenario highlights the limitations of restricting candidates to specific resources during the interview process. While the intention might be to focus on official documentation, it can inadvertently hinder the candidate’s ability to demonstrate their problem-solving skills effectively. Allowing candidates to use all available resources, including articles, forums, and documentation, can provide a more comprehensive view of their capabilities. Moreover, this is an ideal moment for interviewers to offer hints or guide the candidate towards the solution, emphasizing the collaborative nature of problem-solving in real-world settings.
Strategies for Improvement ✅:
Training and Preparation:
Equip interviewers with the skills to conduct effective, respectful interviews. This includes training on technical evaluations, communication techniques, and fostering a positive interview environment.
Structured Interview Process:
Develop a clear, consistent interview format that includes time for introductions, technical assessments, and candidate questions. This structure ensures comprehensive evaluations and respects the candidate’s time.
Focus on Collaboration:
Incorporate interactive elements into the interview process, such as pair programming or problem-solving discussions, to assess candidates’ teamwork and communication skills realistically.
Constructive Dialogue:
Encourage interviewers to engage in open, respectful discussions about technology choices and problem-solving approaches. This not only assesses the candidate’s technical knowledge but also their ability to contribute to technical discussions and decision-making processes.
Clear Communication on Live Coding:
Ensure candidates are informed about the nature of live coding challenges they will face, including the technologies and frameworks that will be used. This allows candidates to adequately prepare and ensures that they can demonstrate their skills and adaptability effectively.
Feedback and Adaptation:
Implement a feedback loop where interviewers and candidates can provide post-interview insights. This feedback can be invaluable in refining the interview process and ensuring it remains effective and respectful of candidates’ diverse experiences.
Conclusion 🎯
The engineering interview process is ripe for innovation. By recognizing and addressing the aforementioned pitfalls, organizations can enhance their ability to attract and evaluate top engineering talent effectively. Embracing a culture of respect, open-mindedness, and continuous improvement in interviewing practices is not just beneficial for securing the best candidates; it also reflects positively on the organization’s brand and workplace culture. As the tech industry continues to evolve, so too should the methods we use to identify and welcome the architects of tomorrow’s innovations.
Now, I’d love to hear from you. Whether you’ve been on the interviewing side of the table, the candidate’s side, or both, your experiences are invaluable. What has been your experience with engineering interviews? Have you encountered similar pitfalls, or do you have additional insights to share? How do you envision the future of the engineering interview process?
Please feel free to leave your comments and thoughts below. Your feedback not only enriches this discussion but also helps in shaping a more effective and inclusive approach to engineering interviews.
This is previously published on proandroiddev.com
