The panelists give their tips for finding jobs in the world of iOS programming.

 

Don’t forget to mispronounce someone’s name.

Hey everybody, and welcome to episode 76 of the iPhreaks Show. This week on our panel we have Andrew Madsen.

Hi from Salt Lake City.

Pete Hodgson.

Hello from sunny San Francisco.

Alondo Brewington.

Hello from North Carolina.

Charles Max Wood.

This is the first show that I haven’t intro-ed that I’ve actually been on, but I have a cold.

Ouch, that sounds tough. My name is Jim Zuber. [Laughter] Actually it’s Jaim Zuber. Oh, sorry. I figure I should give the obligatory mispronunciation going. But today I’m going to talk about finding iOS jobs, and I thought we’d start by just going around the horn and having people share their story of how they got into iOS development. Who wants to start?

I will start. I don’t know if technically I have an iOS job [chuckles]. I got a job at ThoughtWorks and we do a bunch of – I’ve worked in a bunch of different tech stacks at various points in my ThoughtWorks career. And then one day, I was on a project in Pittsburgh and I got a call saying, “We’re starting a project in San Francisco and it’s an iOS job or it’s an iOS project. Do you know any iOS?” I said, “Well, I’ve spent about two hours, no, maybe eight hours playing around in Xcode a year ago” and they said, “You’re the man for us.” So I learned iOS on the job, basically.

So you could spell iOS?

I could just about spell iOS. Probably at the time I wasn’t sure whether you capitalize the ‘i’ or not, so I could half spell it maybe. Yeah, so that was my story. I learnt on the job, helping this big bank in San Francisco build their iOS app or rebuild it. That’s how I got started I guess. How about you, Alondo?

I was a C# developer in Windows dev and I got involved in the local iOS dev group. What happened was I started working on an app volunteering for a conference that was being put on, and someone saw me committing code there and called me up and asked me if I was interested in joining their iOS development team. I sort of dipped my toe in iOS pool because I was interested in the platform, having just purchased an iPhone, and started from there.

Andrew, what do you have?

Well, long time listeners of the show know that I consider myself a Mac developer more so than an iOS developer, but I just got started doing Mac development in my spare time. I wrote and released an app that I still sell, a Mac app. And so when the iOS SDK came out in 2008, I was already a Mac developer – already a Cocoa developer – and I had an iPhone, and so I was really excited about it and applied to the Beta Program and got in.

I’ve been doing iOS development since the very beginning, but I was really a hardware engineer and I wasn’t doing development full-time. I did do some contract work and I was even able to maneuver to where I did a pretty serious iOS app at my job where I was a hardware engineer.

Then about three and a half years ago, I decided I wanted to do programming full-time, mostly because of the work environment. I wanted to be able to work from home, have a little more creative input into what I was doing and so I started looking for jobs and found a job at Mixed In Key, applied, and got the job.

It’s been a really great change for me, so I’ve thoroughly enjoyed the switch even though I miss hardware sometimes. But the job, the job environment and all of that has been really great.

Yeah, I think that’s one of the pluses of doing mobile development is, people that can actually do the work are hard to find, so people will work with you if you want to have a different working situation, if you want to do remote working, not in the office all the time, a contract, people are willing to work with you. That’s really a good benefit of being in this niche right now.

Yeah, absolutely. Particularly coming from my career doing hardware, it’s pretty hard to do hardware from home because you have test equipment and a room full of parts and lots of specialized tools, and you’re working on physical things a lot of the time. So software, and I think in particular mobile, for various reasons really blends itself well to the remote work thing, unlike most other industries.

Yeah, definitely. They don’t really want to ship out a half a million dollar test unit for you to mess with, have it in your house. [Crosstalk 05:18]

Yeah, I got to work on cool stuff, and I would love to have it at my house, but that certainly was not practical.

So Jaim, how did you get started?

I did some Mac work way back when – not a whole lot – but primarily I was a .NET, C# developer. I started doing way back when, doing embedded work, C, C++, but eventually that transitioned into .NET. I did client development, Windows forums, that type of thing.

Eventually that went away, but I was doing C#, backend, database type work, and I just went out as an independent consultant. I was talking to these people that were starting a project for this startup, and they were like “Yeah, we need some help doing some C# backend work, some .NET, MVC type work” and I’m like “Yeah, I can do that.”

I found out a little more about the project and there was an iPhone component to it. This was probably late 2010, and I remembered the Mac stuff I had done and I always enjoyed working with Mac, and I told them “Look, I’ll buy a Macbook if you let me work on the iPhone project” and they were like “Yeah, sure.” That’s how I got my start.

40] work I had and I wasn’t really doing a whole lot of iOS work yet, but I recognized that this is something that’s coming down the pipe. It’s going to be pretty big pretty soon, so I set my focus to get my skills up to it, up to what was happening, and went from there. Just picking work where I can get and doing as much mobile as I could – that’s how I got my start.

Did you gradually transition into [inaudible 07:06], all of your work being iOS, or did you just jump totally into iOS work straight away?

Yes. I had a three, four month project upfront where it was all iOS, and I’m like “Oh cool, I’ll do some iOS work” and there really wasn’t much and my net was really .NET’s enterprise type work.

Those types of companies weren’t looking for iOS work stuff at this point. IPad was still pretty new; I think iPad 2 came out, and that’s really what drove a lot of interest in iOS for the bigger companies. So I just took contacts that I could and did as much mobile work as I could with it, and gradually transitioned over, did some work on the side, and just found one full-time iOS gig I was at for about a year. That’s how I got into it pretty seriously.

I have to admit, I mostly just dabble. I do a lot of backend work for iOS, so I built APIs and I built stuff that integrates with the Apple Push Notification Service, and that’s my economy of words because I’m not talking very much.

