Why Sit on a Nonprofit Advisory Board

2014 Computer History Museum NextGen Board offsite (from left to right): Sunil Nagaraj (Vice President at Bessemer Venture Partners), Vishal Arya (Enterprise Relationships Manager at Marqeta),Veronica Pinchin (Product Manager at Google), Angela Tran Kingyens (Investor at Version One Ventures), Jeremiah Stone
(General Manager of Industrial Data Intelligence at GE), John Hollar (President & CEO at Computer History Museum), Joel Franusic (Senior Developer Evangelist at Okta), Michelle Zatlyn (CloudFlare co-founder), me.

A friend emailed me recently with the following question:

I noticed you sit on a few boards (saw your recent Facebook post). I'm curious what role you think board membership plays in a technical career. How and why did you start seeking out these types of roles?

Background: I sit on 2 nonprofit advisory boards: 

• NextGen Advisory Board for the Computer History Museum
• Industrial Advisory Board for the California Polytechnic State University's Computer Science Department 

Note: this is not a post about sitting on for-profit startup advisory boards. That is a topic for another post!

2014 Computer History Museum Fellows Awards with a few of my fellow CHM board members (from left to right): me, Bobby Johnson (CTO at Interana), Sunil Nagaraj (Vice President at Bessemer Venture Partners), Alec Detwiler (Business Development for Apple Pay)

advisory boards 101

First let me first clarify what it means to sit on an advisory board:

Sitting on a nonprofit board means that you are exposed to and gain a high-level understanding of the state of the entire organization. This comes through attending board meetings where you: listen, ask thoughtful questions, occasionally offer advice and volunteer time/experience.

I only sit on the boards of nonprofit organizations I care deeply about and where I personally identify with the mission of the organization. I am also very interested in how large organizations run and enjoy learning and contributing to them.

why you should sit on an advisory board

If you should seek out a board seat is largely dependent on your interests and your career goals:

If your goal is to be an executive or in high-level leadership position in any department (engineering, business development, sales, marketing) then sitting on a board is invaluable experience for understanding how large companies and nonprofits are run, what challenges they face and how they overcome those challenges. Spoiler: regardless if it’s a nonprofit (like the Computer History Museum) or a for-profit company, the #1 priority and #1 challenge these organizations have is hiring and convincing talented people to join them (exactly the same challenge as tech companies). I have also seen every organization struggle with marketing and branding, user acquisition and budgeting.

If your goal is to stay very technical on an engineering IC (individual contributor) track, there is very little value (above networking) to serving on a board. The people who sit on these boards are generally not on the "technical front lines" anymore as most are in leadership or executive positions. They are rarely writing code on a daily basis (although some do). You’re likely not going to have a deep technical discussion with your fellow board members, but you could if you really wanted to. When the board meeting entails having a long discussion about branding, for example, that should be something you have some peripheral interest in but likely won't have direct benefit to your technical career.

For people who plan to stay on very technical tracks I instead suggest serving on technical advisory boards: for example, the Django Software Foundation board falls into this category.

 

benefits of board membership

The beauty of serving on a board is hands-on experience and insight into large organizations without having to actually be in charge of an organization that size. I've become familiar with and even have some input in organizations that are much larger and more complex that Tindie. I can then take that experience back to my startup, so if we have an aforementioned branding problem, I can use the lessons learned from discussing branding at the board meeting.

The caliber of people on most boards is very high. For example, It would be difficult for me otherwise to form relationships with C-level executives (CEO, CIO, CTO) at public companies, but through the California Poly board I've gotten to know the CIO of GoDaddy quite well. It also exposes you to how people at very high levels think and how they approach problems: I have found it is very different from ICs or even people in leadership roles at small startups (mostly because they have seen these problems before and it's "not their first rodeo").

HOW TO FIND BOARDS ACCEPTING NEW MEMBERs

The tricky thing about board seats is that they are rarely publicly posted or announced. They have to come to you. All the boards I have sat on (or have been asked to sit on) I have not sought out. After 8 years in the Valley I’ve deliberately stayed in touch with and bought coffee for enough people that occasionally my name will come up for different opportunities.

It partially boils down to: if people know you exist, opportunities will eventually come to you. For me this has taken years of proactively staying in touch and offering to help. I don't do this because I hope to one day "cash in" on the relationship, but because I genuinely like people and enjoy helping when I can (I do at least 1 intro/week). A side effect of this is being top of mind when or if interesting opportunities arise, knowing full well that they may never arise!

I would also suggest that if this is something that interests you, tell people. Tell as many people as you can. When you meet with your peers at work, your mentors, your friends: tell them you're interested in sitting on an advisory board and ask if they know of any. This is a trick I learned from a mentor of mine years ago: for every meeting I have, close with a simple favor, for example: "I'm looking to join a nonprofit board, if you know of any please let me know!"

 

