So one of the most popular questions from interviewers at Demo Day was, “What’s next?” That one was especially easy to answer; the next step, of course, is to make sure we keep learning. An important step in that process is making sure that we get jobs where we continue to be challenged to take on brand new problems every day, and in order to land that kind of job we’re going to need to not just brush up but polish, varnish and shine our problem-solving skills.
It has been an incredible ride at App Academy. I can’t believe it, but the nine weeks of heads-down, full time coding under Ned’s mentorship have finally come to a close. You can see what I ended up having to show for it here! I was going to say that I am going to really miss coming in and working with this bunch of people, but I don’t exactly have to do that yet. As all of us know that finding the right job is going to be a difficult, demanding task, we’re all inclined to take it on together and help each other out in preparing for this daunting endeavor. Yesterday, our first Saturday after the Big Day on Friday, we already met up at one student’s house to talk about data structures and to practice whiteboarding problems in front of one another.
There’s no stopping us, really. The class may be officially over but the momentum is so intoxicatingly high that through sheer inertia I’m not at all compelled to let up the pace. But in terms of closure I can say that during these nine weeks of non-stop long days in San Francisco programming with some of the brightest people I’ve ever worked with, I’ve learned so much more than I could have imagined, not only from the jam packed curriculum and the awesome leadership, but also from the wonderful variety of perspectives imparted by the students with their eclectic range of experience and backgrounds. I am going to miss coming in to ‘the Office,’ but I think it’s best to focus not on what we’re losing, but on what we can take with us.
Also, I’d like to really thank our instructors and TAs, Ned, Kush and Jonathan for their amazing patience and uncanny ability to explain things to us and answer our unending questions about programming over the past nine weeks. I’m grateful to all the smart and fun people I worked with; you can check them out here or here for some background. And all the cool companies who took the time to come in and talk to us, either throughout the course or at Interview Day. I had an amazing time meeting and discussing different real-world challenges and opportunities. Anyone with any ideas on how I’m going to keep on my toes, get in touch!
Interview Day at App Academy
One. The Programming Interview: Keep Talking.
Today is going to be our last day of class, and as though finishing our projects wasn’t exciting enough, last night we also got a taste of the interview process. Ned and Kush gave us a little talk about what to expect in technical interviews, and how we ought to handle it when things get tough. Here are the main lessons we took out of it:
- Clarify. Before jumping into a problem, ask questions until you know that you’re on the same page as the interviewer and you understand the prompt.
- Keep talking. While writing code on a whiteboard or paper, whatever you do, even if you have to stop coding in order to think, do not stop explaining your thought process. This gives them a chance to give you hints or at the least, to know that you’re not brain-dead.
- If you get stuck, simplify, try an example, or break things down further with questions. If you don’t know something but you’ve heard about it, tell them you’ve heard about it.
- Do the easiest version of the solution first so that you get something down; worry about optimization later, if they even want you to.
- Work in a language you’re familiar with.
It was a little bit brutal and a little bit amazing, the way they taught us these things. They called up three students one by one to the white board and straight up posed some common interview questions. We got to watch our fellow students apply the above ideas and do their best to go with the flow, sometimes stunning us with their aptitude and other times making us realize where we could get stuck.
The three interview questions, in case anyone’s curious to try their hand (no googling, trust me, you’ll want to just think it out if at all), were: 1. Write a function that finds the Fibonacci number corresponding to an index (eg if given n=5, it would find the sixth number in the sequence, base-0 of course). 2. Write a function that would test whether a linked list contains a cycle. 3. Write a function that determines whether two rectangles intersect on a plane.
Yesterday we talked about facebook integration in a mobile app. Basically all you have to do to get started is install their SDK, either via CocoaPods or from their website, and then you start writing some OpenGraph methods; Open Graph is their API that you make calls to, using ‘graph paths’ that get you access to different resources. The login process uses OAuth behind the scenes, so your app never gets the user’s password, making it fairly secure.
Now we’ve got two days left in class, today and tomorrow, and that’s it! Most of the day in class is pretty quiet now, as we each code away at our final projects, deciding what’s important enough to polish up by Friday. So in two days, at 9AM, what’s supposed to happen? Well, we’ve put together short bios and links to our projects, which presumably, Kush has sent off to any prospective employers who have already signed up to meet us.
So in the morning (early as it is), we’ll all be there bright-eyed and bushy-tailed ready to show off our work. We’ll have five-minute or so interviews with each of the prospectors who show up, and in that short amount of time do our best to demonstrate our capabilities, while sizing them up as people we may or may not want to work with. This goes on for up to three hours after which time, the sixteen of us and our mentors will stand around going, “well.” “yep.” and then sigh a huge sigh of I-don’t-know-what-yet. That doesn’t sound so scary. Bring it on.
Four! User-X and GooglePlex
We went in yesterday, on a Sunday, to work on our projects and learn a little bit more as the ninth and final week of App Academy begins. I finally have most features of my app working almost all the way, so it was a good experience to hand it off to people to play with and get back some honest criticisms.
There are always a lot of little things to think about with User Experience, but with iOS in particular where convention is so enforced, largely by Apple, you might be surprised how many details are expected to be just a certain way in order to make the interaction feel “natural” to the user. A button being in the wrong place, a weird transition, a keyboard not hiding on enter, these are all going to be noticed by the user. So even once I do have the functionality down, I see that I’m also going to have to make a lot of detail checks to polish it up, which is exciting, but also daunting as we only have four days left before presenting our projects.
Toward the end of the day, Ned started talking to us about Hadoop and Map Reduce, which are methods for processing huge amount of data by means of parallel computing; it involves splitting up the workload amongst many computers and then aggregating all the work back into a final analysed result afterward. There are three phases to the Map Reduce process: first, each of the computers gets part of the work and does it, this is the map phase. Then, the ‘shuffle’: each key (in a hash which is key=> value), is assigned to a computer, and all of the other computers send any work related to that key to that computer until all computers have a distinct set of keys. Lastly, the ‘reduce’ phase, where all of the work for all of the keys is put together into one giant hash.
Ned, having worked at Google where Map Reduce is implemented, gave us a little insight into how things went there; apparently it takes a lot of computers, and during the crunch phase, sometimes computers would literally burst into flames from overwork! More incentive not to burn out though, eh? We’ve got to keep a steady pace.
It’s Sunday, and we’re in class. Our new challenges are: make our apps presentable, and figure out how to present ourselves. With interview day just five days away, how should we balance the two concerns? We need to have something concrete to show for our abilities, but we also need to be mentally prepared to answer questions about things we may not have been concentrating on to build our projects.
We had to write bios on ourselves and come up with links for Kush to put together some little information packets on each of us, and we’re now torn between finishing the projects, practicing for interviews, and writing/getting together assets to show for all the work we’ve done, before and during class. Well things are about to go into overdrive for a few days here, and hopefully with great results.
SIX! How CoreData Works with RestKit
Yesterday, we worked all day as usual on our personal projects, and during the last hour, we all demo’d our apps to one another to get a glimpse at what the rest of the class was working on and to give us the experience of having to answer questions. Everyone seemed to have a really cool and interesting project going on, which was wonderfully exciting but also somewhat worrying - I didn’t feel like my project was really up to snuff during the presentations, largely because instead of implementing sparkly features, I spent long hours over the past two days struggling (successfully) to get a better understanding of some tricky concepts, namely authentication and data stores. I’ll share my painstakingly newfound knowledge here in its simplest form.
There is no concept of a session in iOS, but there is authentication. With RestKit, you will basically send your credentials to the server every single time you make a request, and the server will validate you for the request. If the backend uses AuthLogic, as mine did, it by default finds the current_user (which it uses to validate) through the user_session, which doesn’t get created by the iOS app, so after hours of trying various things, it became clear that this was where a change had to be made, and I had to redefine “current_user.”
I also spent a very long time switching my data pattern over form RestKit-based dataStores to internal CoreData files, so that the app will fetch all the current data from the web when it has internet connection, but it will also cache everything it brings down so that you can still see all the records when you are not connected. The reason that it took a long time and a lot of headaches for me was that I was unable to find the basic data-flow explained before I dove in, and a lack of the big picture when it comes to intricate processes like data flow can lead to a lot of inefficient design decisions and bugs. I drew the picture above in order to perhaps save someone else the heartache.
Well, six days left and then it’s all over for this batch of App Academyists. I’m so excited and scared that I won’t have anything to show! But I’m really happy for all of my classmates and the amazing things we have made as a group, so I can’t wait to see how the endgame plays out. All right, time to get back to work!
Eight. Don’t Say You Don’t Know
Last night, a few of us went to a drink-up at Parse, who is celebrating the release of their new ‘Cloud Code’ feature, and we were repping App Academy pretty hard. It’s becoming apparent to me how valuable networking is when you’re learning and/or looking for a job, but the more valuable lesson was a moment when I sort of put a couple of things together. A guy who works at CueUp.com asked me, “What is your specialty?” and my very first mental reaction was “What? I don’t know! I don’t have a specialty…” but I realized that this was not a satisfactory response. I wanted to have an asnwer, so I thought about what I am currently working on, and said “We’ve been really focused on iOS for a while, and the things I’m working on are quite focused on RestKit API interactions and custom views.” Voila, an answer 100x better than I don’t know.
I’ve been reading a little bit from this book that a few classmates recommended, Programming Interviews Exposed, and the chapter I just read talks about how important it is to demonstrate above all else that you have a logical thought process. The context was in regards to tough programming questions, and the gist of it was that when you get stuck, the worst thing you can do is to give up or say nothing, you have to at least show that you can try, even when you can’t succeed.
I’m thinking this idea applies to a lot of things and especially to a lot of things directly relevant to where we’re at right now, with eight days left of App Academy, hardly any time to finish up our projects and try our best to let them show what we can do. What are we going to present at demo day? What are we going to say we can do? During the process of building on our own this past week, I’ve tried to apply this to my everyday workflow and I’ve learned quite well how to not ever stop. If something gets tough, narrow it down to its most basic parts, and many times this allows you to solve it but when it doesn’t, it allows you at least to communicate it to a source that may help you solve it. Even then if that source is not available, isolate the problem and move onto a new one.
And when it comes to problem-solving, the first answer isn’t always the best answer, sometimes you’re going to have to completely scrap what you’ve done and do it differently. This is how I ended up getting unstuck from the problems I had with RestKit: First my JSON data was stored as an NSDictionary in Objective C, but this didn’t allow me to set properties on it, so I created an Class and a Store. Then RestKit wasn’t calling its delegate methods, so I switched to blocks, and everything worked. Then I ran into another problem when I got to the question of how to allow my app to post to the API, so I switched from blocks to Object-Mapping, a really cool feature of RestKit whereby you can translate a JSON object into an Objective C object by mapping values for keys to attributes. This may not have been the most efficient workflow in this case, but it led to an elegant solution and it taught me a lot. Now we’re moving on to bigger and better things, like remote user authentication and mapping to CoreData. Every second I just feel like I’ve really got my work cut out for me.
Eight days left where the only REST we get is our own APIs.
Nine. Flying Solo
Yesterday and today we didn’t have any lectures, and we didn’t have any pair programming, just ~9 hours of heads-down planning and coding on our own personal projects, and it’s presented quite a shift in the feeling of the class. We still have our amazing instructor and TA slowly making their ways around the room checking in to make sure we don’t need advice or to re-think design, logical and structural decisions we are making on our own. We still have plenty of questions for them all the time, but we’re getting on for the most part without getting totally stuck anymore, which is very encouraging.
I’ve got three apps underway and have been focusing on two of them this week so far; both involve using RestKit to make API calls and populate views with the parsed response. I’ve gotten a lot of mileage out of Grand Central Dispatch for multi-threading time-intensive processes (Ray Wenderlich has an awesome intro on that here). One thing I have found helpful to remember is that when you start a block, the program will go through it line by line, which means that if you start up another block inside of that block, such as when getting a different queue, you can be sure that the second, inner block won’t get called until the lines before it are completed, which makes GCD an ideal choice for when you need things to happen in a particular order. One note, though: setting the priority of the queue (Low to High) doesn’t necessarily guarantee the order in which things get done, so your structure has to take care of that.
Other than more adventures with blocks, my Evincel mobile project for instance has led me into a deeper understanding of how to use iOS to reflect the MVC perspective that was so important in rails. Building a mobile app that makes API calls to the rails app seemed simple enough, but as soon as your navigation flow gets a little more complex, it’s absolutely necessary to separate data logic from UI logic and to have associated models for specific items. I had initially taken the hacky route of making API calls with my viewController and having it save an array of objects to load from, but obviously this was not logical long-term, so I spent most of this afternoon refactoring and restructuring the flow of data until it became rather charming to me.
This whole thing is becoming markedly surreal now that we’re so close to the end. In a week and a half we’re done! We won’t be on our own completely, because we can still talk to each other, but the full-time, balls-to-the-wall, teacher-guided mad rush will be over and we’ll have to find other people and companies to grow our skills with. I feel like there is so much momentum that it’s gonna be hard to come down from, but there’s still quite a push to keep learning and to find valuable work that I don’t think is gonna stop at all. For the next ten days now I’m just going to give it my all and hope that something wonderful comes out of it. For the next ten days it’s almost nothing but programming and determination.
Hm, by the way, evincel.com is up and running, though there is still a lot of work to be done on it, so feel free to try it out and perhaps review a website or two to make sure it isn’t just awful.