Saturday, December 15, 2012

My Experiences Interviewing for a New Job

I recently interviewed for a new software engineering role.  It is a terrific time to be a software engineer in the Bay Area.  Lots of companies, big and tiny, are hiring.

Last time I searched for a job, I didn't really look around much.  This time, I went the other extreme and interviewed at 10 companies, mostly startups.  In retrospect, 10 was too many.  I should have spent more effort filtering out startups after the initial conversations with the founders/engineering leads, and should have avoided the first round of technical interviews if I wasn't entirely enthusiastic and convinced about the company or the role.  In multiple cases, I cancelled the second round of interviews after it became clear to me that a company would not be among my final top choices.  That way, I avoided further wasting everyone's time.

I applied to a couple of startups and big companies through friends who already worked there.  For most startups, I applied via a recruiter who contacted me over LinkedIn multiple times over the last one year.  He, and his colleagues at his firm, turned out to be excellent and presented many exciting startup opportunities to me, which I otherwise would not have known about.  I was initially concerned about recruiters being pushy, but these guys were super nice and professional.  I also participated in

Last time I applied for jobs, I used my pdf resume.  This time, all I needed was my LinkedIn profile.  Only one company even asked for my pdf resume.  I spent a good deal of time (grudgingly) searching for my resume's latex source files, which I finally found on an external backup drive.  Now, it is checked in at bitbucket; but hopefully, I will never need it again.  An up-to-date LinkedIn profile is all you need these days when applying for a job.

Since I applied to too many companies this time, I did a LOT of interviews.  Most of my interviews were the standard "write code for simple algorithmic problem on the whiteboard". I really don't enjoy writing code on the whiteboard - it is so unnatural - but I did it without complaining and was successful.  At a couple of startups, I was asked only about my current projects and some high-level design problems - didn't write a single line of  code.  The best interview process was at a mid-sized mobile payment startup - 4 pair-programming interviews where we produced real working code and unit tests, 2 design interviews and one interview just to talk about my work experience.

Successfully tackling algorithmic questions on the whiteboard requires practice, especially if you, like most software engineers, don't deal with linked lists, dynamic programming, graphs, etc on a daily basis.  The last time I dealt with such problems on a daily basis was during my undergrad Algorithms class.   To refresh my memory, I went back to my old favorite algorithms text book - Introduction to Algorithms by Cormen, Leiserson and Rivest.  It was a great $8 investment made 10 years ago (a lot of money for a textbook in India in those days).  Here is a photo of the first page that is marked with my initials (DAnJo) and roll number.    The website and associated book Cracking the Coding Interview: 150 Programming Questions and Solutions were also very useful in preparing for the interviews.

Interviewing took a lot of time.  However, it was a very enjoyable experience for me.  I was able to meet many amazing engineers across multiple super-cool companies (If you are looking for interesting startups, shoot me an email and I can send you some pointers).  I probably never exercised my brain so much in such a short span of time since undergrad exam crunch time.

Lastly, in case you are wondering, I am joining Facebook on Monday.

Saturday, October 06, 2012

My Talk on Spark at AMPCamp 2012

I recently gave a talk about how Conviva uses Spark at AMPCamp 2012.  Spark has helped Conviva speed up online video data analysis by 30x.  My talk video is embedded below.

Tuesday, October 02, 2012

Java Concurrency in Practice - Summary

I recently read Java Concurrency in Practice by Brian Goetz.  It is a fantastic book.  Every Java programmer must read it.  In order to firmly internalize the concepts described in the book, I read it a second time and took down notes summarizing each chapter.  My notes were very popular when I was in school and college.  Hopefully, these notes will be useful to others as well.  

NOTE: These summaries are NOT meant to replace the book.  I highly recommend buying your own copy of the book if you haven't already read it.

  1. Part 1 - Introduction, Thread Safety
  2. Part 2 - Sharing Objects
  3. Part 3 - Composing Objects, Building Blocks
  4. Part 4 - Task Execution
  5. Part 5 - Cancellation & Shutdown
  6. Part 6 - Applying Thread Pools
  7. Part 7 - GUI Applications, Avoiding Liveness Hazards
  8. Part 8 - Performance & Scalability, Testing Concurrent Programs
  9. Part 9 - Explicit Locks, Building Custom Synchronizers
  10. Part 10 - Atomic Variables & Non-blocking Synchronization,  Java Memory Model