This mismatch isn’t accidental. Standardized coding challenges are easier to evaluate, scale, and compare across large candidate pools. Over time, they’ve become the default: reinforced by industry habits and preparation platforms. But convenience doesn’t equal effectiveness.
As engineering work has evolved, so has the need for more meaningful hiring practices. Companies are starting to question whether traditional interviews truly identify the developers who will perform well in real-world environments.
In this interview with Vic Fernandes, Technical Assessment Manager at Proxify, we explore why technical interviews still rely on outdated formats, where they fall short, and how companies can design more accurate, fair, and job-relevant assessment processes, drawing on real-world hiring insights from Proxify.
In your experience, why do so many technical interviews still focus on trivia or algorithm puzzles rather than real work?
If you’ve ever left a technical interview wondering why you were asked to reverse a binary tree or implement a graph traversal for a job that mostly involves building APIs or maintaining production systems, you’re not alone. Many engineers feel a disconnect between what they actually do at work and what they’re asked to do in interviews.
One of the main reasons is standardization. Algorithm problems are relatively easy to structure and evaluate. They usually have clear right-or-wrong answers, can be completed within a fixed time, and are easier to score consistently across many candidates. Real-world engineering tasks, by contrast, are more “messy”. There isn’t always a single correct solution, and evaluating them often requires judgment, context, and more time from senior engineers. For companies hiring at scale, especially those processing hundreds or thousands of applicants, standardized questions may feel safer and more manageable.
There is also a strong element of historical momentum. Large tech companies popularized algorithm-heavy interviews in the early 2000s, and many others followed their lead. Preparation platforms emerged to help candidates master those patterns. Over time, the format became the norm. Changing a hiring system that has become industry standard requires intention and effort, and many organizations simply stick in their “comfort zone”.
Designing better alternatives is more difficult than it sounds. Realistic exercises must be fair to candidates from different backgrounds, respectful of their time, and not overly dependent on a specific company’s internal stack. They must also be evaluated consistently. Creating that kind of process requires more effort, clearer rubrics, and stronger interviewer training. Not every organization is prepared to invest in that.
The good news is that change is happening. More companies are incorporating system design discussions, pair programming sessions, code reviews, and practical exercises that resemble real work.
At Proxify, we prioritize real-world skills, real-world problems, and bug fixes. We strive to constantly improve our processes, focused on the best candidate experience possible.
Can you give an example of a candidate who would likely fail a traditional interview but succeed on the job?
There’s a type of engineer who quietly builds the systems that keep companies running, and yet might struggle in a traditional technical interview.
Imagine a developer named Sofia.
Sofia has spent the past six years working on a large, production-grade backend system. She has improved database query performance, reduced incident frequency, cleaned up legacy code, and mentored junior teammates. When something breaks in production, she doesn’t panic. She gathers logs, isolates variables, forms hypotheses, and works methodically toward a fix. Her pull requests are thoughtful and well-structured. Her code is readable. Her documentation is clear.
Real engineering work is about navigating ambiguity, debugging complex systems, collaborating with teammates, managing trade-offs, and writing maintainable code that evolves over time.
Sofia excels at clarifying vague requirements. She asks good questions before jumping into implementation. She considers long-term maintainability. She thinks about edge cases that others overlook.
A fast, charismatic candidate may leave a strong emotional impression. But when you break down the session by competency, you might notice gaps in depth or correctness. Conversely, a quieter, more methodical candidate might not “wow” the room but demonstrate strong reasoning and sound engineering judgment across the board.
If Sofia is not that “wow” person, when exposed to a non-structured competency-oriented interview process, she might appear less confident simply because she is quieter. But in a collaborative, real-world environment, she is a reliable, detail-oriented, and steady contributor. Hiring will always involve human judgment. But the goal is not to eliminate judgment, it’s to structure it.
What are the biggest sources of false positives in technical interviews today?
A false positive in hiring means someone performs well during the interview process but later underperforms on the job. Overemployment has quietly become one of the biggest sources of false positives in technical interviews for software developers.
In most cases, you may end up hiring highly capable engineers; someone managing multiple jobs may struggle to sustain the level of engagement over time expected for a full-time position, but interviews rarely measure sustained execution.
The core issue is that traditional interviews assess peak performance in a controlled environment, whereas the job requires consistent contribution over time. Overemployment exploits that gap. Someone can demonstrate strong peak performance in interviews yet spread their attention thin across several roles afterward.
The hiring process rewards those who are best prepared for the interview format rather than those most likely to deliver focused, sustained impact. In the end, overemployment doesn’t break technical interviews on its own. It exposes a weakness and an ethical issue that was already there. It is important to double-check the candidate's background and previous work experience, the amount of time he worked at each of his previous companies, LinkedIn recommendations, and other signals that can help measure engagement history.
How do you design technical assessments that are genuinely job-relevant?
The first step is to reverse-engineer the role. Talk to the client and do great requirement gathering and align on expectations. Ask what the role will spend most of their time doing. Is it debugging legacy systems? Designing APIs? Reviewing pull requests? Writing frontend components? Optimizing database queries? Mentoring junior developers? Leading a complete team? The assessment should reflect those recurring tasks, not edge-case intellectual challenges that rarely occur in production.
Once you understand the job, design scenarios rather than abstract problems. For example, instead of asking someone to implement a complex algorithm from scratch, give them a small, realistic feature request. Instead of asking for a theoretical explanation of caching, present a system with performance issues and ask how they would investigate and improve it. Instead of testing knowledge of HTTP status codes, ask them to design an endpoint and justify their choices.
Context matters. Real engineering work is full of constraints: unclear requirements, partial information, and trade-offs between speed and maintainability. A good assessment introduces controlled ambiguity and evaluates how candidates navigate it. Do they ask clarifying questions? Do they state assumptions? Do they consider edge cases and long-term implications? These behaviors are strong predictors of real-world success.
It’s also important to simulate the working environment. If engineers use IDEs, documentation, and version control in their daily work, the assessment should allow those tools. Penalizing candidates for not memorizing syntax does not measure engineering ability; it measures recall. Allowing realistic tooling shifts the focus to logic, structure, and judgment.
Another key element is evaluating quality, not just correctness. A solution that “works” is not necessarily production-ready. Assess readability, naming clarity, modularity, error handling, and testability. Job-relevant assessments should reflect the fact that maintainable code matters as much as functional code.
How do you decide what level of difficulty is appropriate for an interview task?
Ideally, our tests include EASY, MEDIUM, and HARD questions. Now the question is how to determine the threshold for deciding the difficulty level of each task. And in order to do this, we use benchmarks based on a 90% passing rate and assigned as shown below:
Elementary - if 50% or more of the candidates score 90%
Easy: if 25% - 50% of candidates score 90%.
Medium: if 12.5% - 25% of candidates score 90%.
Hard: if 2.5% - 12.5% of candidates score 90%.
Very Hard - if 2.5% or less of candidates score 90%
Some easy tasks may seem hard to some candidates, and, conversely, some medium tasks may turn out easier than we predicted. That’s why, for Proxify, it's so important to review the pass rates of our tasks regularly and adjust their difficulty level if we deem it necessary.
How should interviews differ between junior, mid-level, and senior engineers?
Juniors are expected to solve all elementary and easy problems and eventually some Medium difficulty ones, where we can challenge them to see how far they can go.
Mid-levels are expected to solve all easy problems and most medium-difficulty ones, and we can challenge them to see how far they can go.
Seniors are expected to solve all easy and medium problems and most Hard problems, and we can challenge them to see how far they can go.
In all cases, we also evaluate other parameters, such as requirements understanding, level of handholding and AI support needed, speed and quality of the delivered code, ability to explain the delivered code, identify possible bottlenecks, and propose enhancements.
It is important to say that Proxify only targets senior professionals, connecting top-tier software, data, and AI professionals with long-term remote roles at serious companies. We handle the heavy lifting of connecting you to the right opportunities while you focus on the work, wherever you call home.
How do you evaluate a problem-solving approach without over-rewarding speed or syntax recall?
Technical interviews often claim to measure problem-solving ability. In practice, many end up measuring something else: speed, memorized patterns, or how quickly someone can recall syntax under pressure.
If the goal is to evaluate true problem-solving ability, the interview design needs to shift away from speed and recall, and toward reasoning and judgment.
A good starting point is to redefine what success looks like. If candidates believe they are being evaluated on how quickly they finish, they will optimize for speed. That often means skipping clarification, rushing through edge cases, and focusing on pattern recognition rather than understanding. Instead, explicitly state that clarity of thought matters more than speed. A simple statement such as “Take your time, I’m interested in how you think,” meaningfully changes the dynamic.
It’s also important to separate reasoning from syntax. In real-world development, engineers use documentation constantly. Forgetting the exact name of a method or a small language detail is not a performance issue — it’s normal. Allowing candidates to use Google and/or AI helps ensure you’re evaluating logical thinking rather than memory recall, especially if under pressure during a pair programming live session.
Another powerful signal is how a candidate handles ambiguity or feedback. Real engineering work involves evolving requirements and partial information. When given new constraints or gentle hints, does the candidate adapt thoughtfully? Do they revise their approach logically? The ability to iterate and refine often predicts job performance better than producing a fast initial answer.
Follow-up questions are equally important. Once a solution is proposed, explore its depth. Ask about time and space complexity. Ask how it would scale. Ask how it could be tested or refactored. These conversations reward conceptual understanding rather than memorized templates. They also reveal whether the candidate understands trade-offs — a core engineering skill.
Silence should not be mistaken for weakness. Some engineers think best when given a moment to reflect. Creating psychological safety — allowing pauses without pressure — often produces clearer reasoning and better outcomes. If necessary, gently remind candidates that thinking time is completely acceptable.
Scoring practices also matter. Instead of evaluating candidates with a vague “strong” or “weak” label, define specific competencies: problem decomposition, correctness, edge case awareness, communication clarity, adaptability, and code readability. Structured evaluation reduces the chance that a fast but shallow performance overshadows deeper competence.
At my work, we believe that most engineering roles are collaborative. Observing how a candidate engages in dialogue, responds to questions, and explains their thinking provides insight into how they would function on a team. Finishing quickly is rarely what makes someone effective in production environments. Clear reasoning, openness to feedback, and thoughtful trade-offs are far more predictive. In the end, the best interviews mirror real work. Real engineering is iterative, deliberate, and collaborative. It values clarity over haste and judgment over memorization. When interviews are designed to reward those qualities, they become far better predictors of long-term success.
What’s a better way to score interviews than “pass/fail” or gut feeling?
Every engineering role can be broken down into core competencies. For example, a backend developer role might require strong problem decomposition, technical correctness, edge-case awareness, system design reasoning, code quality, and clear communication. A senior role might add architectural trade-offs and a leadership signal. A junior role might emphasize learning ability and structured thinking.
To make this work, each competency should have clear behavioral anchors. What does “excellent” look like in problem decomposition? What does “needs improvement” look like in edge case handling? When interviewers score against defined standards instead of personal impressions, consistency improves dramatically.
Structured scoring also allows weighting. Not every competency matters equally across roles. For a systems architect, trade-off reasoning might carry more weight than raw coding speed. For an entry-level engineer, foundational logic and coachability may matter more than system scale experience. A thoughtful scoring model explicitly reflects these priorities.
What interview practices consistently introduce bias or noise into hiring decisions?
One major source of noise is unstructured interviewing. When interviewers “just have a chat” and decide based on general impressions, each candidate effectively receives a different evaluation. Different questions, depths, follow-ups, and standards lead to inconsistent signals. Two equally qualified candidates may be judged very differently simply because one interviewer prefers concise communicators while another prefers highly detailed explanations.
Whiteboard or live-coding interviews under intense time pressure create another distortion. They often prioritize stress performance over engineering quality. Some candidates think best when given quiet time and space to reflect. Others are naturally more comfortable performing in front of an audience. The format can amplify anxiety-related differences that have little correlation with actual job performance.
Inconsistent scoring rubrics introduce significant noise. If interviewers are not calibrated on what “strong,” “acceptable,” or “weak” performance looks like, ratings become subjective. One interviewer’s “solid pass” may be another’s “borderline.” Without shared standards and anchor examples, hiring decisions become highly sensitive to which interviewers are assigned.
Halo and horn effects are also common. A strong first impression, such as graduating from a prestigious university or working at a well-known company, can positively bias subsequent evaluation. Conversely, a small mistake early in the interview can unfairly overshadow otherwise strong performance. Once an interviewer forms an initial opinion, confirmation bias can cause them to selectively interpret later responses to support that view.
Overemphasis on pedigree introduces structural bias. Filtering candidates heavily based on brand-name companies, elite schools, or specific past employers narrows the pool in ways that correlate with socioeconomic background and access to opportunity. It may exclude capable candidates who took less conventional paths but developed equivalent skills.
Even logistical factors can introduce bias. Interviewing late in the day, when interviewers are tired, can lead to harsher evaluations. Candidates interviewed after an exceptionally strong or weak applicant may be judged relative to that previous person rather than against a fixed standard. These contextual effects are subtle but real.
Reducing bias does not require removing human judgment. It requires channeling it. Structured interviews, predefined competencies, consistent scoring rubrics, independent written evaluations before group discussion, and diverse interviewer panels all help. The goal is not perfection but consistency and fairness.
At Proxify, we provide ongoing guidelines and training for our interviewing team to identify and reduce bias. We acknowledge the issue as a natural collateral effect of the process and hold team meetings to raise awareness, promote accountability, and decide on actions to reduce its impacts.
How can interviewers reduce the impact of nerves, communication style, or cultural differences on outcomes?
Every interview should start with an icebreaker moment. Interviewers should be polite and friendly yet sound professional. It's all about building psychological safety into the tone of the conversation. Small behaviors matter: smiling, active listening, acknowledging good reasoning, and reframing mistakes as exploration rather than failure.
First, the structure of the interview should be clear and transparent. When candidates know what to expect — the format, timing, evaluation criteria, and goals — anxiety decreases significantly. A brief upfront explanation like, “We’ll spend 10 minutes understanding your background, 30 minutes on a technical problem, and 10 minutes on follow-ups” helps create psychological safety. Uncertainty amplifies nerves; clarity reduces them.
Second, normalize thinking time. Many candidates feel pressured to respond instantly. Explicitly saying, “Feel free to take a minute to think — that’s completely fine,” can dramatically change performance quality. Real engineering work involves reflection. Interviews should allow it. Silence should not be interpreted as weakness.
Third, separate communication polish from technical depth. Some candidates speak confidently but superficially. Others communicate more quietly but demonstrate deeper reasoning. Interviewers should anchor their evaluation in substance: clarity of thought, correctness of reasoning, ability to adapt — not charisma or speed of speech. It helps to take structured notes on competencies rather than impressions.
Fourth, ask consistent, job-relevant questions. Unstructured interviews increase the chance that conversational flow, humor, or shared background influences the outcome. When every candidate is evaluated against the same predefined criteria, cultural style differences have less room to distort results.
Fifth, train interviewers on bias awareness. Many people unconsciously equate confidence with competence. Recognizing this pattern helps interviewers consciously correct for it. Confidence is style. Competence is capability. They do not always correlate.
In the end, the goal of an interview is not to see who performs best under artificial pressure. It is to predict who will perform well on the job. The more the process reduces noise from nerves, style differences, and cultural mismatches, the closer it gets to measuring what actually matters: problem-solving ability, judgment, collaboration, and growth potential.
At Proxify, we believe interviews should be challenging yet respectful. Candidates who feel safe think more clearly and perform closer to their true ability.
At Proxify, we do not have short-term projects; we have career paths with clients seeking to integrate our tech experts as an essential part of their team. That being said, our most important metrics are churn-related. In the case of technical assessment, our most important churn-related metric is churn due to “low member performance”, which is further broken down into recurring reason types and sub-reasons.
One of the most frequent sub-reasons is “Low quality deliverables”, which typically includes: Code not aligned with requirements, Senior-level expectations not met, QA or automation gaps, Decline in quality over time.
It is also important to constantly follow up on NPS and gather candidates' experience feedback through surveys and open channels. Reading and caring for what the candidates have to say takes a lot of time and energy, but improvement will come only if you properly investigate and take action to tune your process, considering their feedback.
At our company, the longer the Devs stay working and living up to the client's expectation the better. This means we did a good job not only assessing the candidate's seniority but also gathering the client's requirements and matching the client with the best candidate possible. We need to make sure we put the right people in the right place, and this means great sourcing, screening, and technical interviews, but also great requirement gathering, shorlisting and match meeting/interviews.
If you could redesign a company’s technical interview process from scratch, what’s the first thing you’d change?
In modern software development, engineers don’t code from memory on a blank surface under pressure. They use editors, documentation, search engines, AI, debuggers, and tests. They collaborate. They ask clarifying questions. They iterate. They refactor. They experiment.
So, if your interview is not designed to allow for such things, it does not correlate to real-world environments and most probably cannot predict a candidate's quality. We should stop treating interviews as isolated performance tests and start treating them as structured simulations of the actual job.
Interviews should aim to predict job performance, not test how well someone performs in an artificial performance setting. The more an interview resembles real engineering, the more meaningful its signal becomes.
Most technical interviews are designed for ease of evaluation, not job realism. They prioritize speed, pattern recognition, and standardized puzzles because those are easy to administer and compare. But the core question we’re trying to answer isn’t “Who performs best in a timed problem-solving contest?” It’s “Who will consistently perform well on this team, in this environment, over time?”
Perhaps most importantly, I would shift the mindset from interrogation to collaboration. Real engineering is collaborative. Strong developers ask clarifying questions. They iterate. They incorporate feedback. An adversarial interview suppresses these behaviors. An interview that feels like working through a problem together reveals them.
Conclusion
Technical interviews shouldn’t be performance theater. They should be reliable predictors of how someone will think, collaborate, and deliver over time.
The shift is already underway. More companies are moving away from trivia and toward realistic, scenario-based assessments that reflect actual engineering work. But meaningful change requires intention: clearer role definition, structured evaluation, better interviewer training, and a commitment to candidate experience.
We believe the best hiring processes mirror real-world environments. They prioritize reasoning over recall, consistency over peak performance, and long-term impact over short-term impressions. When interviews are designed this way, they don’t just filter candidates — they identify the engineers who will truly thrive.
Because in the end, great hiring isn’t about finding the fastest problem-solver in the room. It’s about finding the right engineer for the work that actually needs to be done.
