My Swift/iOS Job hunt guide

8 min readApr 12, 2020

Linkedin Connections: Make sure you have at least 500+ local and your domain specific, local (to your target location) connections on Linkedin.
Extract keyterms: Spend at least 2 hours, looking for job descriptions that match your target role, then extracting relevant key terms from it with which you have experience. You should extract from at least 20 job requirements. Don’t assume that any key term is too obvious for your profile. Remember recruiters don’t know that Xcode is implied by being an iOS developer and they will put that in their search. The iOS developers that stated the obvious on his/her Linkedin will show up in the recruiters search. The iOS developer that was above stating the obvious will not be seen by the recruiter.

After loyally following step 1 and 2, your Linkedin messages should look similar to this.

3. Link to Appointment calendar: Use picktime.com or a paid appointment, or a reasonably priced appointment slot calendar to take the stress out of scheduling with multiple recruiters.

4. Link to cv: Create a google drive link to provide your latest resume, and have a running google sheet link that provides the redundant information that recruiters ask for.

The left side is an email sent by a recruiter asking for a mix of assorted information, some of which can be found on my resume. I don’t appreciate having to provide this information ad nauseum, so I created a google drive link with the common information provided. It is in line with the DRY principle (Do not repeat yourself).

You can set the value for these keys as “will provide after offer” or “don’t feel comfortable providing” if you don’t feel like giving the last 4 digits of your social to a stranger. Which is risky.

So when Recruiters contact me and I’m open to moving forward I simply copy and paste the following message:

Here is my calendar for scheduling: https://www.picktime.com/SBladesInterviewSlots
Here is my latest resume: http://tiny.cc/hilfilmz
Here are different recruitment form data points: http://tiny.cc/cqlfiljmz

5. Patience with Recruiters: One of the hardest parts of the interview process is patience with the repetition accross multiple recruiters. Its not individual recruiter’s faults, but when you talk to many recruiters the repeated questions become a mind numbing blur. It is important to be kind to the recruiters and patient. They are gatekeepers and they are people too.

6. Prepare responses to gotcha questions: Loyally following 1–5 should get you some technical phone screens. This is the first part of the real interview process. Assuming you know your craft, there will be edge case or “gotcha” questions which will often be asked. You will rarely encounter these questions in the wild, but rest assured they will repeat. Here are my running log of Swift/iOS gotcha questions along with some often repeated questions. Study the repeating and difficult questions so that you pass the interview.

7. Read daily: Another thing to do during the period of time that you interview is read and write regularly. Doing so increases your ability to articulate and communicate your ideas under pressure. This can make or break your interview. Charisma counts, even for engineers.

8. Be respectful and patient: The next phase of interviews are usually onsite and that implies a longer, more difficult period of interviews. Keep in mind, the company pays probably at least $600 in engineer hours in order to conduct these interviews, from scheduling, to preparation, to interviewing to review. Respect their time. If you don’t, it can easily break your chance.

9. Onsite interviews:

Your background

They will have you walk through your resume with them. Be honest, consistent and confident.

Casual technical

basically a repeat of the phone technical except its in person.

Build an app

Build an app that makes multiple api calls, displays objects on a tableview.

Create a framework that pre-builds all the routine tasks releated to this. I have created this one.

Algorithm or data structure challenge

DSEUATp: Dose u atp? Or past participle: sautédp, alternative spending.

Description: Read description out loud. Pause for and mention gotchas.
Strategize: Talk about strategies before starting, mention the pros and cons of different strategies.
Example cases: Provide 5+ edge cases. The stranger and more challenging the edge/example cases, the better, especially if you can explain it.
Unit tests: Provide a unit test for each of the 5+ edge cases.