I think as a group we’ve got the main groups of people that get into iOS development. We’ve got people coming in from the Ruby world; we’ve got the old school Mac developers, people that are doing enterprise C# stuff. We’re missing all the Flash people though, because Flash went away like [crosstalk 08:29]

You know what’s interesting? I was just thinking what we’re missing as well is Java devs. It’s kind of funny that there’s no one with that much of, like most of the enterprise-y, backend-y stuff is .NET rather than Java. I wonder if people who were doing Java and wanted to get into mobile tended to just go with Android. I wonder if more people tried to learn iOS development, found it hard, and tried to let to get to see and didn’t like that and then said “If I go and do Android work, then I can still use Java.”

I can say, from my experience and the teams that I’ve worked with – we’ve always done our native apps for both Android and iOS – one of the biggest gripes that I've heard is about Objective-C and just how difficult it is to learn and wrap your head around because of the syntax and some of the other things. And mainly from those Android developers who were Java devs that were interested in developing for iOS but they just really, really hate Objective-C. I’ve heard even recently, the joy in the introduction of Swift, because they think that now, “Okay, it’s one last hurdle for moving over.”

Yeah, I bet that’s pretty common. Although yeah, I’m hoping that with Swift it’ll be a lot more accessible for folks, like you said, that one hurdle will go away.

Does Swift change the market at all, as far as finding jobs goes?

I don’t think so in the short term, because I don’t know how many Swift projects are taking place where a company [inaudible 09:57] just saying was, we’re either shifting our code base over to Swift or we’re implementing. I know we aren’t; in no product that I’ve worked on, as you even mentioned introducing to it.

I’ve heard of one project that I’m aware of that started and they're using Swift but the reason they went into it knowing – they made a conscious decision to use Swift and they knew that it would be a while before – it’s a pretty big app, and they know that they’re not going to release for a few months. They’re expecting to have a few months to get up to speed and get the bugs out of the language and all the rest of it.

I’m going to guess that the Swift apps that are being built today, all the Swift programming that’s being done today, is all in Greenfield, almost all in Greenfield’s apps rather than people converting their current code bases over to be half Swift and half Objective-C.

Yeah, I’m aware of at least one large app that tried to go Swift, and they just backed out because it was not ready; it was not playing with the existing code very well. This was a month or two, three months ago, so it’s undoubtedly improved, but I haven’t heard a lot of big projects that have gone to Swift, or any, really.

I guess the question that Chuck was getting at maybe is, let’s say I’m a .NET developer today and I’m excited about getting a job in iOS. Do you think I should learn Objective-C or should I learn Swift?

That’s a great question. It actually came up at the recent 360iDev min I was at last week in Greenville, and there was a panel discussion and this very question was one of the questions asked. The consensus was that you still need to know Objective-C. The libraries, the frameworks, they haven’t been converted over, so if you’re going to be working with the iOS framework, you really do need to understand and use Objective-C.

That being said, as you mentioned, for Greenfield development and maybe products that are looking to see the light of day in the future, it definitely would be beneficial to start working in Swift and getting your bearings there as well. So I think it’s probably a little bit of both, but you definitely still need to know Objective-C now.

Yeah, so I’ve been thinking about this and I’ve seen quite a bit of discussion about it online, and I think another thing besides just the frameworks being all written in Objective-C is that if you’re planning to work with a team and get a job doing iOS development, you’re almost certainly going to be working on existing code bases that are in Objective-C, that are not going to be converted to Swift any time soon, if ever.

So I really think to be an effective iOS developer, you’re going to need to know Objective-C for quite some time. I think eventually, the move to Swift will probably be mostly complete, but it’s a while yet, I would think.

Yeah, if you know Objective-C and you know C#, Swift is not that hard. Swift is mainly going in this direction that C# has already got, has already been in. A lot of the things I was missing, coming from a C# background, are there in Swift. So I don’t think if you learn Objective-C, you’re cutting yourself off of learning Swift. You already know a lot of the concepts. That’s true for anyone coming from Ruby, Groovy or any more modern type languages.

Yeah, I guess even just from a practical point of view, if you were interviewing for an iOS job, the person who’s interviewing you, the odds of them –. Let’s say they give you a coding problem and you start solving it in Swift, I’m not actually sure the odds are that high that the person interviewing you is going to be comfortable reading Swift, they might say “Hey, can we do this in Objective-C because I don’t know Swift?”

But aren’t they going to want you to have a few years of Swift experience?

That’s the hiring manager, and then the recruiter.

The recruiter is probably going to tell you about this exciting Swift-based Android app that his team has built. [Chuckles] It’s a great opportunity looking for backend Swift developers. [Chuckles]

If you’re looking for an iOS job, where do you go? How do you find one?

In San Francisco, you stand in the street stationary for about two minutes, and then a recruiter walks by, and then they say to you “Hey, you look like you’re a developer! Do you want an iOS job?” and you say “Yes!” and then that’s it, you’re done. It’s easy. Don’t know what you guys go upset over.

Well, if you’re not fortunate enough to live in San Francisco, I will say, in my experience, one of the things you can do is definitely connect with your local Meetup iOS developers user group, or CocoaHeads chapter if there’s one where you are.

In my experience, at least in the South East, in the Meetups that I’ve been to, recruiters tend to frequent those and even sponsor those in a lot of cases, so it’s a great place to kill two birds with one stone. You can meet other developers in the community and you can meet with recruiters who may actually have openings at that time looking to place people.

That’s a really good tip actually. That’s much more helpful than my stupid joke.

