Preparing talk can be really overwhelming. As a rule, I expect to spend an hour preparing for every minute I spend speaking. When a slot gets over 30 minutes… that starts to look like very nearly a full working week. This is an intimidating amount of time to find and clearly being organised and starting early is key.
Step 1: Topic
The beginning of any talk – what is something that I think I can prepare something about, that will be interesting, useful (and entertaining!) to the people watching it? This normally starts from conversations with friends or at work, usually things that I turn into blogposts to test whether people will be interested. Generally I start thinking about a topic the year before I expect to give it.
Step 2: Structure
This is always the hardest part for me, and until I have figured this bit out, I have no idea where to “begin”. How am I going to break the topic down? How will the pieces build upon and relate to each other? Like a UI, I build my talks on grids so this bit is really important.
Normally I figure this out on a long walk – or six. I spend weeks thinking out and angsting, carve out time to wander around (or swim!) and think about it. And eventually it becomes clear and I frantically drop it in a Simplenote document. Phew.
Because I have someone else make my slide decks, at this point I can get them involved in putting the deck together. My MVS (minimum viable slides) are one for each point in the structure, and a template for any other data or photos I want to show.
Step 3: The Pieces
Once things are broken down, I have less-intimidating pieces I can think about individually. For the talk I just prepared (YOLO Releases Considered Harmful) I wrote a blogpost about each section and published one a week in as I prepared. This meant I was carving 2-3 hours for each post, getting the ideas out and getting feedback. It meant even when everything was hectic and I felt like I didn’t have the time or headspace to think about The Looming Event, I could still feel like I was making progress on it.
Step 4: The Intro
This is where things start to feel overwhelming again. I try to step back from the pieces and remember why I wanted to give this talk in the first place. What does it have to offer this audience? How can I make it clear that I am a good person to give it, but subtly, because I will never get on stage and recite a list of accomplishments. How can I introduce the metaphor that ties the whole thing together?
This bit keeps me awake at night talking to myself (very healthy). It’s another time to take a long walk -or go swimming! Last time I felt like I broke through this bit on a day when I spent ~5 hours walking all over Milan.
Step 5: Putting it Together
Now I need a bit more headspace to put things together and think about it as one thing. I put all my pieces in a document, add my intro, and start going through it. At first I read it normally, but soon move to reading it aloud. Is this the way I would say it? Does it flow? I edit it to make it flow, to remove things that are unnecessary, and start putting it with my slides to see how they go together. I check my timing to make sure it’s looking reasonable, and figure out what extra slides I want.
Step 6: The Ending
Now that I’ve looked at it all together – how do I finish? The ending needs to tie it all together and connect to the intro. A good time for another long walk…
Step 7: Practise Practise Practise
The most important bit! I give my talk again and again until it seems natural.
I know a number of people who have been laid off recently – the market is on a downturn and this is more common than seems to be being talked about. I’ve spent time helping a few people try and find their next thing lately, and after some iterations I now have a process.
1. What are you going towards?
Whether someone is leaving their job voluntarily or not, there’s a good chance it hasn’t been great for a while. This makes it easy to focus on what you don’t want rather than what you’re going towards. But you make better decisions when you focus on what you want rather than what you’re trying to avoid.
Be brutally honest – what do you really want to be doing? What do you want your life to look like? How do you want your job to fit into you life?
Only once you’ve done this, consider what tradeoffs you are prepared to make.
For me: I loved managing a distributed team, and I wanted to keep doing that if possible. But I knew there weren’t many of those kind of jobs, so I was realistic that I might have to compromise. There were two dimensions of compromise: on-site management, or remote IC (individual contributor) work. On-site IC wasn’t something I was going to consider until those options were ruled out.
If you’re helping someone else: It’s easy to think you know what someone wants (if you think you know them well), but don’t assume. Ask questions, make observations about what they seemed to enjoy and what their strengths are, but let them figure out what they are going towards. It’s great if you are surprised! This sometimes takes people a while (and multiple conversations), but it’s really worth the time because it’s the foundation of everything else. Once they’ve figured it out, don’t help them be “realistic” even if you think that it’s going to be hard to find what they want. It’s unlikely to be helpful. Most people who you actually want to help have no trouble being realistic.
2. Resume.
Honestly, I hate resumes. Even as a hiring manager, I take very little interest in them (I think resumes are mainly a bias vector). I don’t have one, I got my last 4 job offers without one, and when I did have one it was one I paid someone else to create for me. If that’s an option for you, I really recommend it and I’m happy to connect you to the person who did mine (tweet me – @catehstn).
Once you’ve written up your experience, write your summary. The summary is two to three sentences that position you as a good person for the job you want, and should be backed up by the experience you have.
When you think you’re done, send it to three friends whose opinion on this is worth having. Ideally they review or at least see resumes for the kind of job you want. They might point out stuff you’ve missed. Try and find at least one native speaker of the language your resume is in.
If you’re helping someone else: This really depends on how much time you have. I don’t believe resume writing is a useful skill, so I’m happy to rewrite sections for someone. The process I followed was: I rewrite (or write) the section from their last job in discussion with them, they rewrite other jobs, and then I go through and edit those. Then, we write the summary together. If you’re just reviewing someone’s resume, focus on how they are coming across, or any information that appears to be missing, rather than how you personally would write a resume.
The purpose of these interviews is normally to get a sense of your experience, personality, and ways of working. When you wrote the summary for your resume, you made a conscious effort to think about how you want to present yourself. You want this to come out in your answers. This means not just answering the question, but deciding what you want the takeaway from your answer to be – something that supports your summary – and then telling a story that showcases that. This means that the same story can be an appropriate answer to multiple questions, depending on what you highlight.
The more open ended the question, the more scope you have for this. For example the question “tell me a bit about your background?” You can answer this question directly and chronologically (“I went to university at XXX and then I worked at YYY and did ZZZ and then…”) or you can frame the interview with your answer.
When I get asked this question, I say something like: “I’ve spent my whole career working on mobile, including writing a J2ME app a long time ago! At Google, I built most of the first generations presentations experience on iOS and ran a team building a location-based B2B app, and also worked on that app on Android. Most recently, I ran the mobile team at Ride.”
When answering these questions, one thing to keep in mind is that stories about dysfunctional environments are not helpful. For example a question like, “tell me about something you worked on that failed?” The answer that most springs to mind might be the one where the business didn’t know what they wanted, asked for unreasonable things, didn’t listen to engineering, and of course it didn’t ship or what eventually shipped was something that people didn’t want. If you don’t have a better lesson from this than “don’t work in that kind of environment” (a very fair lesson to learn from that experience), it’s not a good story to share. A less epic failure with more concrete takeaways is a better option.
If you’re helping someone else: Don’t just consider if the answer seems good, consider if it relates to their summary. If you’ve worked with them or know them well, point out other stories or achievements they might have missed – people are often a little blinded to their strengths, because they come more easily.
3b. Recommendation.
If I’m writing (or likely to write) someone a recommendation, I write it after we’ve done this together – it’s when their achievements are top of my mind, and I can write something that a) supports their summary and b) highlights some stories they might want to talk about in an interview.
If you’re asking for a recommendation: Make it easier on your recommender, and highlight some bigger achievements that you think they can speak to. These should relate to your summary. E.g. if your summary highlights your love of experimenting with new technology, include that experimental project you did that influenced something in a useful way.
When I give someone a mock technical interview, I give them my standard technical interview but I am less nice. Mainly, I do less time management for them – allowing them to spend too much time in places that aren’t helpful, if that’s their inclination.
I think Time Management is the easiest and most overlooked skill of technical interviewing. When people don’t know the answer they are very tempted to spend a bunch of time on peripheral things like validation, or writing a bunch of different function definitions, or setting up an elaborate test suite. Sometimes they start writing a brute-force solution with the goal of better understanding, but this takes up a more time than it provides utility. All of these might be good and useful things to spend time on in Real Life Programming, but can work against you when you are trying to show your capabilities in 45 minutes to an hour.
Other common mistakes:
Not taking the time to think of more than one option for solving the problem.
Not communicating clearly, meaning the interviewer has to guess what you are doing.
It’s easier to give someone feedback and guidance when you understand how they are thinking, what they are doing, and why.
5. Introductions.
Some people spread a broad net, my preference is to speak to a few places that I have strong introductions into. It’s more likely to be a good fit, and I’m more likely to be successful in the process. When I was looking for a job in August / September, I spoke to four places with strong connections and ended up with two offers that I felt great about. This is my preference with introductions – to introduce people to places where I think they have a good chance of success, and where I think they would be happy. I use a customised version of the recommendation I wrote to introduce people.
Time
I estimate that taking people through this process took ~8 hours per person (and these were people I knew well). As a result it’s not something that I would make time for other than for close friends or people I have a professional commitment to. They probably spent at least that, more, working on parts of it by themselves – technical interviews especially are a lot of work to prepare for.
TL;DR
Job hunting is a PITA and a ton of work. It helps to think about how to be effective at it.
I’ve written before about how I prepare mentally for a talk. Most recently, I’ve started to view it as a performance and be more and more (as the fall conference season is now underway) I’ve got more comfortable with the things I need to give a good performance. This change is mental, viewing it as a performance (rather than, commonly, a terrifying obligation past-me committed to), so differences are subtle, but important. I felt really good giving my last talk, which I think is a sign it’s time to prep a new one!
Because, it is a performance. I stand up in front of people, not my natural habitat, and try to be intensively witty and insightful.
I hope I’m usually witty and insightful, but in conversations, you take turns. On stage, it’s all on me.
One of my pet peeves as an audience member is when speakers are unprepared (even, maybe especially when they apologise for it!) Not preparing is disrespectful to the audience who have given up their time, and often significant amounts of money to be there.
If I’m speaking, then everything I do is around showing up prepared and in a good place mentally. This makes the conference experience very different. I feel OK about missing talks prior to mine. Although, pro-tip, for small conferences it’s worth letting them know you are hiding prior to your talk, and when to expect you as they may worry if they don’t see you!
Now, I always ask for travel costs (most conferences give speakers a free ticket) in part because it means I don’t feel any obligation to make the cost of attending worthwhile. Any value I got (which has typically been high) is gravy. Everything comes second to the performance.
Decompression time afterwards is also important. I usually use some of this time to make a storify of tweets during my talk.
Following day – a good night’s sleep and a good breakfast!
The other thing I’ve realised is that as a speaker, you can ask for things. Like water. Or to avoid specific slots. You can also ask for specific slots, but that is much harder for the organisers. It is incredibly hard organising a conference, so I try to go along with as much as possible and only ask for the things that will genuinely make an impact on my talk.
Prepare.
Hide (mental prep / power poses).
Setup equipment, test sound etc.
Perform.
Hide.
Socialise (this is when people say nice things! Don’t want to miss that!)
This is the easiest bit. I can spend as much time as I want here. The goal: a strong narrative that weaves together my key points (most of the work). Attractive, minimalist slides that illustrate them (much less work). Knowing what I’m going to say, and being able to speak fluently about the sections. I wrote more about this here.
Show Up
This is logistics, what to wear, how to get there, when to arrive. But also, everything I do to keep me from panicking and makes sure I show up mentally present.
Two day conference, and I’m speaking on the second day. On the first day, there are some great talks, which I alternate between appreciating, and panicking that they are signs that I shouldn’t be there, that I have nothing to offer, that this was all a mistake. I go for a walk. I miss two talks that I would like to see, but I am dramatically calmer as a result so have no regrets.
At another event, I miss my friend’s keynote so that I don’t have to deal with rush hour traffic.
I make time to swim the night before, and to wake up naturally. I eat breakfast. I hide away for at least 30 minutes, preferably an hour, before I speak.
Start Talking
In some ways, the easiest bit. At this point, I am committed – there is no way I’m going to be this guy.
This is the point where I have to be 100% committed to what I’m saying. I can fit in contextual remarks, allude to earlier talks, but the salient points were set long ago. They are happening.
Typically, I keep a script with me, and follow it closely, but hopefully people can’t tell. It’s helpful not just from a “this is what I’m saying” perspective, but also because it forces me to pause. Look down, check, look up, speak. It’s harder to do this when I’m super nervous – pauses are a sign of confidence. Being able to take a real breath, live with the seconds of silence that seem to last forever.
Hide
I’m an ambivert, which means a lot of people think I’m extraverted, but they don’t see me when I’m hiding. After a talk? I need to hide.
This is where I high tail it to a quiet place, as soon as possible. I smile politely, thank people for kind remarks. All recent talks, I was on a panel soon after, I made time for a brief moment of mental quiet. And then when I can get away, I do. Ideally to spend the evening at home alone – I find that immediately after a talk I’m really hungry (probably related to nerves killing my appetite before one), and then really exhausted. I go with that.
I eventually try and respond to all tweets, but not necessarily immediately, I also collect them in Storify [1, 2, 3], which is really helpful to show that a talk was well received and engaging. I might want to hear the talk following mine, but I’ll invariably miss it either physically or mentally – I’m just too overwhelmed afterwards, I can tell my heart is still racing, and I’m frantically checking twitter to see what people are saying (it’s nerve wracking to do this when I’m coming on stage again, I might get some much-needed confidence, or I might be crushed. So far this year, it’s been the good result).
Being alone afterwards for me is a key part of the process. It’s how I rebase, re-equilibriate. I plan it in, in the same way that I plan how to get there.
…
I used to worry that some of these actions would make me seem stand-offish. I’ve let that go. Everyone agrees that speaking is terrifying, and yes people might want you to go to the pub afterwards, or show up to their talk. But it’s better for everyone involved if I show up ready to give a good show. The four step plan? This is what best sets me up for that.
Ignite is an intimidating format. 5 minutes is not a bad length of time, but the auto-advance format is very unforgiving. I’d had that topic in mind as an Ignite talk for a while, but it took me a long time to have the courage to actually present it. And by have the courage to present it, I mean… be talked into it by Melle.
I should prefix this preparation list with the fact that I like to feel very prepared. I do some amount of public speaking, but I am still a software engineer so it is a long way from what I do all day! I’m not comfortable standing up in front of ~350 people and the only way for me to do it is to feel like I have done everything I can to not screw it up.
Picking a Topic
I think all good talks can be summarized by a sentence, and that sentence should contain the core message. 5 minutes or 45 minutes, that sentence is the string that holds it together coherently. This is particularly true of an Ignite talk. The format is unforgiving if you stumble or lose your place, but even more so if you don’t have a strong message. I’ve seen many Ignite talks that tried to pack in too much, but I don’t think ever one that put in too little.
I actually found my topic playing with a humorous intro for another talk I gave (Art, Life and Programming for Girl Geek Dinners Ottawa). I’ve cut the standard intro of “I’m Cate, I work on X, and I’m going to talk to you about Y” and instead try to weave that into the introduction (I’m pleased with how that worked out in Software Engineering for Superheros). And so I started my talk by telling the story of the guy who didn’t believe I was in CompSci, and used this to illustrate the point that programmers don’t just have an image problem – we have a communication problem. There was enough there, and people laughed enough, that I thought I could make it into an Ignite talk.
My topic in one sentence: Humans and engineers are different, and often the two groups fail to communicate.
Choosing a Title
I think there’s a lot of good advice on writing headlines, all of which applies here. I was terrified to go first, but I was also lucky to – because that is quite possibly the most engaged the audience will be. I’ve noticed at these events that I can’t process the amount of information, so diverse and so fast. At the last Ignite I was extremely jet-lagged and so don’t remember large chunks of it. Your title is the first opportunity you have to wake up the audience and remind them that this talk was one they wanted to listen to. It’s important to remember that the audience comes from every kind of background, and they don’t have the same frame of reference. So keep it accessible.
Deciding What to Say
You can opt to time your talk to your deck, like, the slide with the X means start talking about Y. This might be easier to remember, but is much tighter because you’re working within 15 second exact chunks, rather than the larger 5 minutes. Or, you can have your content and have the slides follow, illustrating your points rather than giving you points to talk to. This is more forgiving, and I think flows better. I’ve noticed that the other way often has an effect of making the timings seem contrived.
So, I opted for the second way. I wrote out what I thought would be in my talk, and then read it aloud. It came to about 3 minutes 30 seconds. I was reading aloud to my boyfriend, so he commented where he thought I should be adding stuff, so I followed his suggestions, read out loud again, and came in at 4 minutes 50-ish.
I think it’s important to have less and add rather than have too much and cut. Two reasons for this – not every topic is right for an Ignite talk. Having too much may be a sign that the topic is too broad. Second, I think you will get better flow by taking your core point and then adding in things that work than by having lots of important points and culling.
I read it aloud again to see that my time was consistent, and then again two more times. My (long suffering boyfriend, who heard this talk more than any person should) put in *’s every 15 seconds (you can see this in the slides and commentary). We went through again to check that that was consistent too.
Preparing the Deck
Then I added images that worked with where I was at each *. I tried to keep them general, and beautiful to look at. When I couldn’t think of what would work, I went looking for pictures of penguins. Someone said afterwards that she thought the penguins represented conformity. Unfortunately, I’m not that deep. I just like penguins! There is an Alec Baldwin meme at Ignite Waterloo, which I have never really got – probably because I missed the first Ignite and don’t really know who he is. It makes everyone laugh, but I wasn’t going to introduce anything into my deck that didn’t fit or make sense. So, I tried to make penguins the new Baldwin.
For one slide (the xkcd tech support one), I put it twice on consecutive slides, because I thought it might take longer than 15 seconds for people to process it, and it fitted what I was talking about for that 30 second bit well.
Then I set the slides up to auto-advance on the computer connected to the TV whilst I read from the text on my laptop. We were checking timings and that the content flowed with the slides. I had to adjust my timing a bit, but once we were happy I sent off my deck.
That was probably when I accepted it was really happening. Eep!
Practise, Practise, Practise
My practise set-up was as follows: slides auto-advancing on the TV, and text in Google Docs on my iPad. I was standing up (something they encouraged us to do in Extreme Blue). I just kept going through it over and over again (with my poor boyfriend watching and looking at the flow). I tried to use my iPad less and less, as a safety net, and eventually put it down and went through without.
I focused on timing, and remembering what I was saying. Normally I don’t memorize talks, I have talking points that I’m passionate about. But I think for short talks you have to memorize (this was a key thing we learned about presenting in Extreme Blue).
The content changed because I wanted it to sound natural, you don’t talk like you write. I had the word “ascertain” in my text, which I never say in conversation. So that sentence changed to use “ask” instead.
Having learned the timing, I was able to adjust my pace, adding pauses or an extra couple of words depending on whether I was on, or under time. I talk quite fast in general, and the pauses wouldn’t coincide with a slide change, so I hoped this would seem natural.
The day off, I was doing a last run through and my boyfriend noticed that I’d cut a sentence. Probably it had happened a while before, but neither of us had noticed until then. I left it out, figuring that often if you don’t remember it, it’s probably because it doesn’t flow.
On the Day
I did a couple of last run-throughs before leaving, and made sure I was happy with my outfit. I picked flat shoes – it’s important to be comfortable on stage and I didn’t want to be fidgeting.
We did not leave early enough! Did not realize how far away the venue was, and ran into roadworks and the car started acting up a bit. I was freaking out! But luckily they started a couple of minutes late and I was just in time, with not too much time to get nervous. I was perched on the edge of a chair, shaking, when my friend comes up behind me and touched me on the back saying, “nervous?”. I jumped and yelped.
I also had not realized that there would be a physical microphone. Thankfully we’d used them last summer and so I remembered. It was weird trying to get it the right distance from my mouth as I started off, but once I had that figured out it was OK, I hope. They called me up, and I hit spacebar and went for it.
After
Physically shaking, I went straight to the bar and said “I need liquor”. They said “what kind” and I said, “liquor!”. Eventually I walked away with a vodka and orange which reduced the physical shaking a little. I am ashamed to admit that I do not remember much of the people who followed me as I was still so strung out.
Then I checked the twitter feed and saw that people were saying nice things about and to me. I tried to reply to everyone who has used my handle thanking them for their nice comments. And I enjoyed the second half, at least! People were really, really kind. The audience is so supportive and they want you to rock it, which really helps.
There wasn’t much food there (food has to be done by the venue for bigger venues, which is annoying) and so we stopped off on the way home and I had some milkshake. Milkshake is pretty much my crisis strategy.
What I didn’t expect: I slept for about 10 hours the night following. Probably the result of being so strung out. I was also very socially exhausted and ended up working from home in the afternoon because I was getting very stressed being around people. I’m not particularly extroverted, so allowing for some anti-social space afterwards was very necessary!
Overall
I spent a lot of time preparing. Most of a Sunday on the slide deck and content, and then probably 6 hours of practise. The format is just as tough as I thought, but following the strategy outlined above made it manageable.
But, three people tweeted they were going to encourage their daughters to be software engineers. Which makes it all worthwhile!
Challenging, but a good challenge. I’m glad I did it.
If you follow my Twitter, I may have already given away the ending to this! But as a continuation from my first round, here is my experience for my second (final) on-site with Google two weeks ago.
What Did I Do To Prep?
Things were a little hectic with the end of Extreme Blue and our trip to New York, and my plan to read The Algorithm Design Manual (Amazon) on the bus fell apart somewhat after the bus broke down, I went 5 hours without water in the heat and had a small breakdown. There was (apparently) a hilarious ending that I don’t remember in it’s entirety, which I won’t be sharing on the internet…
That said, I did make it through section 1 which was really helpful and the book actually contains suggested interview questions – great for preparation. I also read more of Java(TM) Puzzlers (Amazon) and started Making it Big in Software (Amazon – good read, mostly for once you’ve made it through the interview though I think).
How Was It?
It was fun. I got to hang out with smart people and code for four hours! My first interviewer was a woman, who was super nice and that really helped. My lunch-buddy was a woman too, so even though diversity at Waterloo is not great it didn’t seem that bad at the time! I don’t know if they do that deliberately or not. I didn’t find the questions too tricky and could answer them all, probably because I’d done enough preparation that I’d got into that way of thinking. I had 3 technical interviews, and one architectural one (designing an API).
Takeaways
Much the same as last time. Knowledge of APIs, particuarly String, Collections and arrays, but additionally:
If coding in Java, know 1.5 features. One of my interviewers was more C++ and hadn’t coded in Java 1.5, and so when I used a for-each they asked the question, and I could answer – for-each loop added as of 1.5. Generics, too. I coded one question using Generics. Some people can find the syntax tricky, so if you’re going to use it (and IMO you should for good design) – know it.
Immutability! In the API-design question immutability made the second part of the question (how would you change it so you can do X) immeasurably easier. Know when you want to have immutable classes, and use get/set and visibility accordingly.
Trade-off’s between space and time. For another question, before I started coding I could say, I can do it in this complexity with this space overhead, or this (higher) complexity with no space overhead. In the end, we coded both. But I started with the easier one!
Overall
Unusually for me, I was happy with how I did! Despite having less time to prepare for this round, I’d remembered the stuff I’d gone over for the last interview and left feeling that I’d done the best I could.
Incredibly, I heard the following day (!) that I’d made it through regional review, my references were collected the day after and I received an offer a week after that. The HR guy in Waterloo was amazing in terms of keeping me in the loop and I got emails from two of my interviewers (one from each round) congratulating me. I’ve read (and heard) about people having a miserable experience interviewing at Google, but that was not at all my experience. The process took a couple of months, but that was because of my schedule and not them. I really liked everyone I interviewed with and everyone I encountered was super nice. I’m really excited about going to work there – and frankly still in shock that I made it!
I start in January. I guess I’m leaving Ottawa and moving to Kitchener/Waterloo. Bring on the next adventure!
For those of you who didn’t know (or work it out), this is where I interviewed last week. It went well, I think – at least I feel like I did the best I could and whatever happens that will be helpful.
I agreed to an NDA, so I can’t write about the questions that they asked me. However, I can write about how I found it and what I did to prepare.
First, it’s Google – so I would never have applied had my friend who works there not talked me into it and referred me. I didn’t have a phone interview, since I was “local” I was invited on-site directly. I don’t really think Ottawa is local for Waterloo (maybe because I don’t have the Canadian perception of distance!), but definitely in-person interviews are better than phone interviews and I lucked out because it was Ignite Waterloo that night, which was awesome.
First, I had a brief chat with a recruiter, who explained that I would be using a whiteboard and the process, and then two 45 minute interviews with two software engineers, one on one. I was amazed that I found the interviews fun! Normally I find interviewing really stressful, but what’s great is that it’s not so much like interviewing as jamming with another softie. That’s pretty cool! The questions in the first interview was fairly easy, the second one was a little harder but not too bad. The hardest thing was probably coding on the whiteboard (rather than a computer!) – hard to do TDD on a whiteboard! They tell you not to get dressed up, and definitely best not to – I spent a good portion of the time sat on the floor writing on the whiteboard and covered my hands in marker. Imagine doing that in a skirt!
Helpfully, they sent me a list of things to prepare for the interview. I have a solid undergrad so I’d covered all of it at some point, but it was good to know what things to focus on revising. Note that this is in addition to what I do in general – remain current with industry news, use Google products extensively, blog, and think a lot about how technology is changing our lives (yes, these last two things helped). I also already have a good grasp and use the Java 5 additions like Generics, Enums, for-each etc.
Here’s what I prepped (all book links are Amazon links):
Read Effective Java (2nd Edition) – I credit this book with any pretense I have of being a competent Java programmer.
Read Programming Interviews Exposed and worked through all the exercises – really helpful overview and refreshers on basic data structures like lists and trees. The recursion section was not as strong as I’d have liked (given my functional background) and advocated writing iterative methods instead, but other than that, it was a really good and helpful book.
Read Coders at Work – there are an astonishing number of Googlers in this book, which gives an idea of the culture. But there’s also a ton of interesting programming history that I definitely had not been aware of, insight into how these people solve problems, and discussion of APIs, scalability etc.
Reviewed Knapsack and Traveling salesman and NP-completeness in Combinatorial Algorithms: Generation, Enumeration, and Search (I also read almost the entire book and took a course on Combinatorial Algorithms in the fall semester) – honestly, I’m not a big fan of this book. I think it’s written in a fairly math-sy way. If you’re a programmer rather than a mathematician, solving these kind of problems using actual code is probably more helpful, and Wikipedia is almost certainly more readable.
Worked through some of Java Puzzlers – helpful for getting you in the mentality of looking at bits of code and picking out issues in it. I wasn’t asked that kind of question, but I did need to look at my own code critically. IBM gave me a question like that in my phone screen for EB, and I understand that Google do use that kind of question too.
Reviewed concurrency issues – deadlock, livelock, mutexes, locks, semaphores etc. When would you use the synchronized keyword in Java? How do you avoid deadlock? How do you avoid livelock?
Coded 6 sorting algorithms – including the key O(n log n) ones – TDD-style (Test Driven Development – see this post for my test cases).
Coded a hash table, using only arrays. Included: generics, dynamic arrays, lazy initialization. Again, test-first.
Worked through all the practice questions that I could get my hands on – search for “Google interview questions” but don’t bother with the estimates or manhole covers, look for ones like these. Sometimes I coded in Eclipse, but sometimes in Google docs. I’d work with a friend who would review my code and ask questions.
Talked to my friend who worked there a lot. Asked a lot of questions. He was absolutely amazing, and really helped me a lot with my prep. Even more than that, understanding why he thinks I would be a good fit and why he believes I can do it was really helpful in understanding why I would want to work there (yes it’s a cliche, and yes it’s Google but as one of my mentors pointed out, it is about whether you want to work for them nearly as much as whether they want you).
My Googler friend says I was “insanely well prepared”, and even I would say I was adequately prepared – but having gone through it, what would I do in addition to this stuff?
More run-time analysis – do as much of it as can find code to analyze.
Calculating sums. E.g. how can you sum the numbers 1-n? Work through the proof. Playing back the runtime analysis from my second interview, I have something that looks like: (n-1)(n-2) + (n-2)(n-3) + … + (3)(2) + (2)(1). Of course, I didn’t create it at the time so it became an upper bound of O(n³).
Review Java library data-structures. At one point, I was literally said, “I know there’s a data structure that doesn’t take duplicates, I just can’t remember the name of it right now”. Of course it’s anything implementing Set. And of course I remembered later than afternoon.
Review library methods for some key things – Arrays and Strings would have been helpful.
Practice coding on a whiteboard or just on paper. You take for granted being able to insert a line here or refactor and it’s much harder to do that on a whiteboard. Also, it’s easy to forget the return statement – Eclipse never lets me so I tend to write declarations and return statement first and put my code in the middle – can’t do that on a whiteboard!
What next?
Waiting.
Waiting.
Waiting!
Whatever happens, hopefully I will be able to get some feedback.
Code the interview questions (with test cases!)
Finish Java Puzzlers.
Reclaim my life – you might have gathered, I’ve spent quite a lot of time preparing.
Investigate opportunities with other companies. In particular – meet with IBMers and see if I can find something that’s a great fit for me there.
Debrief with mentors.
Cookie Consent
We use cookies to improve your experience on our site. By using our site, you consent to cookies.