import XCTest class YourAlgorithmTests: XCtestCase { 
  
    struct InputOut {
        var input: [Int]
        var output: Bool
    }    var inputOuts = [
        InputOut(input: [1, 2, 3], output: false),
        InputOut(input: [], output: true),
        InputOut(input: [-9], output: false)
    ]    func testYourAlgorithm() {
        for inputOut in inputOuts {
             XCTAssert(myAlgorithm(inputOut.input) == inputOut.output)    }    func myAlgorithm(_ arr: [Int]) -> Bool {
        // Code
    }
}

5. Algorithm: Draft your algorithm/solution.

6. T Diagrams: create T diagrams. And walk through your algorithm step by step tracking the values in your T diagram.

7. Performance: Discuss the big O complexity of your answer.

8. General Strategies:

When its time to code an algorithm after discussing your strategies, Choose the best one you can think of and start executing it right away. Do not get stuck in an infinite loop of comparing pros and cons ad neauseum.

You should practice algorithms following these 6 steps every time. Notice the algorithm itself is only 1/6 of the process. I did a interview a couple months ago where I only got to step 4 for 2 algorithm challenges, meaning I didn’t even start or barely started writing the algorithm itself. I did 1–4 well though, so I got an offer anyway. Inversely, there were multiple times when I provided a correct answer for algorithms and I was rejected, because my process was sloppy.

Physiology:

Make sure you have eaten a high protein low inflammation meal prior to the interview,
make sure you have exercised,
meditated, and
taken any prescribed medications to help you cognitively perform well. Look into nootropics, and if you think more clearly when you drink coffee. Drink coffee before the interview. I personally benefit from eating a handful of cruciferous greens.

Rejection:

There will be rejection, but you are always winning as long as you are improving. When rejection happens, ask for feedback. If you get feedback, work on the feedback and improve. Take the win. When you aren’t given feedback, or you are given feedback but it isn’t clear, make sure you recorded the interview in some way shape or form so that you can review it. Write down a list of things to improve. Improve them. Take the win. After that, give your own self evaluation. Take pride in the things you did right, such as the positive results you have received and the effort you put in and then move forwards quickly. Take the win. Develop resilience. More details on resilience. Every rejection is an opportunity to show yourself and the world how resilient you are.

Optimism. Resist any urge to view the rejection as worse than it is or to be a summary of how you are as a developer. Acknowledge that the interviewer made a snapshot decision based on only a few hours together. They made many incorrect assumptions and guesses. They have a limited idea of what you are capable of. There are thousands of great alternative companies which are all options.
Altruism. Helping others can help with the stress of rejection.
Having a moral compass or set of beliefs that cannot be shattered.
Faith and spirituality.
Humor.
Having a role model.
Social supports. Try to line up someone that is supportive whom you can call when you are rejected to help build you up, and keep you accountable to seeing things optimistically.
Facing fear (or leaving one’s comfort zone). Talk to another recruiter, or send your resume out, or call up a connection to see about starting another interview process.
Having a mission or meaning in life.
Training. Put in 2–3 hours a day or more preparing for the interviews.

Tips for the interview:

Confirm that you have the interviewer’s name correct. I nailed a technical interview but I called him the wrong name throughout the interview and he didn’t correct me. I wasn’t rejected, but I wasn’t given a passing grade. I had to re do the interview. I can’t help but think me calling him the wrong name for an hour had something to do with it.
Know that you are responsible for the timing of your interview, and ask your interviewer what is on the agenda for the interview. If you spend too much time on an algorithm and you have two scheduled, it is cutting into your time for the second one. Ask about it, and move things along.
Ask the title of the person interviewing you. You’ll find senior, lead and manager types won’t mind you spending a lot of time on good form, writing tests, verifying your code etc. It means you will save them time having to clean up after you. A more junior or regular developer might err on the side of respecting speed and completion over robustness. Its a delicate balance though.
Do not emphasize ways they can judge you negatively. If you didn’t get your degree in computer science, you do not have a legal obligation to say “I didn’t get a degree in computer science.”

Remote Interview checklist:

Clean you room
Make your bed
clear the view
Improve the lighting if possible
turn off notifications
turn ac on cool
eat foods that make you think clearly.

One at a time or All at once?

When applied to our focus, studies have shown that we can only focus on one thing at a time. Multitasking is the illusion of a split attention perpetuated by quickly switching attention back and forth between two things. The latter exhausts you're mental resources.

Knowing this, I figured that I should schedule my interviews with enough time for me to process what I learned and fully incorporate it in my toolset so that I wouldn’t be stumped by the same things twice. So I would schedule one technical interview on Monday, and the next technical interview would be no sooner than Thursday for example. WRONG APPROACH.

Scheduling this way makes it nearly impossible earn competing offers. Spreading out your interviews like this limits the amount of interviews you can do before you exhaust your financial and mental resources. Also, while taking time to process and plan for the errors sounds good, the fewer interviews you do, the harder it is to identify useful patterns. The more time between interviews, the more energy and momentum you loose. It takes a certain level of confidence, and energy to interview well, and if you did interviews for the last 4 days, you will likely have a different kind of confidence. You’ll meet more people, you might start to find the interviews to be fun because with the practice you might start to get pretty good.

I used to fear running out of options. If I tried I couldn’t interview at all the companies that are hiring for my skills in my lifetime. Not only that, most the big awesome companies, need to hire for multiple teams and if you fail an interview process in one period of time, you can still interview at another period of time. Go big or go home.