Yeah, and fortunately there is a range of ethics with recruiters, so Pete’s method may not get you the best recruiters.

Yes, yes.

Alondo’s method, I think, will probably get you a better recruiter to work with.

Yeah, actually in all seriousness, if I was looking for a new tech job, I think the biggest thing that I would look for is a good recruiter that I trust, and I think probably if it was me, I would ask around my network of developer friends for a good recruiter. I actually just did this for a friend of mine who’s moving to the Bay Area, an export worker who wants to work at a good company. I posted on Twitter “Any dev friends know of an actual good recruiter?” and I got a good response from some people.

Also, not only are recruiters present there that’s a secondary benefit of connecting with members of a community, there are a lots of independent development projects that need extra help, and that’s how I got started. I just wanted to reiterate that there’s opportunities if you are looking just to do freelance as well, connecting with the groups is a great way to do that as well, because a lot of those developers are independent devs and do contracts for clients, and they just need someone who can chip in to help implement a particular feature or something like that.

You talking about moonlighting, nights and weekends type stuff?

Absolutely! If you just want to get your feet wet, I’m working on several projects where we brought someone in just to get ten hours a week done, just because we didn’t have the bandwidth or to implement a particular feature. Say for instance, you have an interest in AV Foundation or you have strength in that area, when we need someone to implement a particular feature or implementing that framework, I would bring somebody on just to do that short term type of work as well. So whether you’re looking for long term employment, or you’re looking for a way to get your feet wet.

And the third way I would say is volunteering, because that’s how I got started. I just chipped in on an open source project to get something done, and there are people sometimes that are doing presentations surrounding a particular pet project that they have, and you can volunteer. If you’re concerned about not having any experience, then it’s a great way to build your portfolio and get experience and good real-world experience developing on a platform.

Yeah, that’s a good point. I think a lot of people started doing nights and weekends working on their own projects. If they’re lucky they can get paid to do stuff like that. I had created a startup out of a startup weekend, and I didn’t really do any iOS work on the actual project, but after everyone dispersed on the application and I was doing nights and weekends moonlighting, trying to keep things up to date, making changes with the web service, and doing that.

So that’s why I got a lot of the base skills in Objective-C, because my first project with iOS was Xamarin, but back then it was MonoTouch, so I was doing C# and I was still trying to getting my head around Objective-C, but I was able to do it working on a project, moonlighting nights and weekends. The market is good enough where if you show just some aptitude, people will take a chance on you, and if you’re a good developer, those skills translate over.

I think that’s really good advice. I started the same way at Mixed In Key. I had been working nights and weekends on my own stuff, and that’s how I really learned Objective-C and Cocoa development. But even when I started for Mixed In Key and wanted to move to a real job, for the first few months I worked for them on Saturdays and in the evenings, and they were open to it because they needed help, and then I transitioned to doing it full-time. I think that’s actually fairly common, and it can work out really well for both parties.

I guess the benefit there as well is you can develop a portfolio if you will, so that when you’re going to another company to try and get your first job, you can show them “Yeah, I built this app or I helped with this app” and you’ve got something to talk about during the interview process and all the rest. I think open source is ideal for that, because if you think you’re any good, then you can actually show code ahead of time in the interview process and show that you know this stuff.

I actually think that’s – something that I’ve noticed and also something that we do at Mixed In Key when we’re looking for people is, I think a lot of iOS jobs, probably even the majority, they’ll list in the job requirements. One of the requirements is that you have to have an app on the App Store that you’ve worked on. Of course there can be exceptions, you’ve done a bunch of Enterprise Development that’s not on the App Store or whatever, but the point is they want to see that you actually know how to write an app, not just you’ve played around a little bit or whatever.

I think even better is you can show code that you’ve written. I’ve talked to people who are looking

for someone to do iOS development, and it’s not uncommon for them to say “Do you have any code? you can share with us so we can see what kind of code you write.” So if you have that, it can be super valuable, and I agree that open source is a great way to build that kind of a portfolio up.

I agree with that. That’s one of the things that, in the past we’ve done interviews, we’ve always asked for a GitHub I'd just to check and see what kind of contributions have been made by a candidate. It definitely gives people a leg up when this time to determine who to call and talk to further.

I guess that the challenge for people hiring is not using that as a way of excluding people that don’t have the time or the disposable income to just hang out and do open source work. Do you know what I mean? I guess I’m particularly sensitive to this because I live in Silicon Valley that’s full of programmers and a bunch of white guys dominating the industry, but if you’ve got less disposable income, then it’s harder for you to spend time working on open source and if you’ve got spare time, you need to be making money with your spare time. But I still think that there’s ways that you can do that and demonstrate capability.

Yeah, so even in the situations where he had a candidate that didn’t have open source projects and they may have temporarily just let us look at some project they were working on, giving us brief access to just review the code base, and making it private again.

Have you been involved in the interview process or the recruitment process for the candidates? I don’t know if this is more of the focus, for employers rather than people trying to get a job, but what’s some good ways that you can think of for finding a good iOS developer? What would you use to try and filter out people who don’t really know what they’re doing versus your next awesome iOS dev?

We’ve done this recently in Mixed In Key, and our experience typically in the past has been that it’s actually really hard to find somebody that’s really good. We might interview thirty people and find a couple of those seem like they’re really going to work out.

But one of the things that we do – I don’t know how typical it is and there are people that complain about it, but we actually give a code challenge. It’s like a simple problem and it’s timed so you have an hour, although we’re not really strict about the time. We just say “Write an app that does this” and the requirements are quite simple. Any experienced developer should not look at it and be like “Oh, what the heck is this?” It’s a pretty straightforward kind of a thing and pretty typical of normal development, and what we really want to see is the code that they write. Do they know how to write a simple app that is written well but isn’t over-engineered? The code’s clean but they haven’t gone crazy on design patterns that really weren’t warranted for such a simple problem, and that kind of thing. We found that you can tell a lot about somebody just by reading a little bit of code that they’ve written to solve a problem.

