| |||
Job hunting? How to spot the right (or wrong) cultural 'fit'
It's not always easy to get a clear picture of a company's culture in a job interview, but thoughtful preparation can help you ask the right questions.FORTUNE -- Dear Annie: I'm unhappy in my current position for a number of reasons, none of which seems likely to change anytime soon, so I've been looking around for a new job for the past couple of months. All the career advice I've heard (and read) mentions that a good "fit" is essential. But nobody ever tells you how to determine whether the "fit" is there or not. I've had a couple of interviews lately where it seemed to me that both the interviewer and I were putting our best feet forward and saying what the other side wanted to hear, which is natural enough, but I haven't felt I've gotten a clear idea of what it would really be like to work for these companies. They all say they value their people, reward individual initiative, offer opportunities for advancement, blah, blah, blah, but how can I tell if it's all just part of the script or if they really walk the talk? Any suggestions? — Seattle SkepticDear Skeptic: You're right, this is tricky. The culture of any organization -- that ineffable mix of traditions, habits, assumptions, and unwritten rules that add up to "how we do things around here" -- is so complex, and so subtle, that it's hard (if not impossible) to sum up in a few simple phrases. So, even with the best of intentions, many job interviewers tend to fall back on the cliches you've been hearing. At the same time, though, you owe it to both yourself and the company to peer past the happy talk. Especially since you're already working, "you don't want to end up in just any new job," says Jim Hinthorn. "You want one where you're going to thrive -- and that means finding the best 'fit' possible." MORE: America's workers: A year of ups and downs As a veteran human resources executive who is now a coach for the national career-counseling network Five O'Clock Club, Hinthorne has spent decades pondering the "fit" question from both sides of the interviewer's desk. In his view, getting it right requires you to do a fair amount of sleuthing to learn as much as you can about a prospective employer before you meet with anyone there. Beyond the standard homework every job seeker should be doing -- like studying the company's website and annual report, and reading up on it in the trade press -- take advantage of resources like Vault.com and Glassdoor.com. "You can get invaluable insights from the comments employees and ex-employees post on these sites," Hinthorn notes. "You might also seek out current employees on LinkedIn and ask them what it's like to work there." The more specific your questions, the more useful the answers are likely to be. "You're far more likely to find the right fit if you know exactly what you're looking for," Hinthorn says. So think hard about what you want in your next job, pinpointing what's really important to you, what's optional or negotiable, and what doesn't matter at all. The Five O'Clock Club has developed assessment tools to help with this, spelled out in a book called Targeting a Great Career by Kate Wendleton, the organization's founder and president. But with a little introspection, you can do the same thing on your own. "Some of the values people want in a job are, for instance, independence, creativity, power, money, adventure, working for a cause, or having time for a personal life," Hinthorn says. Once you've come up with a short list of what matters most to you, you can focus on those areas when you pose questions to people who are already there. "To some extent everyone adapts to the prevailing culture in a company -- casual versus more formal dress codes, for example -- but certain things are non-negotiable," Hinthorn points out. "And you are the only one who knows what those things are." MORE: Job-hunting law school grads will face a 'perfect storm' Let's say you decide that one of your non-negotiable items is time for a life outside of work. Before going to an interview, come up with questions that will give you a glimpse of whether that will jibe with the company's culture. "Ask, for instance, what the interviewer's typical day is like, especially if he or she is your prospective boss," Hinthorn suggests. As a candidate for a senior HR management job, he once asked that question and heard that the interviewer "put in half days on Saturdays and Sundays, on top of working 12-hour days during the week and attending client dinners several evenings a month," he recalls. "I didn't ask, 'Is work-life balance important to managers at this company?' But I sure found out." Hinthorn also recommends asking to speak with people who currently report to your prospective boss. "Ask them what he or she is like to work for, including questions like, 'If you could change one thing about this person, what would it be?'" he says. "People tell me, 'I couldn't ask that!' But in all the years I interviewed people, I never thought anyone asked too many questions. Most job hunters ask too few." Talkback: What questions have you asked in job interviews that helped you identify a good (or bad) cultural fit? Leave a comment below. Filed under: Ask AnnieSee more Ask Annie | |||
Showing posts with label culture. Show all posts
Showing posts with label culture. Show all posts
Friday, September 7, 2012
Job hunting? Spot the right (or wrong) cultural 'fit' [Ask Annie]
Friday, August 24, 2012
What makes a good engineering culture? - Quora
What makes a good engineering culture?
Software Engineering: What makes a good engineering culture? - Quora
'via Blog this'
22 Answers
One of my favorite interview questions for engineering candidates is to tell me about one thing they liked and one thing they disliked about the engineering culture at their previous company. Over the course of a few hundred interviews, this interview question has given me a sense of what good engineers look for and what they're trying to avoid. I also reflected back on my own experiences from the past six years working across Google, Ooyala, and Quora and distilled some things that a team can do to build a good engineering culture:
1. Optimize for iteration speed.
Quick iteration speed increases work motivation and excitement. Infrastructural and bureaucratic barriers to deploying code and launching features are some of the most common and frustrating reasons that engineers cite during interviews for why they're leaving their current companies.
Organizationally, quick iteration speed means giving engineers and designers flexibility and autonomy to make day-to-day decisions without asking for permission. While I was at Google, any user-visible change to search results, even for low-traffic experiments, required Marissa Mayer's approval at a weekly UI review. Needless to say, while this allowed Google to protect its search brand, it significantly hampered innovation. Optimizing for iteration speed also means that there are well-defined processes for launching products, so that cancellations don't happen unexpectedly after significant time investment.
Infrastructurally, optimizing for iteration speed means building out continuous deployment with a fast deployment process, high test coverage to reduce build and site breakages, fast unit tests so that people run them, and fast and incremental compiles and reloads to reduce development time. Continuous deployment, where commits go immediately to production, deserves a special mention. Prior to using it at Quora, it would've been hard for me to internalize that the benefits it provides toward iteration speed outweigh the risks of site breakages, at least for small engineering teams. People are more excited about features and incentivized to fix bugs because changes see live traffic quickly. It's also significantly easier to reason about and pinpoint the source of errors for a narrow window of committed code rather a week or more's worth of batched changes.
Team-wise, fast iteration speed means having a set of strong leaders to help coordinate and drive team efforts. Key stakeholders in a decision need to decide effectively and commit to their choices. To borrow a phrase from Bill Walsh, a leader who coached the 49ers to 3 Super Bowls, strong leaders need to "commit, explode, recover," which means committing to a plan of attack, executing it, and then reacting to the results. A team crippled with indecisiveness will just cause individual efforts to flounder. [1]
2. Push relentlessly toward automation.
In his tech talk "Scaling Instagram", Instagram co-founder Mike Krieger cited "optimize for minimal operational burden" as a key lesson his 13-person team learned in scaling the product to tens of millions of users. [2] As a product grows, so does the operational burden per engineer, as measured by the ratio of users to engineers or of features to engineers. Facebook, for example, is well-known for touting scaling metrics like supporting over 1 million users per engineer. [3]
Automating solutions and scripting repetitive tasks are important because they free up the engineering team to work on the actual product. Ensuring that services restart automatically if possible when they fail and that services are easily and quickly replicated at peak traffic is the only sane way to manage complexity at scale. In the short-term, there's always the tempting tradeoff of applying a quick band-aid manually rather than automating and testing a long-term fix.
Etsy's motto of "measure anything, measure everything" [4] and its support of open-source monitoring and charting tools like graphite [5] and statsd [6] highlight an important aspect of automation -- that automation must be driven by data and monitoring. Without monitoring and logs to know what, how, or why something is going wrong, automation is difficult. A good follow-up motto would be to "measure anything, measure everything, and automate as much as possible."
3. Build the right software abstractions.
MIT Professor Daniel Jackson captures the importance of software abstractions well [7]:
Part of what allowed thousands of engineers to build scalable systems at Google is that really smart engineers like Jeff Dean and Sanjay Ghemawat built simple but versatile abstractions like MapReduce [8], SSTable [9], protocol buffers [10], and the like. Part of what allowed Facebook engineering to scale up is the focus on similarly core abstractions like Thrift [11], Scribe [12], and Hive [13]. And part of what allows designers to build products effectively at Quora is that Webnode and Livenode [14] are fairly easy to understand and build on top of.
Keeping core abstractions simple and general reduces the need for custom solutions and increases the team's familiarity and expertise with the common abstractions. The growing popularity and reliability of systems like Memcached, Redis, MongoDB, etc. have reduced the need to build custom storage and caching systems. Funneling the team's focus onto a small number of core abstractions rather than fragmenting it over many ad-hoc solutions means that common libraries get more robust, monitoring gets more intelligent, performance characteristics get better understood, and tests get more comprehensive. All of this helps contribute to a simpler system with reduced operational burden.
4. Develop a focus on high code quality with code reviews.
Maintaining a high-quality code base increases the productivity of the entire engineering team. Cleaner code is easier to reason about, quicker to develop on, more amenable to changes, and less susceptible to bugs. A healthy code review process makes this possible.
Establishing a process for timely code reviews, whether pre-commit or post-commit, improves code quality in a few ways. First, the peer pressure of knowing that someone will be reviewing your code and that committing poorly written code will likely let down your teammates is a strong deterrent against hacky, unmaintainable, or untested code. Second, code reviews provide opportunities for the code reviewer and author to learn from each other to write better code.
If the code reviews are easily accessible to other members of the engineering team, then the reviews also bring along the benefits of a) increasing accountability for reviewing code in a timely manner, b) allowing team members -- particularly, newer ones -- to model off of others' good code reviews, and c) speeding up the dissemination of best coding practices.
Counter-arguments that nimble teams don't have time to spend on code reviews ignore the technical debt that can easily accumulate from poorly written code. Ooyala, in its very early startup days, used to optimize for cranking out as many features as possible, with an absence of code reviews; the result was that while the initial product may have gone to market more quickly, the resultant code became painful to modify, and we spent over a year just rewriting brittle code to eliminate technical debt.
Google, at its size, does pre-commit code reviews for all code, but smaller teams don't need to be as comprehensive or strict, and not all code needs to be reviewed with the same rigor. Ooyala later adopted post-commit reviews over email for core or risky changes while I was there. At Quora, we currently conduct all code reviews in Phabricator [15], mostly post-commit, and apply different standards for model or controller code and view code; for sensitive code or for code from newer engineers, we'll either do pre-commit reviews or try to review them within a few hours of the code being submitted.
5. Maintain a respectful work environment.
Respect among peers forms the foundation for any type of open communication. A place where people feel comfortable challenging each other's ideas is one where sound ideas get forged through debate. A place where people easily get offended is one where crucial feedback gets withheld.
In 1948, Alex Osborn outlined the familiar brainstorming approach that's been popular in work environments for the past few decades, where participants come together, set aside criticism and negative feedback, and collectively pool together creative ideas without fear of being judged. [16] Respectful deferment of judgment is key to this type of brainstorming session. Recent psychology research has started to overturn Osborn's approach, suggesting that encouraging debate in brainstorming sessions actually helps to avoid groupthink and generates more effective ideas. In light of this research, a respectful environment becomes even more critical so that attacks are directed toward ideas rather than being ad-hominem. [17]
Engineering often spans a wide range of areas (systems, machine learning, product, etc.) and not everyone has the same expertise in each area. A strong team in fact probably ought to have individuals who are uniquely strong in certain areas even if they end up being deficient in others. This sometimes makes it tricky for say, a systems engineer to evaluate the proficiency of a product engineer, but it's important in a healthy engineering culture to respect those differences and to not judge solely based on your own strengths.
6. Build shared ownership of code.
While it's natural for individuals to become proficient in various parts of the code base or infrastructure, no one person should feel that they own or are the sole maintainer of any one piece. While having individuals become experts that own certain areas for a year or more might increase effectiveness in the short run, this approach ends up hurting in the long run.
Organizationally, shared code ownership provides three benefits. First, keeping the bus factor [18] greater than one relieves stress from the maintainer and reduces risk for the team in case the maintainer leaves. It also makes it difficult for that one person to take worry-free time off. I sure don't miss the days when I was the sole maintainer of Ooyala's logs processor and got texted by pager alerts while hiking on volcanoes in Hawaii.
Second, shared ownership empowers engineers who aren't knee-deep in the particular area to contribute fresh insights. It frees engineers from the sense that they're stuck on certain projects and encourages them to work on a diversity of projects, which helps to keep work interesting and boosts employee learning and motivation. In the long run, it reduces organizational risk that some engineer feels stagnated and decides to leave. [19]
Third, shared ownership also sets the foundation for having multiple team members swarm (a technique from agile development) together on a high-priority problem when necessary to finish a strategic goal more quickly. With siloed ownership, the burden typically falls on one or two people.
One mistake that many engineering organizations make too early on is dividing the entire team into subteams with tech leads when the team's still small. Subteams build walls of ownership that reduce incentive to cross those walls, since individuals will likely be assessed by their subteam's objectives. Ooyala had subteams while I was there, and one thing I missed out on was the opportunity to work with some folks on other teams; they've since adopted an agile development process with a much larger focus on shared code ownership that I've heard has made large strides in work happiness and productivity. One aspect of Quora that I've loved is that we've emphasized projects over teams, and I've had an opportunity to work on projects ranging from user growth, machine learning, moderation tools, recommendations, analytics, site speed, and spam detection.
7. Invest in automated testing.
Unit test coverage and some degree of integration test coverage is the only scalable way of managing a large codebase with a large group of people without constantly breaking the build or the product. Automated testing provides confidence in and meaningful protection against large-scale refactorings that are required to improve code quality. In the absence of rigorous automated testing, the time required for manual testing either by the engineering team or by an outsourced testing team easily becomes prohibitive, and it's easy to fall into a culture of fear for improving a piece of code just because it might break.
In practice, automated testing is a requirement for making continuous deployment work as the team grows. Codebase size grows over time as the product grows, but average familiarity with the codebase by team members decreases as new people join. Testing and validation are most easily done by the original code authors when the code is fresh in their minds than by those who try to modify the code months or years later. Encouraging a strong unit testing culture shifts the validation responsibility toward the authors.
8. Allot 20% time.
Gmail found its roots in Paul Buchheit's 20% project, and he hacked together the first version in a single day. [20] Google News, Google Transit, and Google Suggest also started and launched as 20% projects. I used 20% time while at Google to write a python framework that made it significantly easier to build search page demos. While Google's 20% time may be less productive now than during the early days of the company [21], the notion of letting engineers spend 20% of their time working on something not on their product map remains a cradle of innovation for smaller engineering organizations.
Ooyala didn't officially have 20% time while I was there, but I took some anyway and wrote a command-line build tool for Flex and Actionscript that sped up the team's build times, just as Adobe's Flex Builder tool chain started to degrade, and the tool's still in use today even though the engineering team has nearly tripled in size. Atlassian adopted 20% time after experimenting it for year. [22] A variation of 20% time that Facebook's fond of and that Ooyala added later is periodic hackathons -- all-night events where the rule is that you can work on anything except your normal project. [23]
Top-down approaches to product planning, while necessary for focusing the overall direction of the company, can't account to for the multitude of ideas that might arise from engineers closer to the ground. As long as engineers are accountable for their 20% time and focus on what can be high-impact changes, these projects can lead to large steps forward in progress. Without official 20% time, it's still possible but much more difficult for engineers and designers to try out crazy ideas -- the dedicated ones basically have to find weekends or vacation days to do it.
9. Build a culture of learning and continuous improvement.
Learning and being sufficiently challenged are requirements for what psychology professor Mihaly Csikszentmihalyi calls a state of "flow", where someone is so completely focused and motivated by what they're doing that they even lose track of time. [24] The direct and immediate feedback loop provided by faster iteration cycles is another requirement.
Weekly tech talks provide forums for engineers to share their designs or what they've built, creating an opportunity for engineers to take pride in their work and for the the team to learn more outside their immediate scope of work. Documenting processes internally like how a email service works or how to make ranking changes to a search service also empowers engineers to learn and explore new things on their own, nicely complementing 20% time. At Quora, we do this by running an internal instance of Quora where we ask product- and development-related questions.
A corollary of building a culture of learning is focusing on mentoring and training to make sure that everyone has the basic algorithms, systems, and product skills necessary for success. The more an engineering organization grows and the more effort gets spent on recruiting (particularly college recruiting), the more effort needs to be invested into mentoring and training. It might seem burdensome for a single mentor to spend an hour per day for a new hire's first 4 weeks on the job, but that investment represents less than 1% of the total time that hire will spend in a year and has significantly high leverage in determining whether the person is set up for success.
10. Hire the best.
Hiring the best is the foundation for many of the other philosophies listed. It's hard to respect someone if you think they're a B-level engineer. It's hard to give someone autonomy in product development if you don't trust their product instincts. It's hard to recognize the right abstraction to build without enough engineering experience. It's easy to fall into a trap of building something complex without other smart people to challenge your ideas and drive you toward simplicity.
There's a saying around Silicon Valley, coined by Steve Jobs, that "A players hire A players. B players hire C players." [25,26] Focusing on recruiting and hiring the right people is hard but critical to effectively growing an engineering organization. Yishan Wong, who previously was an engineering manager and director at Facebook, argued that hiring has to be the number one priority for everyone in the engineering organization, not just for managers, but for engineers as well. [27] He also quite rightly points out the difference between "hiring the best" and "hiring the best candidate that you've interviewed."
In the early days of Ooyala, we were so overwhelmed with the queue of inbound customer work that we nearly caved in to lowering our hiring bar so that we could hire enough people to get all our work done. I'm glad that we didn't, as the technical debt from lower quality code and weaker engineers on the team would've ended up hurting the team and the product.
Building a good engineering culture is certainly a lot of work, but the resulting work environment is well worth it.
----------
[1] Bill Walsh. The Score Takes Care of Itself: My Philosophy of Leadershiphttp://books.google.com/b
[2] Scaling Instagram.
http://www.scribd.com/doc
[3] Scaling Facebook to 500 Million Users and Beyond. https://www.facebook.com/
[4] Measure Anything, Measure Everything. http://codeascraft.etsy.c
[5] http://graphite.wikidot.c
[6] https://github.com/etsy/s
[7] Daniel Jackson. Software Abstractions: Logic, Language, and Analysishttp://mitpress.mit.edu/c
[8] http://research.google.co
[9] What is an SSTable in Google's internal infrastructure?
[10] http://code.google.com/p/
[11] https://thrift.apache.org
[12] https://github.com/facebo
[13] http://hive.apache.org/
[14] http://www.quora.com/Shre
[15] http://phabricator.org/
[16] Alex Osborn. Your Creative Power. http://www.amazon.com/You
[17] Groupthink. http://www.newyorker.com/
[18] What is "bus number" and why do you want it to be greater than 1?
[19] How do experienced engineers at startups avoid stagnation due to the overabundance of operational issues?
[20] Communicating with Code. http://paulbuchheit.blogs
[21] Engineering in Silicon Valley: How does Google's "Innovation Time Off" (20% time) work, in practice?
[22] http://www.atlassian.com/
[23] Inside Facebook’s final Palo Alto Hackathon. http://gigaom.com/2011/12
[24] http://en.wikipedia.org/w
[25] What is an "A Player"?
[26] What I learned from Steve Jobs. http://blog.guykawasaki.c
[27] http://algeri-wong.com/yi
1. Optimize for iteration speed.
Quick iteration speed increases work motivation and excitement. Infrastructural and bureaucratic barriers to deploying code and launching features are some of the most common and frustrating reasons that engineers cite during interviews for why they're leaving their current companies.
Organizationally, quick iteration speed means giving engineers and designers flexibility and autonomy to make day-to-day decisions without asking for permission. While I was at Google, any user-visible change to search results, even for low-traffic experiments, required Marissa Mayer's approval at a weekly UI review. Needless to say, while this allowed Google to protect its search brand, it significantly hampered innovation. Optimizing for iteration speed also means that there are well-defined processes for launching products, so that cancellations don't happen unexpectedly after significant time investment.
Infrastructurally, optimizing for iteration speed means building out continuous deployment with a fast deployment process, high test coverage to reduce build and site breakages, fast unit tests so that people run them, and fast and incremental compiles and reloads to reduce development time. Continuous deployment, where commits go immediately to production, deserves a special mention. Prior to using it at Quora, it would've been hard for me to internalize that the benefits it provides toward iteration speed outweigh the risks of site breakages, at least for small engineering teams. People are more excited about features and incentivized to fix bugs because changes see live traffic quickly. It's also significantly easier to reason about and pinpoint the source of errors for a narrow window of committed code rather a week or more's worth of batched changes.
Team-wise, fast iteration speed means having a set of strong leaders to help coordinate and drive team efforts. Key stakeholders in a decision need to decide effectively and commit to their choices. To borrow a phrase from Bill Walsh, a leader who coached the 49ers to 3 Super Bowls, strong leaders need to "commit, explode, recover," which means committing to a plan of attack, executing it, and then reacting to the results. A team crippled with indecisiveness will just cause individual efforts to flounder. [1]
2. Push relentlessly toward automation.
In his tech talk "Scaling Instagram", Instagram co-founder Mike Krieger cited "optimize for minimal operational burden" as a key lesson his 13-person team learned in scaling the product to tens of millions of users. [2] As a product grows, so does the operational burden per engineer, as measured by the ratio of users to engineers or of features to engineers. Facebook, for example, is well-known for touting scaling metrics like supporting over 1 million users per engineer. [3]
Automating solutions and scripting repetitive tasks are important because they free up the engineering team to work on the actual product. Ensuring that services restart automatically if possible when they fail and that services are easily and quickly replicated at peak traffic is the only sane way to manage complexity at scale. In the short-term, there's always the tempting tradeoff of applying a quick band-aid manually rather than automating and testing a long-term fix.
Etsy's motto of "measure anything, measure everything" [4] and its support of open-source monitoring and charting tools like graphite [5] and statsd [6] highlight an important aspect of automation -- that automation must be driven by data and monitoring. Without monitoring and logs to know what, how, or why something is going wrong, automation is difficult. A good follow-up motto would be to "measure anything, measure everything, and automate as much as possible."
3. Build the right software abstractions.
MIT Professor Daniel Jackson captures the importance of software abstractions well [7]:
"Pick the right ones, and programming will flow naturally from design; modules will have small and simple interfaces; and new functionality will more likely fit in without extensive reorganization. Pick the wrong ones, and programming will be a series of nasty surprises: interfaces will become baroque and clumsy as they are forced to accommodate unanticipated interactions, and even the simplest of changes will be hard to make."
Part of what allowed thousands of engineers to build scalable systems at Google is that really smart engineers like Jeff Dean and Sanjay Ghemawat built simple but versatile abstractions like MapReduce [8], SSTable [9], protocol buffers [10], and the like. Part of what allowed Facebook engineering to scale up is the focus on similarly core abstractions like Thrift [11], Scribe [12], and Hive [13]. And part of what allows designers to build products effectively at Quora is that Webnode and Livenode [14] are fairly easy to understand and build on top of.
Keeping core abstractions simple and general reduces the need for custom solutions and increases the team's familiarity and expertise with the common abstractions. The growing popularity and reliability of systems like Memcached, Redis, MongoDB, etc. have reduced the need to build custom storage and caching systems. Funneling the team's focus onto a small number of core abstractions rather than fragmenting it over many ad-hoc solutions means that common libraries get more robust, monitoring gets more intelligent, performance characteristics get better understood, and tests get more comprehensive. All of this helps contribute to a simpler system with reduced operational burden.
4. Develop a focus on high code quality with code reviews.
Maintaining a high-quality code base increases the productivity of the entire engineering team. Cleaner code is easier to reason about, quicker to develop on, more amenable to changes, and less susceptible to bugs. A healthy code review process makes this possible.
Establishing a process for timely code reviews, whether pre-commit or post-commit, improves code quality in a few ways. First, the peer pressure of knowing that someone will be reviewing your code and that committing poorly written code will likely let down your teammates is a strong deterrent against hacky, unmaintainable, or untested code. Second, code reviews provide opportunities for the code reviewer and author to learn from each other to write better code.
If the code reviews are easily accessible to other members of the engineering team, then the reviews also bring along the benefits of a) increasing accountability for reviewing code in a timely manner, b) allowing team members -- particularly, newer ones -- to model off of others' good code reviews, and c) speeding up the dissemination of best coding practices.
Counter-arguments that nimble teams don't have time to spend on code reviews ignore the technical debt that can easily accumulate from poorly written code. Ooyala, in its very early startup days, used to optimize for cranking out as many features as possible, with an absence of code reviews; the result was that while the initial product may have gone to market more quickly, the resultant code became painful to modify, and we spent over a year just rewriting brittle code to eliminate technical debt.
Google, at its size, does pre-commit code reviews for all code, but smaller teams don't need to be as comprehensive or strict, and not all code needs to be reviewed with the same rigor. Ooyala later adopted post-commit reviews over email for core or risky changes while I was there. At Quora, we currently conduct all code reviews in Phabricator [15], mostly post-commit, and apply different standards for model or controller code and view code; for sensitive code or for code from newer engineers, we'll either do pre-commit reviews or try to review them within a few hours of the code being submitted.
5. Maintain a respectful work environment.
Respect among peers forms the foundation for any type of open communication. A place where people feel comfortable challenging each other's ideas is one where sound ideas get forged through debate. A place where people easily get offended is one where crucial feedback gets withheld.
In 1948, Alex Osborn outlined the familiar brainstorming approach that's been popular in work environments for the past few decades, where participants come together, set aside criticism and negative feedback, and collectively pool together creative ideas without fear of being judged. [16] Respectful deferment of judgment is key to this type of brainstorming session. Recent psychology research has started to overturn Osborn's approach, suggesting that encouraging debate in brainstorming sessions actually helps to avoid groupthink and generates more effective ideas. In light of this research, a respectful environment becomes even more critical so that attacks are directed toward ideas rather than being ad-hominem. [17]
Engineering often spans a wide range of areas (systems, machine learning, product, etc.) and not everyone has the same expertise in each area. A strong team in fact probably ought to have individuals who are uniquely strong in certain areas even if they end up being deficient in others. This sometimes makes it tricky for say, a systems engineer to evaluate the proficiency of a product engineer, but it's important in a healthy engineering culture to respect those differences and to not judge solely based on your own strengths.
6. Build shared ownership of code.
While it's natural for individuals to become proficient in various parts of the code base or infrastructure, no one person should feel that they own or are the sole maintainer of any one piece. While having individuals become experts that own certain areas for a year or more might increase effectiveness in the short run, this approach ends up hurting in the long run.
Organizationally, shared code ownership provides three benefits. First, keeping the bus factor [18] greater than one relieves stress from the maintainer and reduces risk for the team in case the maintainer leaves. It also makes it difficult for that one person to take worry-free time off. I sure don't miss the days when I was the sole maintainer of Ooyala's logs processor and got texted by pager alerts while hiking on volcanoes in Hawaii.
Second, shared ownership empowers engineers who aren't knee-deep in the particular area to contribute fresh insights. It frees engineers from the sense that they're stuck on certain projects and encourages them to work on a diversity of projects, which helps to keep work interesting and boosts employee learning and motivation. In the long run, it reduces organizational risk that some engineer feels stagnated and decides to leave. [19]
Third, shared ownership also sets the foundation for having multiple team members swarm (a technique from agile development) together on a high-priority problem when necessary to finish a strategic goal more quickly. With siloed ownership, the burden typically falls on one or two people.
One mistake that many engineering organizations make too early on is dividing the entire team into subteams with tech leads when the team's still small. Subteams build walls of ownership that reduce incentive to cross those walls, since individuals will likely be assessed by their subteam's objectives. Ooyala had subteams while I was there, and one thing I missed out on was the opportunity to work with some folks on other teams; they've since adopted an agile development process with a much larger focus on shared code ownership that I've heard has made large strides in work happiness and productivity. One aspect of Quora that I've loved is that we've emphasized projects over teams, and I've had an opportunity to work on projects ranging from user growth, machine learning, moderation tools, recommendations, analytics, site speed, and spam detection.
7. Invest in automated testing.
Unit test coverage and some degree of integration test coverage is the only scalable way of managing a large codebase with a large group of people without constantly breaking the build or the product. Automated testing provides confidence in and meaningful protection against large-scale refactorings that are required to improve code quality. In the absence of rigorous automated testing, the time required for manual testing either by the engineering team or by an outsourced testing team easily becomes prohibitive, and it's easy to fall into a culture of fear for improving a piece of code just because it might break.
In practice, automated testing is a requirement for making continuous deployment work as the team grows. Codebase size grows over time as the product grows, but average familiarity with the codebase by team members decreases as new people join. Testing and validation are most easily done by the original code authors when the code is fresh in their minds than by those who try to modify the code months or years later. Encouraging a strong unit testing culture shifts the validation responsibility toward the authors.
8. Allot 20% time.
Gmail found its roots in Paul Buchheit's 20% project, and he hacked together the first version in a single day. [20] Google News, Google Transit, and Google Suggest also started and launched as 20% projects. I used 20% time while at Google to write a python framework that made it significantly easier to build search page demos. While Google's 20% time may be less productive now than during the early days of the company [21], the notion of letting engineers spend 20% of their time working on something not on their product map remains a cradle of innovation for smaller engineering organizations.
Ooyala didn't officially have 20% time while I was there, but I took some anyway and wrote a command-line build tool for Flex and Actionscript that sped up the team's build times, just as Adobe's Flex Builder tool chain started to degrade, and the tool's still in use today even though the engineering team has nearly tripled in size. Atlassian adopted 20% time after experimenting it for year. [22] A variation of 20% time that Facebook's fond of and that Ooyala added later is periodic hackathons -- all-night events where the rule is that you can work on anything except your normal project. [23]
Top-down approaches to product planning, while necessary for focusing the overall direction of the company, can't account to for the multitude of ideas that might arise from engineers closer to the ground. As long as engineers are accountable for their 20% time and focus on what can be high-impact changes, these projects can lead to large steps forward in progress. Without official 20% time, it's still possible but much more difficult for engineers and designers to try out crazy ideas -- the dedicated ones basically have to find weekends or vacation days to do it.
9. Build a culture of learning and continuous improvement.
Learning and being sufficiently challenged are requirements for what psychology professor Mihaly Csikszentmihalyi calls a state of "flow", where someone is so completely focused and motivated by what they're doing that they even lose track of time. [24] The direct and immediate feedback loop provided by faster iteration cycles is another requirement.
Weekly tech talks provide forums for engineers to share their designs or what they've built, creating an opportunity for engineers to take pride in their work and for the the team to learn more outside their immediate scope of work. Documenting processes internally like how a email service works or how to make ranking changes to a search service also empowers engineers to learn and explore new things on their own, nicely complementing 20% time. At Quora, we do this by running an internal instance of Quora where we ask product- and development-related questions.
A corollary of building a culture of learning is focusing on mentoring and training to make sure that everyone has the basic algorithms, systems, and product skills necessary for success. The more an engineering organization grows and the more effort gets spent on recruiting (particularly college recruiting), the more effort needs to be invested into mentoring and training. It might seem burdensome for a single mentor to spend an hour per day for a new hire's first 4 weeks on the job, but that investment represents less than 1% of the total time that hire will spend in a year and has significantly high leverage in determining whether the person is set up for success.
10. Hire the best.
Hiring the best is the foundation for many of the other philosophies listed. It's hard to respect someone if you think they're a B-level engineer. It's hard to give someone autonomy in product development if you don't trust their product instincts. It's hard to recognize the right abstraction to build without enough engineering experience. It's easy to fall into a trap of building something complex without other smart people to challenge your ideas and drive you toward simplicity.
There's a saying around Silicon Valley, coined by Steve Jobs, that "A players hire A players. B players hire C players." [25,26] Focusing on recruiting and hiring the right people is hard but critical to effectively growing an engineering organization. Yishan Wong, who previously was an engineering manager and director at Facebook, argued that hiring has to be the number one priority for everyone in the engineering organization, not just for managers, but for engineers as well. [27] He also quite rightly points out the difference between "hiring the best" and "hiring the best candidate that you've interviewed."
In the early days of Ooyala, we were so overwhelmed with the queue of inbound customer work that we nearly caved in to lowering our hiring bar so that we could hire enough people to get all our work done. I'm glad that we didn't, as the technical debt from lower quality code and weaker engineers on the team would've ended up hurting the team and the product.
Building a good engineering culture is certainly a lot of work, but the resulting work environment is well worth it.
----------
[1] Bill Walsh. The Score Takes Care of Itself: My Philosophy of Leadershiphttp://books.google.com/b
[2] Scaling Instagram.
http://www.scribd.com/doc
[3] Scaling Facebook to 500 Million Users and Beyond. https://www.facebook.com/
[4] Measure Anything, Measure Everything. http://codeascraft.etsy.c
[5] http://graphite.wikidot.c
[6] https://github.com/etsy/s
[7] Daniel Jackson. Software Abstractions: Logic, Language, and Analysishttp://mitpress.mit.edu/c
[8] http://research.google.co
[9] What is an SSTable in Google's internal infrastructure?
[10] http://code.google.com/p/
[11] https://thrift.apache.org
[12] https://github.com/facebo
[13] http://hive.apache.org/
[14] http://www.quora.com/Shre
[15] http://phabricator.org/
[16] Alex Osborn. Your Creative Power. http://www.amazon.com/You
[17] Groupthink. http://www.newyorker.com/
[18] What is "bus number" and why do you want it to be greater than 1?
[19] How do experienced engineers at startups avoid stagnation due to the overabundance of operational issues?
[20] Communicating with Code. http://paulbuchheit.blogs
[21] Engineering in Silicon Valley: How does Google's "Innovation Time Off" (20% time) work, in practice?
[22] http://www.atlassian.com/
[23] Inside Facebook’s final Palo Alto Hackathon. http://gigaom.com/2011/12
[24] http://en.wikipedia.org/w
[25] What is an "A Player"?
[26] What I learned from Steve Jobs. http://blog.guykawasaki.c
[27] http://algeri-wong.com/yi
Software Engineering: What makes a good engineering culture? - Quora
'via Blog this'
Thursday, March 29, 2012
Humor in interviewing/work, courtesy of Ask Annie (A CPA and a tax analyst walk into a bar...)
| |||
A CPA and a tax analyst walk into a bar...
Number crunchers who enjoy a good joke are more likely to succeed, says a new survey. They may even make more money. By Anne Fisher, contributor FORTUNE -- Accounting and the professionals who practice it don't strike most people as a barrel of laughs. Yet it seems that number crunchers who know how to lighten up are in demand. That's according to Accountemps, a finance-and-accounting staffing firm whose researchers recently asked about 1,400 chief financial officers, "How important is an employee's sense of humor to fitting into your company's corporate culture?" An overwhelming 79% said a little levity is "very" or "somewhat" important. Only 20% said it doesn't matter at all. "All work and no play can erode employee morale," observes Max Messmer, Accountemps' chairman, adding: "Job candidates should let their personality shine through when they meet with prospective employers. An interview is no place for a standup comedy routine, but it is the right time to show hiring managers you are approachable and will be easy to work with." Another survey, this one by Accountemps' parent Robert Half International, suggests that lightening up might even help with higher starting pay: For candidates with the right skills and great cultural fit, about 40% of CFOs are more willing to negotiate bigger salaries than they were a year ago. Only 5% of CFOs said they're less flexible on compensation for top candidates than in 2011. Messmer advises accounting mavens that "it's okay to laugh at yourself. Share a funny story. Kick off meetings with an amusing anecdote to put everyone at ease," before getting down to business. A comptroller, auditor, or compliance officer cracking up the room? Well, maybe. In defiance of the stereotype of accountants as humorless drones, the Internet is awash in accountant jokes, most of them on accounting websites, and thus presumably written by finance types themselves. Like this one: How many accountants does it take to change a light bulb? Let me run some numbers on that and I'll get back to you. Or this one: A surgeon, an accountant, and a lawyer are debating whose profession goes back the furthest. The surgeon says, "God made Eve out of Adam's rib, so obviously surgery came first." The accountant disagrees. "Before that, God created the universe by bringing order out of chaos," he says. "That's accounting." Then the attorney speaks up. "I've got you both beat," she says. "Answer me this. Who created the chaos?" Actually, that's more of a lawyer joke, isn't it? The verdict is still out on whether jocularity makes for better jurists. Filed under: Ask Annie, Contributors | About This Author  Anne Fisher Contributor, Fortune Anne Fisher has been writing "Ask Annie," a column on careers, for Fortune since 1996, helping readers navigate booms, recessions, changing industries, and changing ideas about what's appropriate in the workplace (and beyond). Anne is the author of two books, Wall Street Women (Knopf, 1990) and If My Career's on the Fast Track, Where Do I Get a Road Map? (William Morrow, 2001). She also writes the "Executive Inbox" column on New York City entrepreneurs for Crain's New York Business. | ||
Friday, March 16, 2012
6 questions to ask a job interviewer, thanks to Ask Annie!
| |||
6 questions to ask a job interviewer
To stand out from your competition, says an executive coach, you need to start a real, memorable conversation. Here's how to do it.Dear Annie: I've only been out of college a few years, and I was hired into my first real job (which I still have) by an on-campus recruiter at a career fair, so I don't have much experience with interviews. Now, I'm looking around for something a bit more challenging. I have some tech skills that happen to be in demand right now, so I'm getting interviews, and they've mostly gone pretty well so far.My problem is with the part of the discussion, usually at the end, when the hiring manager says, "Do you have any questions?" I research each company online beforehand, and can usually think of a few things to ask about industry trends or particular moves the company has made lately, but I keep feeling like my questions are too predictable (kind of boring, actually). What should I be asking? — Just Jerry Dear J.J.: "If you talk to recruiters and executives who are actively hiring, they will tell you they get three types of questions: "no questions, bad questions, and -- very rarely -- memorable questions," says Andrew Sobel. "The candidates asking the memorable questions are usually the ones who get job offers." Sobel, co-author of a new book called Power Questions: Build Relationships, Win New Business, Influence Others, is a longtime consultant and coach to senior managers at companies like Citigroup (C), Xerox (XRX), Cognizant (CTSH), and Ernst & Young. He says a recruiter for a fast-growing tech company told him recently, "You'd be surprised at how many job candidates have no questions at all, or they ask dumb questions like, 'So what do you do?'" MORE: The 10 investment banks employees most want to quitThat's too bad, because asking the right things is "how you create a thought-provoking conversation, which puts you a cut above the average candidate," Sobel observes.While there is nothing at all wrong with what you've been asking interviewers so far, he suggests adding a few of these to the mix: 1. Why? Questions like "Why did you close down your parts business rather than try to find a buyer for it?" or "Why did you decide to move to a product-based organization structure?" -- which it sounds as if you're already asking -- not only show you've done your homework on the company and put some thought into it, but are open-ended enough to spark an interesting conversation. As a rule, Sobel advises avoiding any question someone could answer with a "yes" or "no." 2. What has been your experience here? Without asking anything intrusive, you want to form a connection based on some understanding of the interviewer's situation. Sobel recommends something like, "I understand you joined the company five years ago. With all the growth you've had, how do you find the experience of working here now compared to when you started?" Or try: "What do you like most about working here?" 3. Show your value. In the interest of making the discussion a two-way street, think about mentioning a technique or process you've learned from your current job that a prospective employer might benefit from adopting. Obviously, with this approach, you have to be careful not to reveal proprietary information or give away any secrets. MORE: The one job banks and hedge funds can't fill4. Focus on the future. Ask something like, "You've achieved large productivity gains in the past three years. Where do you believe future operational improvements will come from?" or "Looking ahead to the next couple of years, what are the potential growth areas that people in the company are most excited about?" Not incidentally, the answers could give you a sense of where your own career path could lead if you get hired.5. Find out about the culture. You can learn a lot about what it would be like to work at a company, Sobel says, by asking, "What are the most common reasons why new hires don't work out here?" or, conversely, "What kinds of people really thrive in your organization?" Along similar lines, "Why do people come to work for you rather than a competitor, and why do you think they stay?" could yield some valuable insights. 6. What are the interviewer's selection criteria?Sobel says you should ask, "If you were to narrow the field to two final candidates for this job, with equal experience and skills, how would you choose one over the other?" You may not get a totally candid answer (the truth might be, for example, that the candidate with the lower salary requirement would win out), but you still might learn something worth knowing. The right questions, Sobel says, "allow you to demonstrate your knowledge without sounding arrogant, and they greatly improve your chances of hearing the best question of all -- 'How soon can you start?'" Talkback: What questions did you ask in your last job interview? If you're a hiring manager, which questions from candidates impress you most (or least)? Leave a comment below. Filed under: Ask Annie See more Ask Annie | |||
Friday, March 9, 2012
When your mentor is half a world away, courtesy of Ask Annie
| |||
When your mentor is half a world away
IBM's 170,000 virtual employees worldwide rarely, if ever, lay eyes on each other. Here's how they make long-distance mentoring work.By Anne Fisher, contributorFORTUNE -- Dear Annie: For the past two and a half years, since I graduated from college and got my first real job, I've been lucky to have a terrific mentor, a couple of levels above me in the company. We get together for lunch, coffee, or just a quick chat at least twice a month, sometimes more. Not only do I really enjoy these sessions, but her advice and insights have helped me get some great assignments (and a promotion). Now, she's been chosen to spend a year running a new operation we are starting up in China. It will be very demanding and, on top of the 12-hour time difference between here and there, she is going to be extremely busy. I'd like to continue our relationship, but I'm wondering, how realistic is it to expect that? — Waving Good-Bye Dear Waving: The short answer, from Nicki Rich: "If you both want it to work, there's no reason why it can't." Rich, a cloud computing executive at IBM (IBM) in Beaverton, Ore., has worked with about 25 mentees since she started at the company 14 years ago. While on an eight-week assignment in Asia in 2008, Rich began mentoring a junior colleague in Jakarta, and the two have stayed in close touch ever since. That's not to say the time difference presents no challenges. "It's nine hours later here than in Indonesia, so the best time for her to talk might be when I'm sitting down to dinner with my family -- or she'll send me a text at 3 a.m.," Rich says. "But it's not a problem. We both want to maintain the relationship, so we make adjustments." It helps that IBM, No. 5 on this year's list of the Most Admired Companies, has built a culture of knowledge sharing, including a strong emphasis on mentoring. Since about 40% of Big Blue's 426,000 employees worldwide are virtual or mobile -- meaning they work from the road, or from one-or-two-person outposts where they rarely meet bosses or colleagues in person -- the company has a wealth of experience with long-distance collaboration. "If there's a commitment from both parties, and a clear set of expectations, distance really becomes immaterial," says Sheila Forte, IBM's global chief of mentoring, based in Raleigh, N.C. and co-author of a book called Intelligent Mentoring: How IBM Creates Value through People, Knowledge, and Relationships. "In addition to our formal program, we encourage employees to seek out mentors and mentees anywhere in the world." Forte and Rich suggest four steps toward effective virtual mentoring: 1. Agree upfront on how often you'll meet, and via what medium. "Decide between you whether you'll have a formal session, say, monthly or quarterly," says Forte. "Once that's been agreed on, it's up to the mentee to schedule those dates ahead of time. If you're going to speak quarterly, set up those virtual meetings for the whole year ahead." Not that you won't sometimes reach out on the spur of the moment, she adds, but making appointments well in advance is "part of using your mentor's time wisely." At the same time, Forte advises, "Agree on what form of communication you both want to use -- email, IM, web cam, a combination? It sounds basic, but it's especially important when you're connecting across time zones." 2. Tap into all the available technology. Nicki Rich and her mentee "started out scheduling meetings once a month, then went to once every quarter as her needs changed," says Rich. "But I see her on Facebook every day. She posts a lot, both about what she's doing at work and her personal interests, which really helps us stay in touch. We also tweet and text." 3. Be specific and direct in asking for guidance. Once she gets to China, your mentor is going to be so busy that she probably won't have time to figure out what you need help with, so articulating that is going to be your job. Rich has coached her Jakarta mentee on large questions (should the mentee accept a bigger job at a competing company?) and smaller ones (whose technical expertise should she seek out for a particular project?). "She is very direct in asking me for exactly the information or insight she really needs at that moment," says Rich. "That helps me give her my best answer." Along the same lines, Forte adds, before each scheduled session, send your mentor an email description of any changes in your situation or other issues you want to discuss. "That way, you can get right into the substance of the discussion," she says. 4. Follow through between meetings. First, after each conversation, "send a summary of what came out of the discussion, just to make sure nothing slipped through the cracks or was misunderstood," Forte advises. "It's always a good idea, but especially when great distances are involved." And second, says Rich, let your mentor know how her advice worked out. "I appreciate knowing whether what I suggested was successful, and or less so. It's valuable for me to know what works and what I need to rethink," she says. "I learn a lot from hearing how a situation turned out. It really is a two-way street." Talkback: If you've ever had a virtual mentor -- or been one -- what worked for you? Leave a comment below. Filed under: Ask Annie, Contributors See more Ask Annie | |||
Subscribe to:
Posts (Atom)