Before the Interview
We consider ourselves good iOS developers. How good? Well, we have done some impressive things in our lives. For example, we built gorgeous animations, implemented Combine, uploaded app versions to the App Store, and debugged complex bugs.
So, what is the problem exactly? Why do we need this book?
Because knowing Swift, UIKit, and Combine are remarkable, and debugging, algorithms, and CI management are all essential skills for an iOS developer. But one skill needs to be added for many developers, and that’s how to be a player in the iOS developers’ labor market. Playing in this market requires us to learn and adapt to new skills that some of us may still need to learn, such as skills in the fields of self-expression, wording, communication, and even marketing.
By the end of this book, we will take our tremendous iOS development knowledge and learn how to use it to develop a new skill: the ability to pass an iOS interview.
So, how do we start?
Lau Tzu (a Chinese philosopher) said:
The journey of a thousand miles begins with one step.
But the question is, what is the first step?
Is answering a Swift question or scribbling a design for an architecture problem the first step? Well, our first step is to understand what we want from our workplace, where we want to be, and to get ready to conquer it with confidence.
Understanding all this may sound like an easy task. We just send our resume (that we wrote in two minutes) to all the tech companies we know and expect that something will pop up. Unfortunately, it doesn’t work like that. We must research the market and adjust our resume according to our needs. Even more important, before we look at the market, we must look inside and understand who we are and what will be good for us.
In this chapter, we will learn how to reach our first interview with a company that suits us in the best condition possible. We will build a company profile together and learn about the different types of companies out there. We will also learn what a good (or bad) resume is and write a resume that fits us and our target workplace. Then, we will learn how to be prepared for our first interview in all matters.
To that end, we will cover the following topics in this chapter:
- Performing company research
- Building our resume
- Preparing for the interview
Performing company research
Many candidates may find the next sentence strange, but some fail in iOS interviews, because they lack knowledge about the company they’re interviewing for. Do you believe that? The truth is that mastering UIKit or SwiftUI is essential, and being a Swift expert is crucial, but the workplace profile is just as important.
Think of working in a company as a long-term relationship and the interview process as the blind-date meeting where it all started. Remember the excitement, the research we did with our friends, or the questions each of you asked during the session. Well, the job interview is your first date. Dress nicely!
A job interview is a bidirectional process. During the interview, we examine the workplace just as much as the workplace examines us.
The primary reason for learning about the company we’re interviewing for is apparent: we want to ensure our next workplace fits us like a glove. But there’s another reason. It will be constructive during the interview process if we are familiar with the company, its product, and the market.
Before starting the interview process, we should build a company Profile where we can learn everything about its culture, size, working environment, and more. There’s official and unofficial information that we can retrieve, and both are essential to our readiness.
Why? Let’s find out!
Knowing where you’re going is part of the interview
Here’s a secret you can find only in this book: many interviewers check our knowledge, not only in iOS development but also regarding the workplace itself. Sometimes, it can make a difference when comparing candidates with similar coding skills!
Interviewers look for enthusiastic, self-confident candidates who are familiar with the product, the market, and the industry.
The preceding knowledge leads to another side of our personality that we want to show: that we are mature, serious, and conducted comprehensive research before we came to the interview. This side of us tremendously boosts our chances of succeeding in our role, and that’s something interviewers look for.
Company profiles affect our answers
Believe it or not, some company characteristics may influence our answers, especially regarding design and architecture questions. And that’s something we will learn in the book. In many cases, interviewers want to see gray colors in our personality, not just black and white.
I mean that we always need to balance our answers and understand that there are pros and cons to almost any question. Answering a question with the mindset of the company we are interviewing for can really make a difference in how it looks to the person’s eye who is interviewing us at the time.
Learning the company characteristics
Generally, the company profile is divided into three parts: product and industry, company details, and working environment. I think that all of them are important in one way or another to start understanding where we are interviewing and if and how the workplace fits our needs.
Let’s see how we build each part.
Product and industry
In a job interview, I can’t begin to describe what it means to be familiar with the company’s product or industry. Let’s talk about what it does to us as interviewees.
First, it increases our self-confidence. We feel in control when we understand the broad ecosystem around our interview process. When the interviewer talks about the company and its product, we can quickly understand what he is talking about. But moreover, knowing the product will point our answers in the right direction and context. There’s a big difference between answering an architecture question when interviewing for a social app company and an advertising company building an SDK. In an iOS development world, these are two different creatures. We will go over that in Chapter 12.
And second, asking the interviewer intelligent questions about the company shows that we did our homework and know what we’re talking about. In most places, that counts for a lot.
Retrieving company details
Company details are our company profile’s most accessible and shortest section. There are a couple of questions we should ask ourselves before and during the interview process. These questions can give us a clue about whether this company is suitable for our needs.
The questions that we should ask are essential and intertwined:
- What is the company size?
- Where is the company currently in its life cycle?
- Is the company public or private?
You may not find these questions necessary, but as a matter of fact, they have a tremendous impact on your career as an iOS developer and even beyond that.
Let’s discuss each one in detail and start with the first one – company size.
Considering company size
In the USA, a small tech company is considered to have fewer than 100 employees, a medium tech company employs under 1,000 employees, and a company with over 1,000 employees is considered to be large.
Even though these definitions are not identical in different countries and industries, in our discussion, it doesn’t matter much. What matters is what it means to us as employees.
Small companies allow us to produce a more significant impact on the company and its product. It usually means working in small teams; sometimes teams that are one person only(!). And because these companies are small, they also give us an intimate feeling, which comes with a good work/life balance. Another pro for small companies is the pace – it’s much faster. The fast pace is mainly because small teams have simplified working flows. Small companies also have downsides. They are mostly less stable than bigger companies and have less room to grow your career.
Large companies are the opposite. Even though they are much more stable, the employee has a much smaller impact on the company product and its path. To gain more influence in large companies, we need to move up in the hierarchy, which, unlike small companies, is much easier. Also, the pace of development is much slower due to more dependencies between teams and company regulations.
In a way, medium companies are like a mix of large and small. They still provide an intimate family environment while being more stable than small companies. Therefore, it is not surprising that medium companies are the preferable firms by most tech workers. The combination of stability, a warm environment, and fast development pace fulfill the preferences of most people in the industry.
But looking at company size as the only indication of suitability is perhaps too superficial. As stated earlier in this section, there are more factors you need to take into consideration, for example, where the company is in its life cycle.
Analyzing a company’s life cycle
Yes! Like humans, companies have an age, DNA, innovations, ideas, and many other characteristics.
The following diagram shows a start-up company’s life cycle:
Figure 1.1 – A start-up company’s life cycle
Companies are born, and they grow, mature, and sometimes even decline and die. And just like a human, each stage of their life cycle has its own excitement and risks. As a result, when searching for a company, one thing to look at is the stage in its life.
The company’s stage may point to the working atmosphere we might experience. It can tell us the opportunities and whether the company is at a stage where everything is ticking, or if we need to set up workflows from the ground up.
Another deeper aspect we need to look at is the life cycle of the mobile team itself. The company can be mature, but the mobile team was just born. Regardless of the different opportunities a new team may have, there can also be differences in the technology it uses, and that’s also a critical issue in our interviews.
In many cases, interviewers tend to ask questions about the technology they use or want to use in their projects. For example, if we’re talking about a mature mobile team, its developers probably use UIKit and might even use Objective-C (God forbid!). In this case, expect questions about UIViews or Objective-C categories and blocks.
Also, in mature teams (and mature products), the project might contain legacy code, which can be painful to deal with and sometimes requires refactoring.
When we perform our company’s research, we must ask the right questions about the company’s stage, the team, and the project. The answers we’ll get can give us an overview of what we might expect in our interview and the workplace.
Now, notice that the question, “In what stage is the company right now?” is not always a straightforward question, and not all interviewers can answer that easily. You need to dig in a little bit deeper when asking questions and conclude yourself. One of the things we need to consider when analyzing the company’s state is whether it is public or private.
Deliberating between public and private
The difference between a public and a private company is pretty simple: its ownership. A private company is owned by one or a few individuals, while a public company is owned by shareholders who have bought stock.
It is difficult to say which type of company is “better” to work for, as this will depend on an individual’s personal preferences and career goals. Some developers may prefer the stability and potential for growth that a large public company can offer. In contrast, others may prefer a smaller private company’s flexibility and entrepreneurial spirit.
If you are confused between the “public versus private” and the “large versus small” argument, it is not a coincidence. Public companies are generally more prominent. They are more structured, while private companies are considered to be smaller.
But there’s much more than just size. The ownership difference has an impact on the company culture. For example, in public companies, the decision-making process is more complex due to the need to consider the interests of the shareholders. That’s not the case with a private company with a more agile and faster process.
But I want to clarify this point: we can still find a “start-up” atmosphere in a public company and corporate vibes in a start-up company. Therefore, it is essential to sense the working environment and consider the results.
Let’s see what factors we need to look at.
Sensing the working environment
The product can be excellent, and the team can be super strong. But, if you want to develop not only iOS apps but also your career, you need to work in a supportive environment that can make this happen.
There are several questions we can try to discover about a company’s working environment:
- What is the company’s hierarchy? Is it flat or hierarchical?
- How are the research and development (R&D) department and the mobile team built?
- What is the average working day like? Do we have daily or weekly meetings?
- Are there any code review sessions? Who can do code reviews?
- How is the work/life balance procedure?
- Is there an option for an iOS developer to write backend code and be a full-stack developer?
- Is there shared knowledge between the iOS team and the Android team?
- What is the involvement of the iOS team with other aspects of the company, such as the product?
The primary issue with these questions is the fact that it is hard to get reliable answers from the interviewer. I’m not saying he is a liar! But remember, one of the interviewer’s goals is to market the company and the iOS team. However, one of your goals is to get the most authentic answers, and these two goals do not always fit in.
Always take what the interviewer says with a grain of salt and reach for the truth yourself.
So, next, let’s talk about obtaining some helpful information and see how we build an unofficial profile.
Building the unofficial company profile
Now that we made sure the company’s “dry details” fit what we need and require, it’s time to dive deeper and collect some unofficial information about the company. There are three ways of doing that: research, research, and… research!
Analyzing job postings
You can learn a lot from analyzing the job description. Moreover, it doesn’t have to be the iOS developer job description, but any other roles in the company. By reading the job description, we can reveal how the company prioritizes its values even though the company probably didn’t mean to share that prioritization with us.
For example, if, on the one hand, the job description emphasizes how it’s essential to meet deadlines, it shows happy hour events and talks about loyalty. Still, on the other hand, they say nothing about flexibility, it may be a good indication of how the company feels about work-life balance. If the job description describes the atmosphere as dynamic and young but doesn't mention professional and strong, it may be a good indication of what code reviews will look like.
Remember, nothing is set in stone, but collecting puzzle pieces is vital to see the whole picture.
Looking at social network profiles
Just like job postings, looking at the company’s social networks such as LinkedIn, Facebook, Twitter, and Instagram can give us a sense of the company’s ambience. For instance, we can see how many beach days the company holds versus professional events such as meetups and lectures.
Another interesting thing is what employees, customers, or partners share. Do you feel that they are pleased or unhappy? Do people stay long in this company, or does it look like a revolving door? Do some spy work! It’s perfectly legit and helpful.
Browsing the company website
The company website is another excellent place to find additional details about your dream workplace. Besides products, you can discover interesting information, such as company values, leadership, and more.
But you can find even more fascinating information, such as the company blog and events. Many companies hold professional blogs where employees can post articles related to their work.
A professional blog maintained by employees can indicate that the company puts developer branding on top of their minds. If that’s important to you, a blog can add some points to the equation.
Talking with employees
Today, the world is more connected and linked than ever, and it’s effortless to approach almost anyone you want.
LinkedIn’s company page is probably the simplest way to connect to iOS (or even Android) developers that currently work or worked in this company. Tell them you are considering applying and want to consult with them.
Before the talk, write questions about the information that is much more difficult to receive in other channels. This inside information is precious, so prepare seriously for that talk.
Here are some examples for questions:
- What are your working hours? Do you work from home as well?
- What technologies or design patterns have been added to the project since you started working there?
- Are you doing tech design for features? If so, who’s writing them?
We should always take what people say with some doubts, so asking direct questions can be tricky. Every person we talk to is different, and each has a different history and experience with their working place. What we do need to do is to listen to what’s not being said and try to notice any subtext in the conversation.
For example, we can ask them, “What do you like about the company?” Obviously, they will list things, such as company events and perhaps the people they work with. If they won’t state something such as “high standards,” it doesn’t mean they do not exist, but if several workers don’t mention that, it could be a good indication that they’re not something the company is focusing on.
Being a good detective or investigator can sometimes pay off!
Moreover, Glassdoor provides additional benefits, such as the ability to see not only workers’ reviews, but also candidates’ personal experiences from the process while describing the interview, the office, and even interview questions and coding tasks. Sites like Glassdoor are a treasure for candidates who want to perform advanced company research and can prepare us for the interview day.
Come to the office early
This is one of the lesser-known tips in company research, yet it is still very effective. When you are invited to the first on-site interview, early always looks good. It shows that we are serious and mature, and there’s no worry that it can cause negative effects.
But coming early has an additional benefit. It’s an excellent method to experience how a day looks in the office. We can sit in the office, make a coffee while waiting, and listen to what employees say.
Do they talk about work? A specific problem? Are they working in different teams (so we can tell the collaboration level)?
If it’s morning, how many workers do we see in the office? This can be an indication of working hours or work-life balance.
Remember, we won’t always hear the complete truth during the interview process regarding different information about the workplace, so seeing things through your own eyes is immeasurably valuable.
To summarize, knowing where we go can make us more ready for the interview process, and it helps us understand if the company we are interviewing for fits our requirements.
As I said earlier, interviews go both ways. We examine the workplace just as much as it examines us. And since it is going to be our next “home,” we should invest effort in it as much as we can.
Now that we have done our company research, we need to move forward and apply to those companies. The most popular way to do that is by building our resume.
Building our resume
Being noticeable among dozens or hundreds of other candidates is not easy. Making our resume shine when there are many other great candidates sounds like an impossible mission. It’s not a coincidence that some recruiters claim that writing a good CV is not science but an art. Sure, there are guidelines on how to do that, but to stand out, we need an artistic touch.
And speaking about art, let’s see how looking at our profile as a movie or a book can benefit us.
A resume is like a book or a movie
Imagine you enter a bookstore. You want to pick one or two books, but there are thousands of books in the store. What do you do? You choose a book with an interesting title, turn it over, and go over the back cover text. After a few seconds, you have already decided about the book even though you haven’t opened it or finished reading the back cover. The reason for that is apparent. You don’t have time to review so many books, and you decide to invest your time in those with a catchy title and an interesting back cover opening.
The experience I just described is precisely what happens in workplaces that receive many job applications. In big companies, an average resume scanning by a recruiter takes between six to 10 seconds. This is a short time to impress someone, isn’t it? Well, that’s why I said it’s like an art more than science.
Now, if we pass that stage, the recruiter decides to read the rest of the resume. Assuming our profile fits the company, we need to impress the hiring manager, which is not an easy hurdle at all.
Oh, didn’t I tell you? That’s the difference from a book. We need several people to read our resume and like it!
Let’s see how we nail that challenge together.
Structuring the resume outline
A basic resume outline is based on content importance. We start with our name as the title, contact information, a summary of ourselves, expertise, and then skills, education, and our projects and achievements.
There are indeed different resume outline variants out in the field. For instance, some say adding personal insights, such as hobbies or volunteering activities is also a good idea. Some even add a photo portrait.
But in my perceptive, I think less is more, regarding resumes. We should keep it simple, clear, and straight to the point.
Working on design and layout
Well, what about the design and the layout?
There are tons of resume design templates we can download easily from the web. Even though some of them look beautiful, we should remember that the document’s purpose is sending a clear message about who we are and why we are the best option to invite for an interview.
Since we have only six to ten seconds to catch the recruiter’s attention, we should plan our CV (Curriculum Vitae -> “course of life”) according to that assumption. One of the most famous methods of that is to use something called the F-Pattern.
What is the F-Pattern?
Scanning a document quickly sounds straightforward at first. We probably imagine the recruiter starting to read your document and just stopping after a while. The basic assumption, that the recruiter is reading our document rather than scanning it, is just wrong.
The Nielsen Norman Group (NNGroup) had exciting research in 2006. Their researchers gave thousands of documents to more than 200 students and asked them to review them while analyzing the eye-tracking movement quickly.
The findings concluded that users have a constant pattern of “scanning” the documents – they move their eyes in a pattern that looks like the letter F:
- First, they read the first two rows, from left to right.
- Then, they move down a little bit, skip some lines, maybe, and read another row, but this time they won’t go all the way to the end.
- Finally, they scan the document from top to bottom and on the left side.
For right-to-left languages such as Arabic or Hebrew, the F-Pattern is flipped.
Have a look at the following image from NNGroup’s website (https://www.nngroup.com/articles/f-shaped-pattern-reading-web-content-discovered/):
Figure 1.2 – NNGroup Document Scanning Experiment results
So, why do users do that?
We now understand where the recruiter’s eyes go when scanning your resume, but how can we ensure the reader doesn’t miss our primary objectives?
Okay, now we are battling for the user’s attention, but it doesn’t mean we are losing. Here are some tips on how to handle the situation:
- Because of the F-Pattern research, we know that the user invests heavily in our document’s top part. We should put our most meaningful message to the user in this place. In other words, this is where our “money should be spent.”
- The same goes for each section of our document. We always need to start with the message. When we describe a project that we were involved with, we should start with our contribution to the project rather than describing the project’s history.
- We need to make it easier for the reader to understand what’s important and what’s not by using typography. For example, marking primary words in bold can help us emphasize the document’s essential takes (as I did here).
- Add space between sections and use big, clear headings. That can help the reader understand the document outline and avoid getting lost in the scanning task.
- Use short bullets instead of long, tedious paragraphs. Short bullets take a load of information and display it in a structured list, helping the user to scan and understand what we wanted to say quickly.
Using typography is a great way to help the user understand how to read our resume while taking advantage of the F-Pattern and overcoming its flaws.
Let’s break our resume into different pieces. We’ll start with your personal information.
What is the personal information part?
Returning to the bookstore analogy, the reader first scans the book title. In the CV world, our name is the book’s title, and the profession is its subtitle. We can also add certificates and awards to the pile to make the subtitle a bit catchier.
The most important thing about putting our personal information on top is double-checking that all the provided information is accurate. We don’t want to be in a position where it is difficult for the reviewer to reach us just because we haven’t paid enough attention.
One tricky piece of information is our address.
A few words about the personal address, because it’s a little bit of a sensitive subject.
Traditionally, resume documents used to contain a personal address. A personal address was a primary part of reaching a candidate and a massive consideration of whether their location suited a company. Even though things have changed, and we live in a different era, many recruiters still expect resumes to include an address.
However, there are a couple of reasons why we don’t want to put our full address in the resume document:
- It’s sensitive information. For privacy and security reasons, it is perfectly understood why some candidates prefer not to have their address details flowing around.
- Some places can find long-distance locations a problem and may reject us. There are countries where discriminating by location is illegal, and still, we don’t want to put ourselves in a problematic situation.
If we still decide to put an address in our resume, here are some tips:
- We don’t have to put our full address. A city or a region is good enough for most reviewers.
- If we know that our location can become an issue for many companies, we can state our willingness to relocate (if that’s accurate, of course).
- Emphasize throughout our resume our ability and experience in working remotely (again, be accurate on this). Working remotely for iOS developers is perfectly legit today, especially since COVID-19.
Now, let’s continue to our main dish and formulate our personal summary section.
Formulating the personal summary section
Now, even though we call it a “summary," it doesn’t summarize our resume, and we’ll understand why in a minute.
The first thing we need to do when approaching to write our summary section is to flip sides and think like an employer. What kind of iOS developer are we looking for? What can help our team or our company? What kind of a person can fit into our squad?
Working according to a structure
Let me start by reminding you of the 6 to 10 seconds it takes for a reviewer to scan our CV and decide.
6 to 10 seconds. This is all we have.
So, we need to write our summary section according to that assumption. Short, simple, and to the point, while keeping it to 3 to 5 sentences and no more than 50 words.
But what exactly do we need to write?
Let’s start with how it is built. The basic structure is built upon three things: who we are, what we offer, and our goals.
Since we are all iOS developers, let me try to describe it as a formatted string:
let adjective: String = "Self motivated…"let role: String = " iOS Developer" let experience: String = " with 3+ years of experience with iOS project.." let goals: String = "eager to learn and develop myself" let summary = adjective + role + experience + goals
Perhaps we are not professional in resumes just yet, but Swift we know, don’t we?
Find our soft and hard skills
Soft skills are not related to a specific role or industry. Soft skills are non-technical and can help the employee accomplish various tasks. Some examples are time management, communication, and problem-solving.
For instance, if you lack development experience, try to emphasize your hard skills. If you’re an experienced iOS developer, you probably gained some tremendous soft skills over the years, and you can highlight them instead.
Adjusting to your workplace using terminology
Yes! It means that we may need to create several summary versions for different job postings. And why is it important?
To start, we want to speak in our reviewer’s language. If they are looking for a “motivated iOS developer," our reviewer will be excited to find exactly what they were looking for.
But it doesn’t end here. In the next sections, I’m going to tell you a dark secret most candidates don’t know: Applicant Tracking Systems (ATSs).
What are ATSs?
Back (again!) to the 6-to-10-second scanning process. A recruiter scanning a resume is efficient when the workplace receives dozens of resumes daily. But what do we do when a workplace gets hundreds or even thousands of resume documents daily?
Oh, I know! They hire more reviewers, right?
They use something called ATS, which, among many things, this system does. It can also parse resumes and extract headers, contact information, and keywords.
As a matter of fact, in big companies, most of the resumes aren’t even read by humans! The ATS act as gatekeeper in these places, filtering out irrelevant candidates. Want to beat the ATS? Include keywords based on the job posting and use clear formatting.
Be aligned with the employer’s needs
Every company needs something different from us. One company needs us to deliver an extremely robust SDK, and another company will need us to build a slick UI. SDK and slick UI are two different things. We cannot express how good we are in both areas in 50 words!
We need to choose, and therefore research, and understand what the company’s needs are. Following that, we can adjust our summary to answer the company’s requirements.
Adjusting to the post-COVID era – be flexible
If there’s something that COVID-19 has taught us, it is that nothing is set in stone, and we need to be as flexible as we can. Flexibility can be expressed by relocation, role changes, or technology.
If some of these are legit on your side, try to include that side in your summary and show how you evolved and adjusted yourself to changes over the years.
Flexibility and willingness to change can give employers confidence, and in some companies, it can be useful to emphasize that side of us.
Focus on specialty
The last tip in the perfect summary is that we all have a specialty – something that we are good at in being a powerful iOS developer.
If we want to stand out from the other developers trying to compete in our role, we need to emphasize the area where we have outstanding capabilities.
Now, the big question is, what if that capability is not relevant to our desirable workplace? The answer is that it doesn’t matter. Managers are like ninjas and superb developers. If we are striking well in one area, it probably means we can be good in another.
Listing our expertise
This “Expertise” section contains a list of workplaces and open source projects we worked on. Usually, the list is chronologically ordered, and that’s perfectly understood. Our last workplace is the most important one, so it should be on top. But there are three things we need to make sure of when we write that list:
- Focus on our contribution to the company and the team, rather than our last or current title. “I created an app from scratch,” and “I led the iOS development of the company’s primary app” are examples of contributions.
- Cover our contribution with project names, numbers, and stories. Some details make our contribution description much more reliable and precise.
- Speaking of reliability, don’t miss anything! Never hide a workplace, even if you worked there for a few months and got fired. At this point, the recruiter may try to dig into some details about our application, and hiding such an important detail may cost us the job and our reputation.
Expertise is only part of the picture we want to expose. The other major factor is our skills.
This section aims to show our capabilities and present our knowledge to the reviewer.
First, let’s remind ourselves of what we’ve discussed earlier regarding soft and hard skills. Hard skills are technical skills such as Swift, Combine, and SwiftUI. Soft skills are not particularly related to iOS Development and pertain to our capabilities as employees in general, such as communication and problem-solving skills.
What we need to do now is to list our skills (both hard and soft) cleverly and effectively. Let’s see how.
Adjusting our skills to the requirements
For example, if we are looking for remote work, we need to emphasize the soft skills that can help us work remotely. Communication, time management, and independence are all examples of soft skills employers look for in remote roles.
Mixing our skills list
Remember that even after we successfully passed the initial scanning, there’s still an attention limit when reviewing our application. We can’t put an endless list of skills, and limiting that list to 10 to 15 skills is best.
Don’t worry, limitation has a significant upside. It pushes us to focus and forces us to prioritize our list.
In the 10-to-15 skills list, we must have different types of skills as listed here and create some sort of an interesting skills mix bag:
- Hard skills that are relevant to the job requirement are important. Social apps, payment, gaming, and SDK are all examples of relevant hard skills.
- Soft skills relevant to the working environment, role, and company size help, too.
- Add a specialty skill that makes us stand out compared to the other candidates and shows our capability to shine in specific areas.
Some skills need to be in your personal summary section, and we must ensure our summary is synced with the skills list.
Mixing the skill list will ensure we don’t have blind spots and safely cover the hiring manager’s requirements.
After we present our skills and personality, we move to the part where we need to show some evidence.
In this part, we can present our education, certificates, training, blogs, publications, GitHub repositories, and more.
Part of what I just wrote is something we call Developer Branding, and we will discuss it in Chapter 3.
Avoiding red flags
The first thing we must understand about red flags in our resume is that no resume is perfect. Most of us have had issues in the past. We took a very long vacation to organize our lives, got fired, or things just couldn’t work out.
So, as a result, we need to ensure our resume is reliable. On the other hand, we need to emphasize our positive side on occasion.
The first red flag we need to address is job-hopping. Spending less than a year in one place can raise some eyebrows in a workplace that looks at our resume. It gives the feeling that we are not stable, mature, and that we have trouble with absorption in workplaces. One thing that many candidates do in a job-hopping situation is to eliminate that job from their resume, with the excuse that, “It doesn’t have any meaning, anyway."
Now, hiding details from our working expertise is not a good idea. The hole in the resume is there to be seen, and eventually, things like that are always floating and can cause much more damage than we wanted to avoid.
The best thing to do in this situation is to highlight our accomplishments in each role rather than our work duration. When we emphasize our experience in each workplace, we show how working across different teams and companies increased our breadth of knowledge and competence.
We should consider taking a disadvantage (job-hopping) and converting it into an advantage (working diversity and broad experience).
Of course, that lesson is relevant for all the other parts of our resume, but when we have a built-in warning alarm, this is doubly true.
Inviting another set of eyes
Once we have finished writing our resume document, it is highly recommended to give it to someone else to read and give us their feedback.
We must pick our “second set of eyes” carefully and ensure our feedback will be as emotionless and professional as possible. Try to pick a recruiter or talent acquisition to review your resume structure and a hiring manager to review your summary and expertise. Even one or two comments can make significant differences.
Preparing for the interview
So, we got a call from a recruiter saying they went over our resume and are interested in moving forward with us! This call means that we did a great job with our resume and succeeded in showing our experience and capabilities just the way we wanted.
But – the hard work is only ahead of us.
In Chapter 2, we will discuss the interviewing process, the different stages, and their primary goals, but now, I want to discuss the period before the interview.
Taking our time
When the recruiter wants to schedule your first interview, the first thing many candidates do is schedule as soon as possible because of the excitement of getting an interview. Well, that’s a bold mistake.
We should take our time and make sure we start this journey 100% ready. A time frame between one and two weeks should be enough to start the first stage.
Technical, personal, and logistics preparations
Being ready for an interview doesn’t mean just going over Swift questions. There are three levels we need to ensure we are ready: Technical, Personal, and Logistics.
Most of the books that talk about iOS interviews deal with technical preparations. In this period, the first thing we need to ensure is that the foundation of iOS development is strong and solid. Screwing up on the fundamental questions and tasks will devastate us and risk our job application more than anything.
The second thing we need to do is get a whiteboard to practice design and architecture questions. In design questions, we need to get used to drawing a UML or a system chart on a whiteboard. Even though drawing on a whiteboard sounds easy, it requires practice and experience.
Besides the drawing task itself (which is not that easy for many candidates), we need to know how to present a system, decide what we consider a module in our chart, and explain it verbally. We will focus on that in Part 4: Design and Architecture of this book, but we need to make time for that in our preparation plan.
The third thing is building our daily routine. Whether we have a daily job or are unemployed, without a daily practice routine, it’s going to be hard to move forward and close all the knowledge gaps. Are we night or morning people? Knowing who we are can help reserve a slot dedicated to practice in our schedule.
Our personality is another important side of the process. As part of the interview preparations, we must build our story as developers. What is our story? How did we get into the development world, especially iOS development? Why did we decide to work in the places that we worked in the past? How was it to work in a big or small company? Why do we search now for a new workplace?
The answers to these questions help the interviewer to build our developer profile, so we must not forget that in our preparation planning.
This is the easy part, but we must not fall for this one. We first need to print our resumes. It is always good to bring them with us. Bringing our resumes shows that we are serious and have got nothing to hide. It also starts the interview by focusing on us, which is precisely what we wanted.
The second thing is to plan our arrival journey. Being early can never harm our odds of continuing the process, but late sure can. Never – never be late for an interview.
The third thing may sound weird and unrelated, but it is much more important than you think: make sure you smell good. Now, I mention the smell, because many people (interviewers, in our case) tend to associate a smell with the person they talk with. Now, just to be clear, the link between smell and people is not the interviewer’s fault; it’s just how our brain is built. There’s a direct connection between memory, emotion, and our sense of smell. It can be a good idea to put deodorant or perfume in our bag during our on-site interview.
Throughout this chapter, we’ve learned what a company profile is and how to build it, how to describe our needs, and how to match with the right company. We also learned how to write a resume for fast recruiter scanning and deep reading.
We’ve discussed the different skills that we have and tried to find a solution for gaps and issues that might be present in our expertise.
Finally, we discussed being prepared for our first interview with full power.
Company research is a significant part of the interview preparation. It increases our chances of choosing the right place for us and helps us to get through the application process and get our first interview.
But what exactly happens in the first interview and beyond? That’s precisely what we will talk about in our next chapter.