Yeah, I totally agree. We do something similar at ThoughtWorks, except we have, it’s like a takehome assignment I guess. We send someone a choice of three different problems and then they have a week, I think, to build a solution and then we do a code review. The nice thing about that is it also forms the basis for in-office interview; so we have something concrete that we can talk about with the candidate, and it’s their code, so they know it, so they’re comfortable talking about it, rather than coming up with some abstract problem and saying “How would you solve this problem?” You can find an existing problem in their code, because no code is perfect, and talk through their code and how they would improve their own code. It works well for us.

We’ve definitely done that. I’ve actually taken one of those as well where it’s been a take-home and I had a week to finish it. In addition to that, we’ve also done pairing sessions with candidates as well. One of the reasons why we’ve done that where I’ve been is that we wanted to get a feel for what it’s like to work with someone.

I don’t pair as much in my current job, but we did a lot of pairing on my previous place of employment and since it was such a large component, just the team dynamic is such a big component, we made that a part of the process as well. So spending thirty minutes to an hour actually working on an existing bug or feature in the backlog with a candidate, just to get a feel for their approach to problem-solving.

I agree with Alondo in the sense that once you can establish they have a baseline skill level, how they are to work with, becomes way more important to me.

Yeah, it’s hard to tell if someone knows what they’re doing, but even harder in an interview, to tell if they’re easy to work with. They become bad at about every little thing.

Yeah, absolutely.

You don’t find that out until they’re on the job, and they’ve been there for a couple of weeks and actually get into code, at that point you’re too late.

Yeah, there’s no perfect hiring process that will tell you whether or not they’re the person you want. You find that out, like you said, within a few weeks of them coming on board.

One of the other things that we do earlier in the process too though, is that when we’re interviewing someone, we talk about – some places tend to ask these rote questions about frameworks, or View life cycle or things like that. I like to ask questions that let people talk about their experience in a particular area, just to get a feel for what their experience level is with that, say for instance, core data or some issue that they’ve had with View life cycle or a particular challenge. What I really look for a lot of times is just their ability to speak about a particular area directly, pitfalls – I always like if I can hear tips. [Inaudible 24:17] You may run into this issue, because that means that they probably dug a little bit deeper into a particular area, and not only for expertise and knowledge of everything – of course, because that is impossible – but just want to get a feel for competence and they’ve got a few scars from development.

I guess that leads into – you mentioned a couple of things there, things that you would expect a candidate to know, like View life cycle and core data. If I was a .NET dev that wants to learn enough to get through the interview process, not in a cheesy way, but learn enough so that they can have a conversation to get into a first entry level job. What stuff is there that you would expect every candidate to know, even if they’re relatively new to the world of iOS?

I usually push them to the point where they have to tell me they don’t know something. [Laughter] Just because I hate the people that are going to go in and screw up my project, because they think they know the answer, they think they can fudge it, when in all reality all they have to do is go ask somebody.

Second order ignorance is the worst, when you don’t know what you don’t know, that’s when you really screw things up.

Yeah, I think the same thing. I've typically asked questions that I knew that even a really good developer might not know the answer to, and the answer I was looking for was not the answer to the question. It was “Oh, I don’t know” and then maybe we talk about how they would figure it out or whatever. But the point is I don’t want somebody who just bluffs or makes things up as they go along.

I once interviewed at Google, and one of the phone screen questions they asked me was to write a regex that would match every possible regex. [Laughter] I’m pretty sure they weren’t expecting me – well I know they weren’t expecting me to write it because technically it’s not possible. But that was a good example of, I’m hoping they were expecting me to say “I’m not sure how to do that” because that’s what I said. [Chuckles] That was actually really funny to me.

But anyway, back to your question. What skills do you look for people to have?

I think the big question is, we talked a little bit about Swift versus Objective-C, what about Storyboards versus Non-Storyboards? A lot of the ways Apple is leading us to develop is Storyboards. I think most of the bigger apps out there aren’t using them, or haven’t been, if they started three to four years ago.

Yeah, that’s the challenge, is depending on when someone started doing iOS development, they may or may not have exposure to certain techniques or tools. Someone may be used to building Views [inaudible 26:44], or using nibs and not using Storyboards, and they may still be [inaudible 26:47]. I actually know people who are begrudgingly, even now, using Storyboard, so they wouldn’t know anything about them, or people that only know ARC and weren’t developing pre-ARC or not escalating with some of the memory management issues.

Yeah, I forgot one – there are Storyboards, nibs and also in code, which was very common, if you look at something from four or five years ago. So there’s a lot of ways you can work on an app and have no clue how the rest of the world is doing things.

I guess the way that I think about it is most of someone’s working life, or most of the time they’re going to be working at a job, the main thing you need to be able to do is to be good at learning things rather than have knowledge, but I do think there are some key things that you would expect everyone to know.

I think View life cycle is a really good example. I almost say ARC is a good example as well. If I was looking for a senior iOS dev, I would want them to be able to talk through with me, or at least try and talk through with me how ARC works under the covers, explain reference counting and why you need to do it and that kind of stuff. Even if you don’t need to do it in your day-to-day job, if you’re a senior dev or the lead on a team, then you need to understand some of that internal stuff so that you can get to the bottom of some hairy issues.

Yeah, it doesn’t matter what you’re doing, you should be able to know how to create a Retain Cycle and how to avoid those.

