New Hire Program Services: Fill & Download for Free

"Sink or swim." They weren't the most encouraging words that Sean, Ooyala's CTO and ex-Google co-founder, could have said to me as I was ramping up, but they did set the tone for my onboarding experience at the company and for my first foray into the startup world. No life preserver was coming -- the expectation was that I would be struggling and had better figure out how to survive, fast.From my first day at the 30-something person startup called Ooyala [1], I found myself wading through a codebase laced with technical debt and augmented with little documentation and no unit tests, written in a Java-like language called ActionScript that I wasn't familiar with. I had two weeks to build and launch a feature already promised to video publishers, a feature that would allow them to schedule when their online videos would go on the air. [2] To hit my deadline, I needed to learn ActionScript, get comfortable with Ruby on Rails, and familiarize myself with Flash video and graphics libraries, all while tracing through code littered with obscure variable names like "qqq" and questionable function names like "load2" and "load3."I ended up pulling two nerve-wracking, 70-80 hour weeks to ship my first feature on schedule. The "sink-or-swim" onboarding experience remains to this day one of my most stressful and intimidating work experiences. In my early days there, I constantly wondered whether leaving the comforts of Google and joining the startup world had been the right choice for me. I eventually acclimated to the new environment and, with the help of the rest of team, the early untested and cryptic code has long since been supplanted with strong engineering practices. I learned a lot from the great team there during my two years at the company, but there's no doubt that onboarding could have been a smoother and more positive experience.When I later joined the 12-person team at Quora in August 2010, the onboarding process wasn't that much farther along. Charlie Cheever gave me a few starter bugs to work on, but since there weren't any paying customers, there was no time pressure other than whatever was self-imposed. Onboarding consisted mainly of me walking up to different people on the team asking them to explain things to me and maybe one or two ad-hoc whiteboard talks. My onboarding experience at Ooyala and two intense years in the startup world had made me battle-ready for anything though, so ramping up at Quora felt fairly mellow in comparison.My onboarding experiences would later motivate and shape my later work in building Quora's onboarding program, something that I've written about in detail back in November 2012 (What is the on-boarding process for new engineers at Quora? Is there any such process at all? Does Quora train their employees in a fashion similar to Facebook, or are they asked to start writing code straight away?).Is it actually worth the time to invest in onboarding?Startups have lots to get done, and many are racing against time to build a product and to acquire users and customers before funding runs out. So the first question is whether, and when, it actually makes sense to divert away resources to invest into onboarding. Many startups either don't make or defer making the investment, and instead just rely on newcomers to ask questions and figure out things on their own.While that might work, some risks of an ad-hoc, absent, or ill-defined onboarding process include:Weeding out good people who might have been productive had they been given a little more guidance, which would be a shame given how much effort is typically spent on recruiting someone to a company.Not identifying low performers or bad hires soon enough because there aren't enough opportunities to evaluate their work or because you're wondering that maybe you just need to give them a chance to ramp up before they become more productive.Losing productive output from the new hire because ramping up takes longer than it should have.Increased stress or reduced happiness of new hires, particularly those who might not have worked in startup-like environments before.These risks increase as more people get hired, especially if your recruiting pipeline biases toward more inexperienced hires, like college grads in their first full-time job.As a team grows, informal onboarding experiences cease to scale. Different employees explain concepts to new hires at different times, and without a standardized onboarding process, it's easy for those scattered explanations to omit coverage of useful information. An engineer might not learn a key abstraction that would've been helpful because his initial projects were on peripheral features, and he never took the time to walk through parts of the core code. Or, if expectations aren't communicated clearly, a new employee might spend too much time learning new things and not actually be productive until a month in. When a startup is small, there aren't as many places to look and people to ask to identify what's most important. As a company, a product, and a codebase get larger, the surface area of things to explore increases, and it becomes harder and harder for a new person, without any guidance, to figure out on his own what to learn first.The onboarding process is an opportunity to direct the learning and the activity of a new hire toward what the team believes matters most. Designing a good onboarding process can increase the effectiveness of the rest of the new hire's time. Moreover, the initial time investment to build a good onboarding program continues to pay off dividends with each additional hire.Designing an onboarding processDuring my time at Quora, I led the development of the onboarding program for new engineers and was directly responsible for areas like defining the role of engineering mentorship, organizing and scheduling onboarding talks, coordinating the creation of training materials, and holding mentor training workshops. I started working on Quora's onboarding program in December 2011, when Charlie and I realized that we would have more than 10 new engineering full-time hires and interns joining that coming summer. Our team was under 30 at the time, with only 14 engineers, so we knew that without a good onboarding process, things could easily get too chaotic.When first creating Quora's onboarding program, I knew that it needed to be much smoother and less stressful than my own experiences. I started by defining a set of goals for a good onboarding process before figuring out the materials, talks, mentoring, etc. that we needed to set up to achieve those goals. People on the team shared what they liked and didn't like about their previous onboarding experiences. I also reached out to engineers at other companies (including my friends at Ooyala who had started building an onboarding program there) to get a sense of how they did onboarding and of what worked well.The goals of onboarding may vary from startup to startup. I'll walk through some goals that I think a good onboarding process for a new employee at a startup should achieve and describe some examples of what we did on engineering at Quora for each goal.1. Ramp up a new employee as quickly as possible.A startup tends to be starved on personnel resources, and taking time to ramp up a new employee does mean a short-term hit on productivity for those involved in the onboarding process. The sooner a new employee gets ramped up, however, the sooner she'll be productive and contribute meaningful output for the startup. That's better in the long run both for the startup, since more will get done overall, and also for the new employee, who wants to prove that she can be a productive member of the team.One way that we emphasized the importance of rampup time at Quora was to assign each new engineer a mentor who's responsible for the person's success. We then built a shared understanding where it's acceptable and, in fact, strongly encouraged for mentors and other teammates to spend time away from their regular work to train new employees. It would be expected that a mentor might lose 25% or more of her productivity training the mentee during the first few weeks. Mentors did things ranging from doing a mentee's initial code reviews, picking out projects of increasing breadth and difficulty, outlining skills that the mentee should pick up to get more efficient, pair programming to teach tips and tricks, teaching strategies in prioritization, or helping to figure out the best way to work with different team members.I mentored a number of people while I was at Quora, and I would explicitly tell my mentees on their first day that it was a higher priority for me to get them ramped up than to get my other work done. This helped establish the shared goal of ramping them up as quickly as possible and to set the expectation that they shouldn't hesitate to ask any questions.2. Impart the startup's culture and values.Every startup culture is different. While a new employee may have gotten glimpses of the culture through recruiting and marketing materials and through meeting team members during interviews, the onboarding process is a great opportunity to ensure that a new hire learns about the values that the team shares. Those values might center around getting things done, being data-driven, working well as a team, building high quality products and services, or something else. A prerequisite to doing this effectively during onboarding is, of course, actually having a shared understanding internally of what defines the startup's culture, mission, and values.At Quora, for example, the product lends itself quite naturally to a culture of learning. But there's actually a tendency to focus too much on learning when first joining a company, especially for those right out of college, and not enough on moving fast and getting things done. To ensure that new engineers learned the company's pace, we tried to have each new engineer push a commit to add herself to the team page on the first day and to deploy a bug fix, a small new feature, or a new experiment by the end of the first week.This meant simplifying the first day's activities enough so that a new hire would have enough time to set up her development environment, make a simple code change, run tests, and commit the change on the first day. It also meant that mentors needed to do some preparation to find bugs, features, or experiments that they thought new engineers could ship in the first week. Because there tends to be a lot of variance in our own project estimates [3] and in how long it takes new employees to ramp up, I generally advised mentors to pick starter projects that they thought they themselves would be able to finish in about a day, so that even if the project slipped, there would still be a high probability that it would ship in a week.3. Expose the new employee to the breadth of fundamentals needed to succeed.The complexity of the product, team, and codebase grows as the startup grows, which means there's more and more surface area for new employees to wade through to identify things that every new person should know. During my career, I've also noticed that those engineers who learned the fundamental tools and abstractions well -- whether it was because they did a better job identifying what to learn or had mentors or starter projects that encouraged them to learn the key concepts -- tended to be much more effective many months later because they knew what was available and when to use them. A key part of a good onboarding program is ensuring that everyone starts off on a consistent and solid foundation with respect to those fundamentals, so that there's less variance in terms of who learned what based on initial project or mentoring assignments.Two ways at Quora that we accomplished this on engineering were by:Setting up a series of ~10 onboarding talks in a new hire's first two or three weeks. These talks introduced the codebase, explained git's data model, walked through testing expectations, demoed debugging and profiling tools, and covered a variety of other topics that we thought were important for new hires to learn in their first two or three weeks. The most important ones (like an introduction to the codebase) I would schedule every time a new hire started, even if it was just for one new hire, while some others I would batch together until there were more people.Writing codelabs to explain abstractions and tools at the company. Codelabs were a concept that I borrowed from Google. A codelab is a document that explains why a core abstraction was designed, shows how it's used, walks through relevant parts of the codebase, and then provides a set of exercises to validate understanding. I spent about three days writing a good, first codelab that others could model off of, and then recruited others on the team to pitch in and write other codelabs on core abstractions and tools that every engineer ought to know.These investments primarily involved an upfront, one-time cost to create a reusable resource followed by a relatively small recurring cost to update outdated materials and to actually give the talks.4. Socially integrate the new employee onto the team.At a startup, you're likely to spend significantly more time with your teammates than at many other places. It helps to encourage more team bonding with new hires, especially the ones who might be more shy or quieter.Early on at Quora, we relied mainly on mentors to help introduce the new hires around. Later on, some members of the team started organizing small group lunches to help give more structured opportunities to meet other folks on the team. Batching new hires to start on the same day also helps to create more of a sense of camaraderie.These goals are just some examples of what you might want to think about in designing the onboarding process at your startup. As startups grow, onboarding goals may also change. For instance, based on some talks with engineers at Facebook (granted, not quite a startup now) who worked on the Bootcamp onboarding process [4], it was important to have new engineers decide which team they might want to join. During Bootcamp, the new engineers would try out small projects relevant to those teams. That wasn't an onboarding goal until the organization actually had well-defined engineering teams.It's important to realize that building an onboarding program can and should be an iterative process. Maybe you'll simply start with a document on how to set up a development environment with the goal of getting a new engineer ready to modify code after his first day. Perhaps you later realize that not all starter projects necessarily provide the same rampup benefit and decide to articulate a set of guiding principles on how to pick good starter projects. Maybe you notice that you're giving the same codebase or architecture walkthrough over and over again and realize that it would be much more effective and efficient if you just prepared a talk for the topic.Wherever you are in designing an onboarding process, think about your own onboarding experience and survey others on the team to get a sense of what worked well and what could use some improvement. Think about where new hires struggled and what things you might be able to do help them ramp up more quickly. Think about key concepts, tools, and values that you wish you had learned earlier during your time at the startup. Once you have some ideas, implement the most valuable ones, and then survey later new hires and team members who work with them to see if the changes helped. Rinse and repeat, and hopefully the onboarding for your new hires won't be stressful as my own experience at Ooyala.Looking for more tips on engineering and startups? Subscribe to my blog at The Effective Engineer.[1]: Ooyala focused on building an end-to-end platform to power online video for its customers, handling everything including transcoding, delivery, advertising, analytics, and other services.[2]: Schedule When Your Videos Go on the Air, June 2008.[3]: See my answers on What are some ways to improve your project estimation skills? and What is the best way to communicate to a software development team that they need to work more hours to meet a launch date? to understand why project estimation is hard.[4]: How does Facebook Engineering's "Bootcamp" program work?