interviewing for boards

If you are considered for a position on a board you will go through an interview process. Usually you talk to several board members, although there was one interview where the whole board threw questions at me rapid fire (this seemed disorganized and if you chair a board I wouldn't recommend interviewing people like this). 

Know what your strengths are and how you can uniquely apply them to the board. For example, on the Computer History Museum board I knew that I was one of the few people considered who didn't have an MBA (but I do have a Masters degree in Computer Science)! Given it's the Computer History Museum I emphasized about my passion for computing and technical background as I am in the target demographic of the museum.

It is best to go into the interviews talking about what you can do for the board, not what the board can do for you. Highly organized and well run boards will be able to communicate the value you will get from joining the board. Sitting on a board isn't purely altruistic and there should be some value above just networking, and the board should be able to clearly and concisely communicate that.

note

This post was originally written as a reply to a question from a friend (see the beginning of the post).

The forcing function that caused me to blog about this was listening to the Andreessen Horowitz podcasts: The Truth about Serving on Boards and Building a Better Board.

That series of podcasts is about serving on the boards of large public companies (for example: Google, Nordstrom, Intel). They are great podcasts and I highly recommend listening to them, but for most people a board seat at a public company is out of reach.

However, if you are not a venture capitalist then joining a nonprofit board is can be good training to see if you enjoy serving on boards. If your career progresses to the point of being able to join public board, you will at least have some board experience.

3 Great Engineering Management Talks from 2014

Flickr / Michael Valli Photography 

Sasha Laundy recently reached out to me as part of a new project she's working on (I'll share more when it's public! :). She was curious if I'd seen any good tech talks recently, and if I'd be willing to share them with a larger audience along with why I thought they were great.

Although I do listen to a fair amount of tech talks (usually on 2x speed in the background while I'm working on tasks that requite little cognitive overhead), I've recently been more interested in technical/engineering management talks than talks about specific programming languages, frameworks or constructs.

I chose these talks not only because the speakers are excellent and very compelling, but they touch on a couple themes I have been thinking about recently.

general themes in these talks

• Hiring is really hard. Let me clue you into a secret: hiring is hard regardless if you're hiring engineers or sales people or community managers or executives. Across all the organizations I am involved with (large and small, for-profit and not-for-profit) hiring is the #1 priority and the #1 challenge.

For engineering specific hiring, keep in mind: you’re not hiring a “Rails Engineer” or a “Python Programmer” - you’re hiring someone who can help you change the world. It is very important to communicate the opportunity and the unique challenges of the job you're hiring for, not just describe a set of prerequisite skills the person should have. Raffi describes the unique scaling challenges on the Twitter platform team and how he communicated those to candidates. Harper and Dylan also touch on this when they were recruiting and hiring for the 2012 Obama for America Campaign.

• Rewriting systems is really hard. We believe we are going to replace our old Honda with a Tesla (so much improved! better than we ever could have imagined!) and this often ends in disaster.

As someone who has gutted and rewrote several production systems (all many magnitudes smaller than Twitter and Rent the Runway) not only was redesigning the architecture difficult, but what proved just as tricky was designing the database schema (which requires thinking through data access patterns in your new application that no one yet uses), how to migrate all the data to the new schema and how to verify that it actually worked.

Successful system rewrites require an incremental approach that takes months/years and often runs way over schedule. Both Raffi and Camille discuss rewriting Twitter and Rent the Runway respectively, not only from a technical perspective but a cultural and management perspective as well.

Without further ado, my favorite engineering management talks of 2014!

Two Developers, Many Lines of Code, and A Campaign that Made History

Harper Reed (CTO of Obama for America, now CEO of Modest) and Dylan Richard (Director of Eng of Obama for America, now CTO of Modest)

• 30 min talk + questions
• From an cultural perspective, Harper and Dylan were working at the intersection of two very different worlds: US politics/presidential campaigns and the technology/startup world of building highly scalable, fault tolerant systems.
• Harper speaks during the first half in an overview of the technology and process behind the 2012 Obama for America Campaign from how they recruited engineers to how they designed their technical infrastructure.
• Dylan then goes over Modest’s interview process (taking lessons learned from the campaign). He gives several tips around how they ensure they don't just hire "people who look like them." I found this very valuable as I am changing and refining our recruitment process in real time.

We've all dealt with systems that were less than ideal, that just barely worked, that we desperately wanted to rip out and replace. But what is the cost of doing this? From the standpoint both of the small company outgrowing its work, and the big company moving a major system, I'll discuss the real technical and cultural implications of replatforming, as well as some best and worst practices.

So You Want To Rewrite That

Camille Fournier (CTO of Rent the Runway)

• 42 min talk
• She focuses on rewrites within startups. This isn't a talk about rewriting very old, legacy software within large organizations, although in my opinion the lessons could be applied to rewrites of any size. 
• This is not a talk focused on which technologies to use, but rather how to approach a rewrite (Rent the Runway went from monolithic Drupal to Java services).
• Rewrites are dangerous because:
  • There are significant temptations along the way to build the Best System Ever. In other words: why build a car when you could build a plane? Why build a plane when you could build a rocketship? etc.
  • It is hard to know how exactly your new system should work, what it should look like, etc. since it doesn't exist yet and has no users. You can model it off your old system, but you're rewriting that for a reason.
  • If you're doing a lot of firefighting and afraid to change much then you likely don’t have time to think about the new system’s constraints. This is a very tough place to be when you’re just trying to keep the old system up (e.g. not release new features, just reduce downtime).
• Camille suggests changing as little as possible and bringing as much stability as you can to the current system. Swap out small parts, do one thing at a time.
• Also be aware of the cultural implications of a rewrite: people will be upset if you are rewriting “their baby." She does an excellent of talking about how you might approach a rewrite (and if you should even do one!).

EVERY PROBLEM IS A SCALING PROBLEM

Raffi Krikorian (former VP of Engineering at Twitter, now at Uber)

• 60 min talk + questions
• Raffi gave this talk at Etsy on how scaled the Twitter platform team from a culture/hiring/management perspective (not from a nitty gritty technical perspective, although he does weave some of that into the talk).
• He joined Twitter when it was 50 people and a giant monolithic Ruby app and left when it was 3K people and split into many different services. He was in charge of the team that rewrote Twitter; they never launched the first attempt (supposed to take 3 months but took 10 months) but did launch the second.
• One of the parts I particularly enjoyed: he talks about how writing software is an art, not a science: "You can rarely be trained for the exact path you’re going to take."
• A good portion of the talk is dedicated to recruiting and hiring: don’t use outside recruiters (they make you lazy). He was always the “closer”: the last person who talks to the candidate to ensure they understand the opportunity. Again, great advice on hiring/sourcing candidates and how to convince them to join.

An Unconventional Guide for Getting a Software Engineering Job

Working the Tindie booth at PyCon 2014 (Python programming conference). There were 54 other companies hiring engineers there (yes, I counted).

BACKGROUND

At the time of this writing, I’ve been in Silicon Valley for 8 years.

I’ve worked at big companies and small startups. I've interviewed at many of the usual suspects (Facebook, Google, etc.), as well as several startups (some now defunct, some on the road to IPO).

I’m currently a Senior Engineering Manager at Slack and was previously the CTO of Tindie. I have interviewed dozens of engineering candidates and spent the past several years mentoring junior engineers and hearing feedback on their interview experiences at companies large and small.

This blog post details all the aspects of finding a job that I wish someone had told me years ago. The majority of the advice I give is targeted at those looking for software engineering roles, but some of it can be generalized to other positions as well.

This advice is based on my personal experiences, as well as the experiences of my close peers, my mentors, people I have mentored, and other startup CTOs I’ve been in close contact with. As usual, YMMV (your miles may vary).

All the stories are true, but some of the names have been changed.

---

WHERE DO YOU WANT TO WORK?

"So who is hiring?"

Reframe: Think about:

• What industries am I passionate about?
• What apps do I use on my phone everyday?
• What websites/tools do I regularly visit? (browser history is your friend)

Early in my career I conducted very reactive job searches, rather than proactive, making it very hard for me to find a place I actually wanted to work.

I would let the jobs and recruiters come to me rather than keeping my eyes open for new opportunities. This often resulted in me interviewing at places I wasn’t interested in working, didn’t understand me or my career goals.

While interviewing at jobs you aren’t interested in can be good interview practice, it is not a good long term strategy for finding a job.

I got into the practice of asking peers that I respect and who know me well where they would work if they were going to leave their job tomorrow, and why. This yielded many great companies that weren’t on my radar.

---

Priorities, Priorities, Priorities

“I would consider any job!”

Reframe: What are your non-negotiables?

My first job at a startup required me to commute 3 hours total each day, and had almost no flexibility in terms of working from home.

As someone who is an avid runner, this was a disaster. I was working long days (10+ hours) so I would spend 13 hours away from home each day. I never had time to run, and if I did fit in a run before work I was exhausted. I’m much more productive after I run, and I often think through tough problems while I’m running. My quality of life suffered tremendously and I was a much less productive employee.

Write down a list of what is important to you for your next job. Consider factors such as:

• Location: are you willing to relocate, what is your max commuting time, etc.
• Big/small company: for small companies it helps to think in terms of the size of the engineering team: 5 engineers is a lot different than 50.
• Minimum salary requirements
• Flexibility to work from home
• Job role: are you okay with starting off in support or customer service? If interviewing for a management position are you okay with starting off as an IC (individual contributor)?

You may not know if you want to work at a startup or big company, or you may not care where the job is physically located - that is fine. Just write down what is important to you. If you don’t do this, you’ll find yourself compromising on things you never thought you would (“Maybe commuting 3 hours a day won’t be that bad...”).

---

Resumes

“I have done a lot of front-end work, but I’m interested in full stack...but maybe I should apply to front-end jobs and tailor my resume to that.”

Reframe: Don’t put yourself prematurely in a box.

In the Spring of 2011 I had breakfast with DJ Patil. I was interviewing at various startups and trying to figure out how to best tailor my experience for each role. The problem is that I love doing front-end work, back-end work, databases, product, etc.

He gave me a great piece of advice:

“Instead of pigeon holing yourself, instead tell them what you’re great at, what you’re passionate about. Then see if there is a fit."

Don’t mold your interests to fit their job requirements.

Great companies (the ones you want to work for) won’t pass on an excellent candidate because s/he doesn’t have exactly the specific skill set they are looking for. For example, companies that say “she has written Python, but we are a Ruby shop, so we can’t hire her” don’t understand that great engineers can not only can pick up new technologies quickly, but these passionate engineers love learning new things!

There are times when deep knowledge about a particular language/infrastructure are needed, but for most roles (especially junior positions), hiring a software engineering generalist is just fine.

Experience is (generally) replaceable, passion and enthusiasm are not; show that you are excited about engineering.

Further Reading: Nicholas Zakas has a great blog post Generalists and specialists: thoughts on hiring that I have found useful to understand at what stage hiring a specialist vs generalist is useful.

---

Understand how companies source and hire talent

“I’ll just send my resume to their jobs@company.com email address”

Reframe: Companies get hundreds, if not thousands of resumes sent to their job email address each day (this is called "inbound"). That is a lot of noise, and they often miss good candidates.

To illustrate this point: I have a close friend who has a CS degree from MIT. She’s worked at several large public companies. She decided to apply for jobs at several "hot" San Francisco startups. I define "hot" as companies that have significant inbound interest to their job postings and are frequently written about in the tech press. They are often top of mind to engineers applying for jobs.

She emailed her resume to their jobs email address.

She was turned down for every job without even 1 interview. Later, she had a friend at one of these companies deliver her resume to the hiring manager; she had lunch with him and she was fast tracked through the hiring process.

Most people think that hiring processes are optimized to help a company hire great people. This is often not the case. They are optimized to help a company NOT hire less competent people.

The implication of this is that they are less willing to take a chance on someone. Venture capitalists work the same way: they would rather pass on a deal that later was a home run than do a deal that ends up a disaster. The repercussions of dealing with a bad hire (or a bad deal) are much worse that the repercussions of passing on someone or something great. It’s all about risk mitigation.

---

how to find a contact in a company

• Have your resume/LinkedIn given to the company through an intro. Find someone in your network who knows someone at the company.
• If you can’t do this, find someone at the company (search their About pages, which often have links to employees’ LinkedIn, Twitter accounts, etc.) and email that person asking about the company. I’m not saying you should harass them, just politely reach out, indicate you’re interested in the company, ask for advice on how to apply. Most people want to help.
• If there are any women working there and you are a woman, specifically email them. If you are not a woman, don't do this. If there is someone at the company who went to the same university as you, that is also a way in.
• Startups often sponsor hackathons, meetups, etc. Stalk the companies (not people) you’re interested in and go to those events. Talk face to face with employees and if you feel the conversation is going well, get their email address. Follow up with your resume/LinkedIn and why you want to work there.

Further Reading: Sara Mauskoph wrote a great post about her job search process: Landing your next gig, particularly around reaching out to companies.

---

LinkedIn

"Do people actually use LinkedIn? I don’t think so, the last time I updated my profile was 2 years ago and no one looks at it."

Reframe: People use LinkedIn all the time. Really, all the time, and I'm not just talking about recruiters (although they use it a lot). To see this phenomenon in action read Elaine Wherry's "The Recruiter Honeypot".

The goal of using LinkedIn is to be easily findable for new job opportunities. This is especially true early in your career when no one knows who you are or that you even exist. 

I'm not saying you should never maintain a Word/PDF/text resume outside of LinkedIn (especially if you have worked on projects you can't publicly discuss on LinkedIn). However, if the majority of people searching for candidates use LinkedIn, then it behooves you to have a profile where people are looking! Creating a personal website, a GitHub profile, etc. are all great too, but how will people know to search for your personal website and find your resume when they don't know you exist?

How I use LinkedIn: I know a lot of people, more than I can possibly keep track of. When I'm mentoring someone and they are looking for a new job, I used to brainstorm who I should intro them to. This took a non-trivial amount of time and I would inevitably forget someone. Now I point them to my LinkedIn profile and they let me know who in my contacts they want to meet (another trick I learned from DJ Patil).

---

Recruiters are not your friends

“A recruiter at company XYZ emailed me and says I look amazing. How awesome! This recruiter really likes me and has my best interests at heart!”

Reframe: Outside recruiters (also called contingency recruiters - in other words, recruiters that do not work in house for a company) are typically paid 20%+ of salary for anyone they source (meaning find) and are subsequently hired by the company. So if you’re hired for $100K, recruiter gets $20K+.

Recruiters want to get as many candidates in front of a company as possible to increase their chances of one getting hired, and thus getting paid. I’m not saying recruiters are ill-willed or malicious, they will just say anything (truthful or not) to get you to respond to them. Don’t fall for recruiter flattery. 

I know of many engineers who assume that to start their job search they should find a great recruiter to help them. Great recruiters do exist but they are hard to find, so I would instead suggest Angel List Jobs or HIRED (especially early in your career).

For every email from an engineering candidate interested in a job I posted, I get 5-10 emails from recruiters (whom I have never met or corresponded with) telling me about all the engineering candidates they want to send to me. I do not respond to these unsolicited emails.

Further Reading: Elaine Wherry's The Recruiter Honeypot gives a great description of how recruiters work.

---

Interview Prep

“Every interview is so different so how could I possibly prepare?”

Reframe: Most tech interviews - especially those that have generic whiteboard coding questions - are like taking the SAT. If you study, you’ll do better.

There are two facets to interview prep:

• Educate yourself about the company. This sounds obvious and like a no-brainer, but you would be surprised how many people I have interviewed that really have no understanding of what my company does. Understand the technical challenges the company faces (a good place to start is the company's engineering blog).

To illustrate this point: Several years ago I interviewed at a San Francisco startup that was frequently in the news. I read all the articles about the company, including a couple in-depth pieces in WIRED magazine. I went through the CrunchBase profile of the founder. I read their blog, paying particular attention to the engineering challenges the company faced, and how they were approaching them.

In the interview they asked me how I would solve these exact challenges that I had read about. I was very glad I knew what they were beforehand and had spent some time thinking about these exact problems. It almost felt like cheating.

I asked them why they asked those questions, and they said that almost every person they had interviewed hadn’t read their press or their blog.

• Do practice technical whiteboard questions. Go through Programming Interviews Exposed and do all the questions. This is an excellent reference and walks through common questions with in-depth solutions.

If you need more, then tackle Cracking the Coding Interview - this is more of a rapid fire book with tons of questions and short answers, hence why I think you should go through the more detailed book first.

Programming interviews very frequently use questions from these books (sometimes with only slight changes) so it helps to gain familiarity with these questions.

Further Reading: Lynn Root (software engineer at Spotify) has a great blog post about how she prepared for her tech interviews.

Pro tip: A friend once told me: “Whenever someone asked a question I didn’t know, I would ask the interviewer what the solution was. Nine times out of ten, at my next interview, someone would ask the exact same question."

---

Interviews

"I’ll just show up and they will ask me a bunch of questions."

Reframe: Always, always have a list of questions that you will ask the company!

For the interview the company will need to gauge your skill level of what you explicitly state you are good at. So even though you might not write JavaScript everyday, the company will get their best JavaScript engineer to interview you if you say your best language is JavaScript.

I suggest asking these questions (in addition to your own):

• What are your expectations for a person in this role?
• What does success look like?

If you are interviewed by 8 different people and receive 8 different answers to the above questions, this is a very bad sign and indicates the company is not on the same page internally about what they are hiring for. You will never be successful at a company where your manager wants you to do ABC, the CEO wants you to do XYZ and VP of Engineering wants you to do 123.

I have found that women are frequently too humble and volunteer discussion of their weaknesses (this also applies to men but I have seen it more often happen with women). Honesty is important, but remember, you’re being compared to people who might overstate their strengths and understate their weaknesses.

Don’t go into a job interview saying what you can’t do or have limited experience doing. Instead talk what you have done, what you love and what you’d like to explore more.

Further Reading: 

• Julia Evans (software engineer at Stripe) has a great list of Questions I'm Asking In Interviews that she poses to potential employers.
• Cate Huston offers the perspective of the technical interviewer in How I Interview (Cate has extensive experience interviewing candidates at Google).

---

Salaries

"The company wants to give me an offer, but before they do so they have asked for my salary history. I better give them this or else they won’t offer me a job..."

Reframe: Do not give out previous salary information.

Companies want this information for several reasons:

• What other companies are paying their people (collecting data points for competitive analysis).
• Seeing how low of an offer they can get away with giving you.

To illustrate this point: in the Spring of 2011 several of my colleagues from IBM Research were leaving for other large tech companies in the Valley.

One was about to receive an offer from another large company, but first he had to submit 5 years of salary and bonus information. He obliged and got what he thought was a competitive offer, but it was the only place he interviewed so he wasn't actually sure of this.

A year later another colleague was thinking of joining that same tech company. She refused to give salary numbers, even after being repeatedly asked for this information from the recruiter. She instead got a competing job offer from another large tech company and used that offer (which was much higher than her current compensation) as leverage in the negotiation. Her offer for a role similar to his was 30% higher.

Since women are typically underpaid (generally speaking they don’t aggressively negotiate their starting salaries as often as men), a way to continue to be underpaid in the future is to disclose your current and previous salaries. This is also true in general for people who are not aggressive negotiators.

---

Offer Negotiation

"Wow, the company has given me an offer. It’s more than I expected! I should just accept right now." (this is an actual quote from someone I mentored)

Reframe: Companies generally expect you to negotiate. They usually build in 20% wiggle room, so if you are offered $50K they will probably would easily be open to negotiating up to $60K (and probably more), but this varies greatly by role. I have seen senior execs negotiate for 50% more.

No one will get offended by you negotiating for more money or better benefits. I have regularly seen male applicants ask for 40% more and end up with 20% more, and women applicants ask for 20% more and end up with 10%. If the company does get offended, then it’s likely not a good fit for you anyway.

There are exceptions to this rule:

• New grad positions, meaning people who have just graduated from college/university. Those salaries are often the same across the board at a company, but you can negotiate for things like relocation.
• Entry level developer positions, meaning people who have graduated from developer bootcamps or are newer to programming. For the same reasons above, many companies will fix these salaries across the company.
• There are some companies that don't allow for negotiation of their offers, but they will tell you that up front.

Negotiation is an important life skill, and people who do it come across as more senior and competent.

---

Which job should I choose?

"I have this great offer, I’ve negotiated up, so I should just take it!"

Reframe: Now that you have the money you want, will you be a cultural fit in the organization? In an ideal world you shouldn’t waste your time negotiating with a company that is obviously not a good cultural fit for you, but on the other hand it can be good practice.

Look at the managers/leaders of the company: CEO if it’s a startup, department head if it’s a larger company. The qualities that s/he exhibits are the qualities that will be valued in the company. For example, if they are aggressive, aggressive people will more often be promoted.

This is because of an intrinsic bias toward homophily - in other words, we like people more who are similar to us and often more frequently promote people who remind us of our “younger selves”.

At small startups, the background of the CEO generally dictates how decisions are made. Is s/he an engineer? Then most likely engineering will be more highly valued and have more of a say in decisions than other functions such as marketing, sales, business development, etc. This is because the CEO knows how engineering works and has innate biased towards it. In this case engineering is the CEO's “favorite child”.

I am not saying you should not take an engineering job at a company whose CEO used to be in sales, for example. However, if you do want to do this, ensure the technical leaders at the company are very strong and the CEO respects them.

There is a large downside to working at a company run by a former engineer: s/he will often be tempted to “help out” engineering since s/he feels most comfortable with that department because that is where s/he started.

This can be very dangerous because the CEO is likely very distracted with other very important tasks (like running the company) and so s/he might be very tempted to give “drive-by advice”: surface layer advice that well intentioned but not practical because it doesn’t come from a deep understanding of the intricacies of the problem. However, because the advice came from the CEO it is often taken very seriously (often too seriously) and can be very distracting.

The upside is you may have a lot of interaction with the CEO, the downside is you may have a lot of interaction with the CEO.

---

Equity

"The startup gave me an offer, but they are also giving me equity. I don’t know what this equity means! I guess it’s a reasonable amount and I should just accept."

Reframe: It is your responsibility to understand stock, options, vesting, etc. My good friend David Weekly has written a great guide that is targeted towards people that have no idea how this works: An Introduction to Stock Options for the Tech Entrepreneur or Startup Employee (long, but a good read). 

If you have never had a job offer that included equity before, then determining out how much the equity is worth can be very confusing. Do not be intimidated. Remember -- the value of your equity when you join the company might be very, very different from when you leave the company. It could be worth much more, or much less, but at the end of the day 10% (or any %) of $0 is $0 so just because the equity is worth something now doesn’t mean it always will be.

Further Reading: Offerletter.io has a great post about Understanding and Negotiating Startup Equity.

---

You've made it to the end! Thanks for reading. Please don't hesitate to contact me if you have feedback.

Intro to Hardware Hacking on the Arduino

Welcome to the Arduino tutorial I wish existed when I started playing with hardware.

Learn how to send an SMS text message in Python by pushing a button on your Arduino!

A couple years ago I was very new to hardware, hadn't touched a solder in over a decade, never used an Arduino or Raspberry Pi.

I wanted to play around with an Arduino but I didn't know where to begin. In the Fall of 2012 I joined Tindie as the first employee and that fueled my interest in hardware even more.

I'm a software engineer, love programming and preferred to program in Python on my Arduino instead of learning another new language. This was partially because all the cool third party libaries I love have Python bindings.

The tutorial is for you if:

• You have never used an Arduino or have some experience and want to learn how to run Python programs on your Arduino.
• You have some understanding of how to program. Teaching Python programming or programming in general is more than I could tackle here.
• You are comfortable using the command line.
• You know what GitHub is, have a basic understanding how to use it and know how to fork a repository.
• Regardless of skill level, you want to learn how to program your Arduino to send a SMS text message at the push of a button!

---

Background

Arduinos are awesome! But an Arduino doesn't in and of itself do anything. In some ways it's like a whiteboard: the whiteboard doesn't write on itself, it’s what you do with the whiteboard that makes it a useful tool.

This is why Arduino is called a platform. It enables you to build all kinds of amazing things, but it's a blank canvas.

To quote SparkFun:

“Arduino is an open-source electronics prototyping platform based on flexible, easy-to-use hardware and software. It’s intended for artists, designers, hobbyists, and anyone interested in creating interactive objects or environments. Or more simply, you load on some code and it can read sensors, perform actions based on inputs from buttons, control motors, and accept shields to further expand its capabilities. Really, you can do almost anything."

If you feel the need to purchase a book and have no electronics background I would suggest Getting Started with Arduino.

It's very basic and I read it cover-to-cover in one afternoon.

Purchasing an Arduino

I have been lucky enough to get all my Arduinos (yes I have a collection) at technical conferences (SendGrid was giving them away at PyCon), hackathons, and Maker Faire.

However, you can easily purchase one (or many!) on the Internet from places like Adafruit, SparkFun and even Amazon. The Arduino I am using in these examples is an Arduino UNO.

Before you purchase your Arduino I suggest you read through this tutorial especially the"Getting started" section because you might want to purchase a kit that includes an Arduino.

My very first Arduino. Apologies for the terrible iPhone photo...what can I say, it was 2013.

---

Unboxing

When you purchase an Arduino, you are purchasing a circuit board with a microcontroller.

A microcontroller is a small computer; there are microcontrollers in almost everything: microwaves, coffee machines, power drills, you get the idea. It doesn't even come with the USB cord you need to connect it to your laptop.

Here is what an Arduino looks like out of the box.

The top one is a plain Arduino Uno, the bottom one is an Arduino Uno SMD I got at Maker Faire (hence the "Make: Special Edition" printed on the board) but they are almost exactly the same. They have different microprocessors, but you can do the same types of hacks with both.

---

Getting Started

I have found it's very helpful to buy a kit that has some of the nice add-ons you need to build some sweet stuff.

The kits often contain a USB cord and some of the components you need to get started. Here is the kit I bought on Amazon; it’s nothing too fancy and less than $20:

I already had a USB cord, but there are several kits on Amazon that come with a USB cord.

Adafruit also sells several kits that have been well received and include an Arduino.

---

Plug In Your Arduino

1 Install the Arduino IDE. This includes some instructions for how to get your computer to recognize the Arduino.

2 I find it useful to ensure the computer recognizes the Arduino before I start programming. What if you write your whole program and can't get it to talk to the board? Specifically, this means ensuring the correct board and serial port are selected: 7 | Select your board and 8 | Select your serial port. If your computer can successfully talk to your Arduino, then the ON button (green one) should come on and the L button blinks orange:

3 If you want to see something cool, stick the longer (positive) end of an LED in the #13 pin (a pin is a slot on the Arduino board) and the shorter (negative) end in the GND pin (GND stands for "ground").

Just don't leave it plugged in for too long! The LED will draw too much current, burn really bright, get really hot and then die.

To read more awesomeness about LEDs, checkout this tutorial from Adafruit that includes some very interesting LED knowledge:

"One of the best things about modern LEDs is all the colors they come in. It used to be that LEDs were only red or maybe yellow and orange, which is why early electronics from the 70s and 80s only had red LEDs. The color emitted from an LED has to do with what type of material they are made of. So red, for example, is made with Gallium Arsenide. Since then, scientists have experimented with many other materials and figured out how to make other colors such as green and blue, as well as violet and white."

---

LOAD UP THE FIRMWARE

1 To program the Arduino using the IDE you must use the Processing program language. Although this isn't necessarily that hard, all the awesome 3rd party libraries (e.g. Twilio) don't have Processing bindings. So let's use something a little more fun: Python!

2 There are many different ways to talk to your Arduino using Python. The first step is to install the StandardFirmata on your Arduino (Firmatta is a protocol used to by a computer to communicate with the microcontroller).

• Plug in your Arduino via USB
• Open the Arduino IDE, select: File > Examples > Firmata > StandardFirmata

• Click the "Upload" button (arrow that points to the right)
• You should see a success message at the bottom of the IDE ("Done uploading")

Once you have the Firmatta installed you can talk to the Arduino using pyFirmatta or any library built on top of pyFirmatta.

In the following example we are going to use a library called BreakfastSerial that is built on top of pyFirmatta (meaning is abstracts away some of the complexities of pyFirmatta, much like Python abstracts away complexities of C).

BreakfastSerial is a great beginner library and can get you going fast. However, if you want to do more complex things you will likely need to drop down to the pyFirmatta layer.

For example, BreakfastSerial does a great job of abstracting away a lot of the physics of circuits and you don't have to worry about analog vs digital pins on the Arduino, but as you gain experience I have found it's fun to dig deeper and understand more of what's going on "behind the scenes".

---

Send a SMS Text Message

We are going to go through a simple example where you can send a SMS text message by pressing a button on your Arduino!

1 Assemble all the parts you need:

• 1 breadboard (That is the white thing with all the holes in it. The one pictured came with my kit and is a solderless breadboard. Since it doesn't require soldering, it is reusable and thus great for prototyping)
• 6 wires (color and length don't matter - they are all the same)
• 1 10K ohm resistor
• 1 button
• 1 LED (I'm using a red one in the photos below)

2 Hook up your arduino according to this diagram (replicated below). It doesn't matter if your Arduino looks exactly the same, the important part is that you hook the wires up exactly as in the picture and into the correct pins on the board (#2, 5V and GND).

It should look like the following photos (apologies that it is hard to see the little black button, but it is there on the breadboard). I also placed an LED in pin #13 as demonstrated in the Plug in Your Arduino step. You can see it sitting next to the board in the first photo and in pin #13 in the second photo:

If you're wondering "What is a resistor? Why do I need a resistor?" you should read this great answer on Electronics StackExchange. Here are all the resistors in my kit with the resistance labeled; I chose the one that says "10K":

If your resistors don't have a handy label on them you can still tell the resistance from the colored markings on the resistor itself. Here is a guide to decoding the colored markings.

2 I have written some code that we are going to run on your Arduino. Fork my txtduino repository on GitHub.

3 My code assumes you have LED hooked up to pin #13 and the button hooked up to pin #2. If you have used different pins, you will need to modify the code.

4 Ensure you install the requirements (txtduino depends on both pyFirmatta and BreakfastSerial, so both those libraries will be installed when you install the requirements):

$ pip install -r requirements

5 Sign up for a free Twilio account.

6 In settings.py you’ll see several variables you need to fill in with information from your Twilio account (your access key, phone number, etc.):

twilio_account_sid = 'PUT YOUR TWILIO ACCT SID HERE'
twilio_auth_token = 'PUT YOUR TWILIO AUTH TOKEN HERE'
your_phone_number = 'PUT YOUR PHONE NUMBER HERE'
your_twilio_number = 'PUT YOUR TWILIO PHONE NUMBER HERE'

7 Run the code on your Arduino!

$ python txtduino.py

The LED will blink several times while establishing a connection to the Arduino. After you see the message "Connecting to ..." you can now try sending your text message by pressing down firmly on the button.

I have added debugging statements so you can ensure your button press is registering. If you don't see the message "press down" then press the button again harder.

If all is hooked up correctly you should see the following output:

8 It can take several minutes for Twilio to send the text message, but usually quite quickly you'll see:

9 Now you can modify the code to do even more cool stuff - maybe send an email? You can try out the SendGrid API for example.

10 If you're itching for more hardware, you can checkout all the awesome boards and other components we have on Tindie from hardware hackers like yourself all over the world!

---

Thanks For Stopping By!

Hope you enjoyed the tutorial! Isn't hardware awesome?