Yeah, and I can tell you from experience that that’s one of the first questions Apple will ask on a phone screen, a phone interview, is “Can you explain how Objective-C’s memory management model works?” and they don’t want you to say “Oh, it’s ARC. You don’t have to worry about it.”

It’s magic!

But ARC is perfect!

It’s garbage collection. You don’t have to think it, right?

Well, that’s the wrong answer. [Laughter] But I think speaking about Storyboards, and Storyboards versus nibs versus code, some of that to me is almost like a religious choice. I mean there are people that are really adamant one way or the other, and I don’t actually care that much which one they use or which one they know how to use; I really care more about whether they’re going to integrate well with the team and be willing to make decisions as a team and to adapt their personal view to whatever the team decides on, and not be difficult to work with or dogmatic. Because we’ve had that problem before, and it’s way more of a problem then the person having this opinion, is that they’re dead set on their opinion being right.

I actually think that, my observation having been in a few different communities, is there’s an aspect of that that’s more prevalent with Apple and iOS developers. There's that kind of classic developer arrogance, like “I know the right way, and it’s just going to take you a while to come around to my one truth that I know, and everyone else is not quite smart enough to understand you.”

Yeah, and that really doesn’t work well, just in terms of interpersonal politics or whatever, it doesn’t work well on a team that’s just trying to get something done and ship an app.

[Crosstalk 24:45] listening to your elder is the best approach, I find.

Yeah and you had a good point, where it doesn’t really matter what you’ve done in the past – a good developers going to learn whatever he needs to learn, so that’s been a more enlightening perspective. Unfortunately, you get in interviews, and people have that dogmatic approach; you need to understand these type of things, they don’t really –. It’s hard to figure out if someone can learn or is open to a different approach. I think some of the techniques you talked about will help, but if you had to pick one to go with, to build up your skillset, what would it be?

I will say that in interviews I've done, I have asked about manual reference counting in particular. I really sort of want to hear that they understand how that works and I'm not that flexible about it. If they say, “Oh I don’t know anything about that, that’s a pretty big red flag to me.”

I would say, if you're a post-ARC developer, you started after ARC, you don’t need to go write an app using manual reference counting only, but make sure you understand how that works. I think the same is true of sort of the other underlying technologies like – there are a surprising number of people who don’t understand how Objective-C properties work, and I know those aren’t new anymore, but I started writing Objective-C before properties were a thing, and some people think they're just sort of magic. They're not really magic; they're similar to ARC. They're just – the compiler doing things for you that you used to have to do yourself.

So sort of trying to understand some of the low-level underpinnings of the things that you take for granted. I think it can be really helpful in showing that you actually care and know about the technology that you're using.

Are people still saying, “Properties are evil?” Dot notation? Or has that kind of faded away?

Yeah, they probably are. I'm not even talking about dot notation; I'm talking about the actual app property declarations and synthesized accessor methods, because there was a time when this just didn’t exist. You wrote your own accessor methods.

But as far as dot notation versus bracket notation, to me that’s another religious thing and – I don’t know. I can see having a strong opinion, but being unwilling to bend to your team’s code standards or code style is not really a good thing.

Yeah, you don’t want to hire someone who spends the weekend converting the entire code base from one to the other because they believe it’s a better thing to do.

It’s good to be able to identify what the holy wars are in iOS and talk your way around them.

Show that you're open – and I think Andrew’s got a really, really good point. You want to show that you're open, that you have an opinion based on some logic, but you're open to changing that opinion. Or even like saying, “I don’t really agree with this. I think it would be better if we did it the other way, but I understand that we’re a team and it’s more important to the team that we have consensus than for me to get my way every time.”

Yup. The sun’s still going to rise tomorrow no matter what we do.

Well apart from tabs versus spaces, if you use tabs then the sun’s not going to rise [chuckling].

As long as you don’t mix them up.

Thank them for that when they come up.

Yeah, [chuckles].

So we’ve talked about figuring out if somebody’s a good fit for you to hire. If you're on the other end, how do you figure out if the company is a good fit for you?

I think that’s really a good question, and I think some of that comes out in the interview because you get to talk to hopefully more than one of the people, but at least one of the people that you're going to be working with.

But I think what we talked about earlier can be really helpful, which was – I started at Mixed In Key kind of doing it as a side job, just doing contract work. I got to learn a lot about the team and the stuff that they work on and the way they work together, so by the time I decided to quit my real job and do that full-time, I already knew what I was getting into, so there wasn’t a lot of uncertainty.

I think one measuring bar is taking a look at what happens during the interview process. Are they asking questions like the ones we’ve been talking about? Because these are all solid advice. Or are they asking trivial things? Are they doing stress interview type of questions? If they answer a question and half the room – you're talking, they immediately start typing with their keyboard, that’s a stress technique. That’s meant to find out how you behave under pressure. If companies are doing that, walk away. There's going to be a problem.

Yeah, I would definitely agree with that. I think another thing is, as the person being interviewed, don’t be afraid to ask questions. Usually an interviewer will say, “Do you have any questions for me?” At least in my experience, they want you to ask questions. It’s not something like you have to say, “Oh no, everything’s good.” Ask questions.

I definitely consider that a red flag if someone doesn’t have a single question to ask. That’s weird [chuckles].

Well the thing is is that your best employees are going to be the ones that are happy working at your company, and so if they are not making sure they're going to be happy there, then you're running that risk. I think that is a red flag; I think it’s something to be aware of.

I always describe the interview process as both you're interviewing the company and the company is interviewing you. It’s as important for the company to make sure you're a good fit as it is everything else, and the only way to do that is be pretty transparent, I think. If you can’t get a good feel for the culture of the company, then it’s really hard to know whether you're going to work out there even if you're super smart and they're going to pay you a bunch of money, if they're just not aligned with you, then it’s tough.