I assume you are a new grad coming in through our new hire program.Let me suggest a few thoughts for you. One of the fun things about Cisco is that it is a big place, with a very broad range of products and technologies. An aspect of our college program people like is the ability to have more control over your initial placement and assignment. So a good starting point is to research the individual groups, and get data on the available roles. You should be able to make a thoughtful choice, based on who is interested in you, among different roles.As far as the different groups, depending on where in the technology stack you want to play, here are some ideas:- Application / mobile / cloud: Lots of interesting work going on in the Collaboration Group. Webex, Cisco Quad and especially Jabber and the new hosted and cloud solutions for collaboration.- Virtual Services / OpenStack / SDN: Major focus by the Data Center Group in this area. Open source projects, community work, data center virtualizatoin strategy, etc.- Internet of Things / BYOD / Network Protocols / SDN: Marquee projects in the Enterprise Networking Group (my team) across a very diverse set of technical problems.- Cloud Security / Next Gen Firewall: Security is hot right now, and lots of good projects in the Security Group.Finally, don't worry too much about where you start. It's a big place and you can move around once you establish yourself.

I went through this phase 3 years ago, when joining DirectI as a platform Engineer. And I have seen this happen to most new hires every year.Keep in mind that all of these lessons are mentioned in courses, but understood during software development.Below is a comprehensive list of things to do.——————————————Learn about Distributed SystemsDistributed code is very hard to understand compared to conventional “void main” code. The code might be called by an external party, so the flow does not start in a clearly defined function/class. You have to expose methods and objects that will be used by external services, which brings the concept of client packaging and export.Its best if you try to write an HTTP server for starters. It exposes us to APIs and how services interact. Once you are done with this, think about using multiple computers for handling requests. Take into consideration:a) What if one computer fails/shuts down?b) How do I load balance my requests?c) What happens to cached/in-memory data? How do I handle stale data in caches?Reading answers/books for the above stuff is good, but the learning will happen when you try to apply it. Most of the idealistic book knowledge goes down the drain then, and you are left with making practical solutions for real systems.Understand databasesDatabases are the most critical part of your work, sometimes so much that you won’t get direct access to it till you have some experience/requirement. Knowing how to read and persist data is not enough. Look into:a) What are indexes in a database?b) Keep application logic away from the database. This is this most common mistake of a beginner. You want to just pipe data in and out of the databases. Unless there is a specific case where a lot of bandwidth is being used while transferring data, do not write stored procedures or other logic inside the database. Because debugging and code flow is hell there.c) Never manipulate data. Stuff like delete and update should only be done after discussing with your manager. How do you delete a user? Set the status as deleted. How do you update something? Usually by doing another insert.Move from ‘Thrill Seeking’ to ‘Dependable’Your team doesn’t care when you used Persistent Segment Trees to find a bunch of prime numbers. They want a vacation in Goa or the Himalayas. Points to consider:a) Don’t write code which looks like shit. Look into refactoring.b) Don’t be smart around the database. One mistake and you are fired. (I have seen this happen)c) Log your code properly. Don’t abuse debugging statements. People breathing down your back is scary enough, without the additional craziness of not being able to load a huge log file.Expect a mix of workMost competitive programmers are disappointed with the lack of challenging algorithms and data structure problems after starting development. Here are some tips:a) Accept reality. Some tasks are bound to be mundane and you have to get on with it.b) Do not see ghosts of optimization everywhere. If you don’t understand a system entirely, first do that and then check for optimizations. Code breaking because of this is your responsibility, so you need to know how it works beforehand.c) If your colleagues know nothing about data structures, it doesn’t mean they are stupid. Most of them know which libraries to use for different scenarios. Be prepared to write little to no code and spend most time testing functionalities. It’s what brings the money in.Be a master in the language you useLEARN IT WELL. Some common questions in all languages will be:a) How do I make immutable objects in this?b) How do I make Async procedures?c) How do I make connections to external systems and databases?Once you can answer these questions for the language being used, you can read code and understand what’s happening. I made the mistake of not doing this, and took a few months to decipher my first codebase.MultithreadingThread pools, how processes run, and assigning workers are the most common things we do. Knowing how they work and where a bug might have surfaced often saves the day.Talk to your manager when fiddling with thread allocations. It would be nice for you to know how threads are spawned and killed in your language beforehand.Dependency Injection and DeploymentYou wrote the code. But it doesn’t compile because you need an external library. Package management is one of the forms of dependency management.These concepts are a little advanced. You can have a look at:a) Maven. The most common dependency injection tool.b) Guice/Dagger or some other code DI tool. Nearly all firms use these to keep object instantiation at startup level.c) Jenkins is a software to build and deploy code. I know you won’t read about it, because its dead boring. But when you suffer like we all did, at least I can quip: “I told you so :P”Deeply understand GitGit is the most essential tool in a software team. It helps manage code like merging the changes on the same file for two different developers. Get used to it’s commands and watch a video on it here.Git will be with you regardless of programming language or project type, so understand its features well before diving into development.—————————————-Here is a channel trying to explain the above to new hires. Lets see how many topics I can churn out in time :-)System DesignCheers!