Have you ever joined a development team that was a team in name only? Torn apart by internal conflicts, petty quarrels, clashing egos, and office politics? Or perhaps you’ve seen a seemingly perfect candidate join a well-organized team, only to fail to integrate and quickly leave? Finding and recruiting exceptional developers who align with your culture is hard.
The mobile development landscape has transformed dramatically in recent years. With remote work and distributed teams becoming the new norm, hiring the right candidates is more crucial than ever. Addressing cultural misalignments proves far more challenging than helping new hires enhance their technical skills. In fact, today’s iOS development teams need people who showcase strong work ethic and adaptability even more than those who can write clean, maintainable code from day one. Attitude over aptitude.
This post will challenge some common recruitment practices while offering practical alternatives that have consistently delivered results in my experience. Let’s dive into what really matters when building high-performing iOS development teams.
Work ethics beats talent every time.
The harsh reality: Most developers spend little time outside of work honing their skills. On the job, they effectively stop learning after 1-3 years. Everything afterward is just practicing skills they’ve already acquired. Unless absolutely necessary, these developers rarely step out of their comfort zone to learn a new language, experiment with different frameworks, or otherwise expand their knowledge. One might assume that in the fast-paced mobile app development world, such stagnation would be impossible. Yet surprisingly, some projects still rely solely on low-level Objective-C for UI development – not because better alternatives don’t exist, but because teams simply choose to “leave things as they are as long as they work”.
What does this mean for you as a person looking to expand your iOS team? Quite simply: you need to hire for attitude, not aptitude. No matter the candidate’s current level or intellectual capacity – with the right work ethic, they can catch up to more experienced colleagues in no time.
Don’t believe me? It’s pure math. Take Kobe Bryant, known for his legendary work ethic. He would start training at 4:00 AM to fit in 4-6 hours before team practice. This put him years ahead of the average NBA player in practiced skills. Often, he would stay after team practice or games to perfect moves he considered flawed. Through this dedication, he accomplished in one year what took other players 18 months. These efforts compounded over time, leading to 5 NBA championships, an MVP award, and 2 NBA Finals MVP awards. The “Mamba Mentality” at its finest.
How can you recognize people with such a mentality? Well, it’s simple but not easy – primarily because there are so few of them… First of all, look for the craftsmen – the developers showing this level of commitment, passion, and devotion to the craft.
In particular, you can look for:
- Open source contributions:
We learn in proportion to the valuable feedback we receive. The best way to get such feedback is to put your work out there for the community to see and evaluate. It’s surprising when a candidate for a senior position doesn’t have any tools, libraries, or even pet projects on their GitHub profile. While I wouldn’t call it a red flag, it reveals much about their willingness to go the extra mile. Take note of the additional effort candidates put into managing their projects – adding comments, unit tests, guidelines, and helping users with issues they encounter. - Actively sharing knowledge:
Teaching others is one of the best ways to learn new things while improving communication skills and patience. Look for candidate’s blog posts and articles, including those on company blogs and websites. Pick their most interesting piece and ask thoughtful questions about it. Try challenging their viewpoint a little and observe how they respond. Furthermore, it’s a strong positive sign when candidates engage in charity or community work. Look for mentoring activities, organizing local meetups, managing developer community Slack channels, or speaking at conferences and meetups. - Completed certifications:
Some developers frown on certificates, believing more in practical skills. I can’t agree more. Hard skills beat “paper” every time. But should we really automatically disregard the work (and money) someone put into obtaining certifications? Especially given that only a few companies actively invest in their employees’ growth? In my view, especially valuable are certifications obtained in preparation for changing positions within a company. This implies that a candidate didn’t just expect to “learn on the job,” but actively sought knowledge before being promoted. Even better if the candidate continued to pursue their quest for knowledge after securing the “dream position.” That demonstrates commitment to continuous learning – a must-have in my book.
That all sounds great, but what if I can’t afford to wait until a candidate develops the level of skills needed for the position? Here’s the reality: you’ll rarely have enough time to find a “perfect” candidate. More likely, you’ll need to guide and onboard someone into the role. This is where work ethic becomes crucial. If a candidate has shown willingness to go the extra mile in the past, they’ll likely do it again, dramatically accelerating the onboarding process.
Culture fit is non-negotiable
Picture yourself working at a dynamic startup. One day you’re asked to build a backend microservice, the next you’re diving into the mobile app. Such environments prioritize flexibility, versatility, and (above all) rapid delivery. However, if you’re passionate about code quality and craftsmanship, this setting might not be ideal. Your dedication to excellence may not receive the recognition it deserves.
On the flip side, imagine you have only startup experience and are about to join a team of software craftsmen. These developers value code quality, testability, and minimizing technical debt. From day one, you’d likely face thorough code reviews and a steep learning curve. It’s unlikely you’d be asked to switch between different development languages. Even though your colleagues would surely be helpful and willing to show you the ropes, you might feel out of your depth. Even if you’d learn a lot, would this be the right place for you?
Beyond company type, consider your preferred work and communication style. Do you like to set your Slack status to “busy” and focus deeply on your tasks? Do you set aside specific blocks of time for responding to messages and being “available for consultation”? If so, a fast-paced software house might not be your best fit. These environments require quick responsiveness to client questions, where maintaining client relationships is just as crucial as delivering value.
What about your preferred project length? Do you usually work on longer-term projects, or do you thrive on switching between different challenges to keep learning new things? Maybe you’re more suited to quickly launching MVPs but prefer to hand over the post-MVP phase? Or perhaps you enjoy being a “firefighter”, tackling troubled projects full of regressions and technical debt? Believe it or not, some people actually enjoy this role…
I could go on like this for a while. The bottom line is this: every team, project, and company has its own valued skillset, preferred personality types, and communication styles. Before even putting out a job advertisement, you need to define these and write them down. Make sure to consult your team about the values the new hire should represent. Try figuring out how you can find “evidence” supporting that a candidate embodies these traits. Usually, a candidate’s professional track record should be enough to tell if they are a good fit. If you feel overwhelmed by the sheer amount of soft skills to look out for, take it easy. The good news is that during face-to-face interviews, you can usually tell very quickly if a candidate has “chemistry” with the team. All the techniques I provided in this blog post aim to filter out candidates who obviously are not a fit.
Finally, a company’s mission and values can be a powerful differentiator. If your company genuinely aims for societal betterment – like fighting famine and poverty – it can attract exceptional talent. Don’t believe me? Beyond a certain level, money and benefits become mere hygiene factors. Truly remarkable developers often willingly accept lower compensation to work on projects that “make a difference.” I’ve personally reduced my financial expectations twice to work for organizations whose missions resonated with me. Make sure to highlight your company’s mission in job postings, and you’ll be amazed at the results. There’s just caveat – the mission must align with the company’s actions. 😉
Ask smart (not hard) questions
Let’s be honest – it’s very easy to prepare a list of challenging technical questions that tell you little about the real depth of a candidate’s knowledge. Even if a question seems trivial to you, you might be surprised to learn how many truly experienced engineers don’t know the answer. This is called the Curse of Knowledge – a cognitive bias where individuals who are knowledgeable about a topic struggle to imagine what it’s like to lack that knowledge. For example, you might think that every experienced iOS developer should know how to set up SSL pinning for the Alamofire-driven networking layer. I wouldn’t 😉 I haven’t used third-party frameworks for networking in my iOS apps for years now. Have you ever experienced such a situation as an applicant?
In addition, what’s the point of memorizing Swift language documentation and the most popular frameworks (both Apple and third-party)? With tools like ChatGPT or Claude readily available, accessing technical knowledge is no longer a challenge. Using this knowledge to build robust, testable, and sustainable apps surely is…
Therefore, the key questions we should be asking are: Can candidates leverage these tools to deliver high-quality, scalable, and robust code? Can they see beyond the immediate task and see long-term consequences of their decisions? To see an application as a marathon rather than a sprint? How about their thinking process when implementing features? How do they justify their chosen solutions? And many more…
This is precisely why I prefer to ask “swiss-army-knife” type of questions instead of going deep into the technical details, especially when interviewing senior developer candidates. Below, I’ve added a couple of my favorite questions. Each question comes with an associated reason for asking it, as well as what’s worth mentioning when answering. Arguably, the biggest disadvantage of such questions is how broad they are. It’s understandable if a candidate interprets them differently than we do or approaches them from a different angle. In such cases, I’ve also added some “guiding questions” that we can use to steer the candidate toward the aspects we’d like to hear about:
- How do you define “Clean Code”?
One of my favorite questions. We all understand the importance of producing “clean” code, but what does it really mean to us? Is it just about code formatting? Adhering to Swift code guidelines? Of course not.
What should be included in the answer: The more, the better (provided that you can support your answers): S.O.L.I.D. principles, separation of concerns, testability and the value of a comprehensive unit test suite, making sure the code conveys the developer’s intention, and, finally, ensuring the code is well-formatted and documented.
Some steering questions: Is it all about comments in code and keeping proper text formatting? Why can’t I simply implement the entire feature in a view? Which of the SOLID principles is the most important one? - How do you ensure the codebase won’t deteriorate over time?
There’s a reason why most developers prefer working on “greenfield” apps. During the first 6 months, development speed is typically blazing fast. Then, almost like clockwork, the pace starts to drop and regressions begin to appear. When hiring a developer, it’s worth evaluating what measures they take to prevent this situation.
What should be included in the answer: Obviously, a comprehensive automated test suite is arguably the best weapon against regressions. Unit tests are a must, but mentioning ways to test the UI automatically would be great. Next, it’s important to emphasize the importance of establishing a practice of constant refactoring (e.g., practicing the Boy Scout Rule) in the project. It’s simply much cheaper to prevent disease than to treat it. Finally, “what’s not measured, does not improve”. It’s worth mentioning which tools and metrics should be used to measure the codebase’s state of health.
Some steering questions: How can I ensure I won’t break a feature for Client A while working on another feature for Client B? When is the best time to refactor your code? What metrics do you use to determine if the project is healthy or not? - How do you mitigate the negative effects of changing project requirements?
There’s only one constant in IT – change. Developers understand technical changes well. We can usually account for updates in the iOS SDK or frameworks we use. But what about changes in project requirements? Can we even prepare for such changes?
What should be included in the answer: I’d start by acknowledging the reality that project requirements change constantly. Even with a well-documented project scope, we can never assume we’ve identified all stakeholders. That’s why choosing the right architecture for the app is paramount. And by architecture, I mean more than just enforcing a preferred design pattern. It’s also crucial to discuss how technical decisions are made – like choosing local storage implementation or networking client. I’d explain why it’s beneficial to delay these decisions and rely on abstractions until all project requirements (and stakeholders) are known.
Some steering questions: What architecture do they choose (and why)? How do they make architectural decisions? How do they define component responsibilities? How do they provide dependencies for these components?
Finally, a word of caution. As you might imagine, some people can find this approach controversial. I am, after all, “wasting” precious time discussing principles of software engineering instead of asking candidates about, say, the intricacies of SwiftUI animations. And the critics might be right to some extent. While I might not be able to tell if a candidate understands the difference between withAnimation {...} and animation(), I can assess if they grasp the principles behind software engineering. And that’s far more valuable knowledge. When interviewing a candidate with years of experience, proven track record of deployed apps, and a rich GitHub portfolio, it feels almost awkward to ask them about SwiftUI animations…
When is this method not recommended? Definitely when interviewing junior candidates. It’s unreasonable to expect people at the beginning of their IT journey to demonstrate knowledge and experience that requires years to obtain.
Avoid requesting "homework assignments"
I hesitated to include this section. While I recognize that short coding assignments have become standard practice in many companies’ interview processes – and I once supported this approach myself – I now firmly believe in conducting interviews that respect candidates’ time and effort.
As someone who’s surely been on the other side of the fence, how many times have you received a short coding task before you even had a chance to talk to the team or discuss compensation? I’m sure we’ve all heard: “Don’t spend more than 2 hours on it,” “Skip the tests”, “Don’t worry if you don’t finish the task” or “We just want to see how you approach solving problems.” How many times was it actually the case? Exactly…
I have 2 major issues with homework assignments:
- They are usually required before the technical interview.
Honestly, when do you usually establish if you’ll be a good fit with the company? When you first meet the team. And when does it usually happen? During the technical interview, most likely. Asking a candidate to invest substantial time before they could actually talk to the people they would potentially be working with doesn’t seem very reasonable. On the flip side, I understand some teams want to see the homework assignment before the tech interview to ask candidates questions about their chosen solutions. But, realistically, what can you possibly tell about their skills after a task that was meant to take no more than 2 hours? The code will likely be far from perfect, and the candidate would rightfully argue they did their best under the given conditions. Can such a code really provide sufficient insight into a candidate’s skill level? - They require substantially more time from the candidate than advertised.
The curse of knowledge leads task authors to drastically underestimate implementation time. They often completely disregard the conceptual phase, ignoring time needed for choosing the optimal design pattern, establishing proper separation of concerns, designing the code to make it testable (even when tests themselves aren’t required), etc. As a result, a candidate can either do a rushed, incomplete job and hope it won’t be held against them during the technical interview, or invest substantially more time than originally required before meeting the actual team.
In short…
As a result, I politely decline to take homework assignments. While this may sound presumptuous or disrespectful, I simply try to save both sides unnecessary work. I’ve been a professional software developer for over 20 years now. I maintain a reasonable portfolio of pet projects and open-source contributions readily verifiable on my GitHub profile. If these real-world examples aren’t enough to warrant a technical interview with the team, implementing a homework task wouldn’t change that.
Of course, I’m not suggesting we eliminate homework assignments entirely. They serve a valuable purpose, especially for evaluating developers who don’t have many open-source contributions or an active GitHub portfolio. This is particularly relevant for junior and early mid-level developers, as more experienced candidates typically have substantial work to showcase. Additionally, a homework task can serve as a useful tie-breaker. Imagine you’ve spoken with a candidate who would be an excellent cultural fit, but you’re unsure if they have the skills for a senior developer role. In this case, you might offer them an opportunity to implement a short project to demonstrate their abilities. At worst, they’ve already secured a mid-level position. A win-win situation. If you absolutely must ask an established senior developer to complete a homework assignment, ensure they’re compensated for it. To manage costs, agree on a fixed sum and time limit before assigning the task. Several companies, like DuckDuckGo, have been following this approach for years now.
A particularly concerning practice is asking candidates to implement a “missing feature” in a “playground app”. These features, if written well, sometimes mysteriously appear in the company’s commercial products. This practice isn’t just unethical – it’s exploitative.
Remember there’s a human being on the other side.
Last, but definitely not least, we arrive at the guiding principle that should be applied by every interviewer – treat a candidate with respect and empathy.
If a candidate is not a match, that’s all it means. It doesn’t mean they’re stupid or incompetent. The fact that they don’t have the necessary skills or experience today doesn’t mean they won’t develop them in a year. Or maybe you’ll soon have an opening perfect for the candidate of this set of skills? How likely are they to re-apply to your company after they’ve been interviewed by you?
This is why it’s an absolute must to provide candidates with actionable feedback. I firmly believe in the principle of reciprocity. After putting in hours of work to prepare for the interview, wouldn’t you want to know what to work on to increase your chances next time? I would. Therefore, I always provide detailed feedback for candidates – and so should you.
On top of that, simply don’t be a jerk. Even if a candidate is clearly out of their depth, remember it’s not their fault. Someone – be it your manager, HR, or another developer – invited them to the technical interview. If you need to get upset with someone, direct it toward the folks who approved the candidate for the interview, not the candidate themselves. Have I been invited for an interview for a job I wasn’t qualified for? Yes. Have I been humiliated by the interviewers? Yes. Did I feel terrible afterward? For many days. That’s why I strive to spare every candidate from this fate – even if they shouldn’t really be in the interview in the first place.
On the related topic, even if you’ve shown compassion and empathy throughout the interview, a candidate might still feel terrible afterward simply because they struggled with some questions. That’s why I prefer asking the “smart” questions (explained above). Since these questions have no “right” or “wrong” answers, even candidates who give incomplete responses are likely to leave the interview feeling confident. To avoid confusion, it’s best to start the interview by making this clear to candidates. Ensure they understand that there are no “wrong” answers as long as they can logically explain their reasoning. Let candidates know that you might ask follow-up questions to guide the conversation in different directions. Make it clear that these questions aren’t indicators of incorrect answers – they’re simply invitations to explore other aspects of the discussed topic.
Finally, avoid live coding sessions. Another controversial topic, I know… Some people argue that live coding sessions help visualise how a candidate works. It aims to showcase how a candidate approaches solving problems, works with the IDE of their choice, reads the code, etc. But does it really? A typical live coding session is run in some kind of a browser sandbox or plugin. These coding interfaces typically offer only a limited version of the Swift API, error handling, and code completion. So what kind of assignment works best in such a limited environment? Algorithms! My personal favorites! I swear, thinking about algorithmic challenges takes me right back 20 years to when technical interviews happened on a blackboard – you had 5 to 10 minutes to implement an algorithm while the interviewing team watched your every move. The memories I’ll treasure for life. In all seriousness though – what do such interviews really check? Creative problem-solving? There’s hardly anything creative about implementing bubble sort, binary search, reversing a string, or finding prime numbers in a sequence. Working with an IDE? Not really possible in a browser window. TDD? Possibly, but the task must be well-designed and limited to a single application layer. Ironically, implementing an algorithm might be a good option here. So what does the live coding session really check? Working under stress! But is it really something you wish the candidate to be able to do? Do you really work under constant time pressure with your manager peering over you and criticising your code? If you do, please consider changing a company… On top of that, does it really matter where you get the solution from? Stack Overflow, ChatGPT, Claude, or maybe a cookbook? At the end of the day, the code you present for review must solve the problem, be readable, testable, and well-documented. Nothing else really matters. After all, you don’t judge LeBron James by how many shots he missed during training…
Summary
We’ve explored how to create a more meaningful and respectful recruitment process for iOS developers.
The key lies in asking “smart” questions that assess a candidate’s understanding of software development best practices and architectural thinking rather than testing trivial knowledge. This approach is more likely to reveal a candidate’s true potential while creating a more comfortable environment, as there are no strictly “right” or “wrong” answers.
On the topic of coding assignments, we’ve established they should generally be avoided. If used at all, they should be the final – not first – step in the interview process, showing respect for candidates’ time and effort. When coding tasks are necessary before the technical interview, ensure candidates receive fair compensation for their work.
Above all however, we’ve emphasized the vital importance of empathy and human connection throughout the interview process. By offering constructive feedback, maintaining professional respect, and viewing technical interviews as compatibility assessments rather than opportunities to pass judgment, we create a more positive and effective hiring experience.
Remember: every job application represents a person who deserves dignity and respect, regardless of their current abilities or experience level.
Don’t miss any new blogposts!
By subscribing, you agree with our privacy policy and our terms and conditions.
Disclaimer: All memes used in the post were made for fun and educational purposes only
They were not meant to offend anyone
All copyrights belong to their respective owners
Some images were generated using Leonardo AI
Audio version generated with TTS Maker