I interviewed at Google, and going back to that thing that Andrew said about looking at what questions they ask or how they interview – I think that was Andrew – they spent eight hours just grilling me on algorithms and coding problems. They spent maybe one hour talking about process or how I work with a team, or how I'd work in a team, and I left that interview process thinking, “Jeez, they do not care at all about the act of building software; all they care about is algorithms and data.”

I think if I was really into that kind of stuff, then I'd be a great fit. But I care about more than just writing algorithms, so I decided that wasn’t a good fit. And then they turned me down so it worked out great [chuckles]. They fired me before I could fire them.

I think it’s important to understand the culture and the environment you're working in. As you said, you're interviewing – I am always disappointed when I'm doing an interview and the candidate doesn’t have any questions at the end, just because I know if they're younger or they're junior, they tend to be a little more nervous and they tend to not have questions, but it’s important if anyone is listening. Please, ask questions.

It’s tough when you're interviewing because the companies are putting their best foot forward as well, and so you don’t really get a feel sometimes for where that project has been unless they're transparent, the state of the code base, what management’s like there, what the processes are like, if they're not forthcoming with that information.

One of the tricks that I used to do is ask the same question to multiple people and see if they gave me roughly the same answer. I would decide what I thought the biggest risk was in terms of the job, like what was I most scared of turning out to be true once I got there? And then I'd figure out some kind of question that would help answer that, and I would ask that same question to every person interviewing me and see how lined up they were. If I was worried that the company tends to do death marches and doesn’t value work-life balance, then I'd ask person interviewing me that same question about, “How often do you guys work more than 40 hours/week?” or whatever. If the answers are inconsistent, then that’s the big, big red flag because it’s like they're kind of aware that it’s a problem and they're trying to cover it up.

That’s a good technique.

Mm-hm.

That’s a good point. When I was 22, coming out of college, I had no concept of how to interview a company. Asking questions like that makes perfect sense. Are you working a lot of weekends?

How is the code base? [Crosstalk 37:27]

Yeah, and it’s kind of funny, right? I think particularly more junior people or people that haven’t interviewed that much do feel like it’s a one-way thing and the questions they're asking are supposed to be to show that they're a good candidate. “Will I be challenged here? Because I really like being challenged.” But actually, I'm very happy to say, “What's the biggest problem you guys are facing right now?”

One of my favorite questions I used to ask was “Why would you leave this company?” Like, what's the thing that you can see making you leave? It’s direct enough and it’s hard enough to widdle around, that you tend to get some good insights from the people that are interviewing.

It’s also a good interview hack to get the interviewer talking about themselves. It makes them feel like the interview went better even if you're not even talking, kind of a relationship hack.

Wow, sneaky.

Yeah.

Make them think about ice cream as they're leaving the interview. [Chuckling]

One other thing I've done if I have a lot of time is I've asked if I can just sit and work in the office, just be around for a while, and you'll pick up a lot of things about who gets along with who and who’s happy there and who’s not happy there. You'll get a lot of good reads on the dynamics of the company that way.

Yeah, the bare minimum you can ask – I think you could almost always ask to have a tour of the office while you're there and just kind of –. You can pick up a lot by, is everyone sitting there with their headphones on? Are people laughing? Are people crying?

That makes sense. And if you're only talking to HR and a hiring manager, you probably want to talk to some people on the team that you'll be working with and get the inside from them, because it is easier to paint a rose garden if you're not actually doing the work. The people on the team have less incentive to feed you falsehoods.

That’s true. HR may not even be aware. I mean, a lot of times, they're not privy to the day-to-day operations at all.

So I've got a question which I honestly would love to know the answer to because I have not been very good at it. Assuming you do good in the interview process and you might be getting a job, at what point do you negotiate salary? I think all developers are crap at this kind of thing.

I would agree. I've historically been very bad at this. I've gotten better over time; now I tend to – once an offer’s made, it’s at that point that I'm willing to have that discussion. I've learned even from working with recruiters to not answer that question before an offer is made. I may talk about a range, but typically it’s just depending on we can negotiate or something like that. But once the offer’s on the table, then we start talking about the salary.

Yeah, I would suggest you should at least get the range very early on, because it may be something you're willing to work with or something you're not willing to work with.

Yeah. One thing that I found as a freelancer and as an employee is that if I can sell them on myself first – so they know they want to hire me, they know they want to bring me on – then talking money later on, they're more willing to bend over to make it work. They're willing to flex to make it work because they know that they want me. And so it’s not about “Okay, does he fit within our range?” it’s “We got to have this guy, what is it going to take?”

Definitely I'm a consultant, so I'm not an employee, and I definitely agree with what you're saying, Chuck. I think most positions, they’ve got their budget and that’s what they can spend.

Yeah, but if they really want you, they’ll still go to bat and try and get you, and then if they really can’t do it then they’ll come back and try to negotiate with you.

There's also stuff you can negotiate beyond just salaries. You can negotiate how many days of time off will you go in starting with – all that other stuff that doesn’t even occur to everyone is negotiable.

I guess a lot of it is negotiable if you asked.

And the answers from that negotiation are also very valuable feedback. If they're not willing to give you vacation days like you had at your old job, you might want to think about that company as a whole.

Have any of you guys had any experience with folks coming out of hacker schools? Like these intensive programs? Maybe that’s an option for someone who wants to get into iOS development is throw down a bunch of money and do one of these intensive programs.

There are a bunch of hacker schools here in Salt Lake City. I've talked to several people coming out of them doing JavaScript and Ruby, not as many doing iOS, but it seems like the main issue that they have is experience. They come out of there having done three or six months of intensive training, and the company’s just not sure what level of experience they have, and therefore they're not sure of their value.

A lot of the stuff that we discussed at the beginning of the show really comes into that, and go out there, put yourself out there, find some projects, get some stuff done, put some code behind your name and it will pay off for you, I think a whole lot better. That’s not to say that is not a good option; it’s another way of learning the skills. But the ones that guarantee you a job, they either have terrific contacts out in the community, or they're just hoping that they're right.

Yeah, I agree with that. I don’t have any direct experience in terms of hiring or working with somebody that’s gone through one of those schools. I just really think there's no substitute for experience. I don’t think they're a bad option for learning the stuff, because – I mean, I taught myself from books. If you can learn that way, you can certainly learn from people who actually know what they're doing and hopefully the people teaching at those do. But you don’t really know what you are actually doing until you’ve just done it for a long time and made mistakes, just like any other skill. So I would be weary about somebody who’s just graduated last week, and now they want a job. I think maybe they would be – maybe as a junior position where they understand that they’ve got a lot to learn and the company hiring them does too. I certainly wouldn’t think they'd be ready for a senior or even just mid-level developer job.

Yeah, I think it comes down to how much resources a company has to babysit what they're doing and provide mentoring, because you're not going to be a senior-level developer at six months; this is not going to happen, but you can do a lot of things. You can change techs, you can fix things, and if you have supervision and some mentoring, they could probably be a useful member of the team. But you need that in place in your company, and a lot of companies don’t have that – or have any [crosstalk 43:32] how to do it.

That’s actually a really good point for someone who’s barely junior. One of the things you should definitely be trying to figure out when you're interviewing with a company is how they're going to support you like growing into a strong developer. As a consultant, I get to go to a lot of companies and see how they do this, and it is shocking – SHOCKING – how bad some companies treat their junior devs in terms of support. They just kind of throw them in a problem and just assume they’ll learn and it’s such a waste. Devs are not going to get up to speed as fast; the company’s going to be paying them to not be very good – it’s crazy. So I think that’s a really important thing to look at when you're interviewing, is how they plan to support you growing into an awesome developer.

This kind of leads into another question: what does your ideal job look like? Or what things in a job make it the most fulfilling for you?

Actually in my experience, I like challenging work, but a big bonus for me is working with good people. The team has become such an important thing for me in the last few years of just doing development.

When I'm working with people who I can learn from – and they not necessarily just have to be more senior or more experienced, but just coming from a different background or just bringing a different perspective, I find that really refreshing, and I like starting a new day. Even if sometimes you get into modes of work where it’s not the most innovative work or something like that. If you're working with good people, it makes a huge, huge difference.

I totally agree with that.

That’s my biggest factor too is the people I work with. But the problems and everything else kind of – they matter, but they don’t matter as much to me.

Yeah, I completely agree with that, too. The team I'm working with is as important – if not more important – than the work we’re doing. Which is not to say that reasonably challenging, but not too challenging, interesting, cool work is not important, because it is, and you can have all that. If the people you're working with are not fun to work with, it doesn’t really matter.

Yeah, definitely. If a team is collaborative, that’s a huge benefit for me. If everyone’s on a team but just does their own thing and doesn’t really talk to each other, that’s hard for me to work with. I do a lot of work by myself regardless, but you might as well be working by yourself if your team is just heads down.

I think the other thing for me which kind of is related to this is I want a job where I can keep learning. I want an organization where I'm not the smartest guy in the room and where there's enough variety in the work I do that I keep wanting to get out of it because it’s not the same old, same old. I'm always like, I feel I've learned something every month. Or every six months I could look back and say, “Oh that’s cool. I didn’t know CoffeeScript before; I didn’t know core data,” or “I didn’t know how to do design and now I kind of understand the fundamentals of design” and that kind of stuff.

Pete, that was a great point. [Inaudible 46:15] said earlier about when you're evaluating the benefits, more than the salary, what types of ways as a company support your learning? Are they open to letting you – do other people get to work in different teams, different projects? Training, conferences, all those kinds of things, I think play a big part in sort of supporting your growth and learning.

Yeah, and it’s really easy – it’s very easy to find out just the fundamental kind of culture in the company. You just ask what's their policy for supporting people learning, and a good company will say, “We have a budget for people to go to conferences and we have a book program, and we have these five things.” A bad company will be like, “Well, we do think it’s important and we do encourage that” like they don’t have anything in place; they just think it’s a good idea but they don’t really have anything behind thinking it’s a good idea.

Pete, I think it’s a good idea [chuckling].

Glad to hear that, Chuck.

Of course there's the corollary that the startups probably don’t have a program like that, but you will automatically get thrown into all sorts of [inaudible 47:18] things that you can work with.

I don’t know though. That’s kind of true, but it’s kind of not true. A startup that’s moving – particularly a startup that’s successful and is moving really fast and growing really fast, if you go in there as an entry-level person, I wouldn’t be that surprised if you just get thrown into a corner and just asked to do just really boring, unchallenging stuff, and no one’s got time to skill you up and no one’s got time –.

It’s like this kind of local optimization where people don’t have time to teach you these things so you're going to just stay – all you can do is JavaScript and CSS or something.

Yeah, but most startups that I've worked with are self-aware enough to know that they don’t have time to bring up the junior devs, so unless they have a whole bunch of work that a junior dev could do, they're not even looking for them.

Yeah. I don’t know, maybe it’s – I think, again, this might be just like a Silicon Valley thing. There's such a need for developers that I think there's more of an appetite to just say, “Just bring in a junior developer and they’ll get up to speed.” But then if you don’t put anything in place to help them get up to speed, then they're not going to get up to speed.

Yeah, I agree. I don’t think that’s just a unique Silicon Valley problem; I've actually seen it happen here in southeast as well.

Yeah.

Yeah, I was talking about cases in my career where I've been working on doing one aspect of the code base and the company [inaudible 48:34] do something else and don’t know how to do it. I'm like, “Oh I can do that” and I had to figure it out – a way I could expand my skill set. So it’s worked for me, and this was in smaller companies. Startups, but maybe not the Silicon Valley thing that you were talking about.

Yeah, I think that’s true. If you’ve got that attitude of being excited to learn and you want to grow your skills, then a startup is definitely good. Like you said, there's always stuff that needs to get done and if you're a self-starter and you'll put your hand up and volunteer to do stuff, it’s a great environment to do that, way more so than in some big enterprise where it’s like “Oh this is not part of your role to be touching the CSS – that’s a different department, so you have to stay doing whatever it is that you're doing today.”

Yeah, but don’t be – I don’t want to get anyone in trouble in their job, but generally, don’t be afraid to jump in and volunteer to be involved in those things. Because I found that it really does pay off and you wind up developing another skill that you can use later on.

Anything else before we get to the picks?

No, let’s proceed!

Alright, Alondo. What do you have for us?

Okay, I have two picks this week. One is I've started using a different tool for testing RESTful APIs. It’s a tool called Paw from Lucky Marmot. I think I'm pronouncing that correctly. It’s a really nice tool and I just found it quite useful. I'm trying to think about the cost; it’s available on the Mac App Store but I can’t remember what the cost is. There's a free 10-day trial though, so you can give it a show. This is version 2 of Paw.

The second tool is a tool I was introduced to by a friend at the 360iDev min last week, and it’s Faux Pas for Xcode. It’s an analyzer, and it’s apropos of today’s subject because working as a team, one of the things that we try to make sure we do is have our coding standards adhere to when we’re doing our code reviews, and this is a tool that’ll help that. You actually can analyze the code and actually set for your code base basics, standards that you want to adhere to than the rules that you would like to be applied, so it makes it a lot easier to stay in compliance. If you move from project to project, of course it makes it a lot easier too because not every project has the same rules. So the Faux Pas app for Xcode is my second pick, and those are my picks.

Very nice! Andrew?

I just have one pick today. It’s the Core Intuition Jobs boards. Core Intuition is another iOS and Mac developer podcast by Manton Reece Daniel Jalkut. The reason I'm picking this is because we've talked about jobs today, but also because we found the last Mac developer that we hired at Mixed In Key through a posting on Core Intuition board.

To be honest, we got a way lower response from our posting on Core Intuition than we did on some other job posting sites, but they were uniformly higher quality. All the people we got that responded actually seemed really good, so I think it’s a high quality sort of narrowly-targeted jobs board. There are some cool posts on it right now, including a bunch of jobs from Apple. So that’s the Core Intuition Jobs board. That’s my pick.

Chuck, what do you have for us?

I've got two picks. The first one is, if you're a freelancer, my friend Eric Davis is starting a new mailing list called Freelance Chi and it’s a weekly email. It has a bunch of links and articles related to freelancing, and it looks really good. I believe I got the first one and I was pretty excited about what was in it, so that’s one pick.

The other pick is that if you listen to the show and you like it, I am looking for more sponsors for the show. If you know of a company or a tool that you like that you think might be willing to sponsor the show, please let me know. If you are a listener and you work at such a company, then also please let me know so I can reach out to the right people and see if we can get sponsorships gong for the show so that we can pay for all the costs related to putting it up. That’s all I got.

Pete!

Before my picks, Chuck, how would someone let you know? How would they get in touch with you?

Chuck@devchat.tv.

Great to know. Okay, moving onto to my picks. The first one I can’t resist because it’s just so tempting. Thoughtworks.com/join if you want to come and work at ThoughtWorks, then come and find out what a wonderful company we are, speaking of jobs.

16] of perspective to all of the fluffy puppies and unicorns kind of stories that I keep on hearing about hacker schools.

My third pick is a book called Being Geek. If you know the Internet celebrity Rands in Repose, this is a book that he wrote. It’s kind of a collection of his blog posts, essentially, a few years ago. The reason I'm picking it is it’s a really, really good book in general. It’s basically about – it’s a software developer’s handbook, and it’s about essentially how to do stuff other than actual software development. He has loads of good advice around interviewing and negotiating salaries and leading teams and all the kinds of stuff that is tangentially around the job or the life of being a software developer. I really, really recommend it.

Then my last pick is another job board – Slack at Work. Slack is this kind of chat thing that got really trendy recently. They did this really interesting thing; they just made a website that’s free for people to post, and if you're a company that uses Slack, then you can list jobs on their job boards. Essentially, it’s like, “Oh well I like Slack, so I want to go and work at a company that uses it.” Kind of a wacky idea – I have no idea whether the jobs are any good or not, but I just wanted to pick it because I thought it was kind of funny. That’s my picks.

Thanks. Yeah, I've been using Slack with one of my clients and I'm enjoying it quite a bit.

I've got one pick. Chuck talked about a freelancer’s email list; many of us are probably on the iOS Weekly email list. One thing from last week, we talked about Swift and should we go to it. It’s always interesting that we defined out, get people’s perspective on whether we should go to Swift or not, but there's one article from a Near the Speed of Light, and it talks about Swift. It’s always good to get other people’s perspective, so I thought it was a good post. That is my pick.

So I guess that’s it for this show. I think everyone’s ready to get new jobs now; I hope it helps people out. We’ll see you next week!