Startup Job Hunt Tips: Beware Startup Lies and Egos
This is a post in the ongoing series Startup Job Hunt Tips. This is only my own perspective.
When you're interviewing, lots of startups will overrepresent themselves. They will, purposely or not, fool you. Not all of them will do this. Plenty will be exceptions and will be perfectly truthful. But, so many startups overrepresent themselves that I feel it worth the warning to anybody looking to switch into the startup world.
Overrepresentation: "No experience necessary to apply here."
Reality:
When the startup originally wrote that job post saying no experience necessary, they thought they'd hire somebody without experience if everything else about the candidate felt right. In their hypothetical ideal world, they'd totally hire a non-experienced candidate, why not! However, when actually facing somebody with no relevant experience, even if everything else looks good, they'll probably pass. They meet their ideal candidate from their hypothetical world, but in real life. Then real life concerns come into play. They pass on the candidate. They probably ask the candidate to reach out again in a few months.
It can be infuriating when these startups say no experience is necessary, but proceed to reject you for having too little experience. Rest assured, it's them, not you. It's classic overrepresentation #1.
If you're working at a tech company with a reputation, a well-known brand, profitability, over 30 employees, and maybe realistic talks of exiting, then they might actually pay competitive salaries. Some of these companies will call themselves startups. As I said in a previous post, these are "pretend" startups. When one of these companies offers you a job, you should realistically expect that you deserve a truly competitive compensation package. In fact, if you receive anything less, you should not accept the job offer.
Then there are the other startups, the "real" startups. The companies which are small and new and struggling to prove themselves, gain marketshare, and sell. Real startups will likely ask you to take a paycut.
A seemingly long time ago, I interviewed at Typical Startup, and the CTO wanted to offer me a job. However, he ended up not doing so because my requested salary was too high for him. One of his other developers, with several years more experience than me, already got paid the same salary that I was already paid at the time. To be fair to his other developer, he couldn't offer me a job unless I took a paycut, unless I accepted a wage lower than entry-level. Of course, Typical Startup was hoping that I'd take responsibilities far beyond entry-level.
We ended up disagreeing on compensation and parted ways. I checked their website later. Typical Startup advertised providing "highly competitive salaries." Ha. That's stretching the truth a bit, don't you think.
A paycut is not inevitable, but it's still a high possibility at a "real" startup. It's your job to decide how much of a paycut is acceptable.
Overrepresentation: "We hire only smart people and do excellent work."
Reality:
Everybody says they hire smart people and do excellent work. Most companies, startups included, do not. The occasional startup will have a reputation for building great technology or being very particular with hiring. But those startups are exceptions. Most startups end up making hiring mistakes and shipping suboptimal work.
In fact, many startups hire very unremarkable people who do unremarkable work regularly. Be careful. Those startups will also insist that they hire smart people and do excellent work. You won't realize it's not true until you've already logged decent time with them.
During your interviews, it's your burden to prompt the startups to prove that they're smart and do good work. Don't take their word for it. Make them prove it.
Overrepresentation: "We have unique scalability problems."
Reality:
Girl, please. Every funded startup with traction has scalability problems. Every. Single. One. Are your scalability problems actually unique?
For some, yes. Their competitive advantage might be handling exceptional scalability.
For most others, no. At best, they have respectable scalability concerns. At worst, their unremarkable scalability is a problem only because they suck at handling it.
Overrepresentation: "You'll have lots of career growth opportunities working with us."
Reality:
You need to be proactive about developing your own career at a startup. Your career won't develop itself. Your boss probably won't develop it for you either, even if he promised career growth during the interview.
Startups move fast and are likely focusing on the products and customers first, building the team next, and developing your long-term career somewhere further down the list.
The real reason startups can offer good career growth opportunities is that you'll have little to no barriers to taking on more responsibility. Want to learn to code? Start learning and committing code. Want to contribute to design? Learn to use Chrome's Inspect Element on your favorite site. Want leadership experience? Start stepping up and taking initiative in your team.
You can do all this at a startup, and others will be thankful for it. However, nobody will give you private lessons or recommended reading. You need to figure out that stuff on your own, then be proactive and implement it. Startups help you learn and develop your career because they don't have the processes and politics to stop you from doing it yourself.
Startups will make it sound like your career will just shoot up. Your career could -- COULD -- grow ridiculously, but only if you're the one pushing the growth.
Overrepresentation: "We have a great culture."
Reality:
Girl, PLEASE. This is really just something that everybody MUST say. Nobody wants to admit they have a bad culture. Or, worse, they might believe they have a good culture, but it's actually not. Maybe they have a cool kids club celebrating and drinking the company kool-aid at the top, but everybody else doing the real work is suffering at the bottom.
It's just like how every startup says they hire smart people and do excellent work. Culture is important as well, but it's usually separate because building a good culture affects the cash flow statement much less directly than smart people and excellent work. There's always a shop that actually has smart people and does great work, but little thought goes toward its culture.
When a startup says they have a great culture, prompt them to give examples to prove it. Don't take their word for it without examples and proof.
Due to my interest in clojure and clojurescript, I stumbled across Colin Steele, a developer and CTO who rewrote his product in clojure. What I want to share has less to do with clojure and more to do with startups and just being an overall bad ass. Colin wrote these two posts, which are -- BY FAR -- my favorite startup war stories of the year.
Read the posts here and here.
I highly, highly recommend them to technical and non-technical audiences alike. There's a decent amount of technical discussion, but it should manageable, and just as technical as it needs to be to make its points. I'd argue that every non-technical person interested in tech should be able to comprehend these posts if they'd like to make meaningful contributions to a software product.
Even though the punchline of the posts is Colin's conclusion with clojure and AWS, the real takeaway is his whole process to his conclusion.
Here are some, but hardly all, of the elements which make it such a great tech startup war story:
Non-technical MBA cofounders, originally feeling validated by a business plan competition of all things -- all developers learn, generally sooner rather than later, about how wrong things could potentially be with a non-technical founding team
Scaling with a small team and (virtually) zero additional expenses
The classic Evolve Or Big Rewrite (TM) problem -- Colin inherits heavy technical debt and opts for the dramatic Big Rewrite!! :O
Absurdly problematic domain -- unhelpful 3rd party APIs, filthy data
The politics of a BigCo acquisition -- "why are you not using Java??"
Some of my favorite parts of the war story include:
Choosing tools based on the problem at hand, not on familiarity or loyalty to any particular tools themselves
Building an awesome team, which collectively devised clever data solutions and pioneered the single page app (the single page app, of course, being the life blood of UI and UX discussions in modern web development)
Finally, pulling it all off, hitting all business objectives, with only a 4-person team, without any late nights
I'm not joking when I say I'd like to see this turned into a movie.
Colin: I found your posts because I wanted to learn more about using clojure in web development. I left your posts feeling inspired to learn so much more. Thanks so much for sharing your experiences.
Particular minority groups complain way more than others online. This is a post written for people who are frustrated about being a discriminated minority and tweet or post statuses about how unfair and evil their worlds are. No, this post is NOT a rant post about these complaints. This is real, constructive input from somebody who grew up a discriminated minority and learned a few tricks along the way.
In my view, the steps to succeed as a discriminated minority are 1) acceptance, 2) peer selection, 3) self-investment, and 4) charismatic communication.
Acceptance is accepting that THE WORLD IS NOT FAIR. The world is the way it is. Do not live in a "should" world, where you're pissed off because things "should" be different. The harsh reality is that the world "should" be fair, but it is not.
Peer selection is choosing which people to be surrounded by. Of course, spend more time with constructive peers, less time with destructive peers. Unintuitively, you also should remove negativity, including negativity which supports your own views. Some of your peers in your minority group might tirelessly trumpet hateful language. Stop hanging out with them. Unfollow them on twitter. Negativity breeds more negativity. It only stops with you. If you want to change, you need to avoid the negativity. Yes, it's not fair that you're the one who has to suddenly swallow your pride and avoid negativity, but you should have already done the Acceptance step above. Negativity will weigh you down.
Self-investment is making yourself the role model that you'd like to see represent your minority group. It means being excellent, so fucking excellent that nobody can deny your substance. In the end, excellence is the most influential motivator for change. When you're undoubtedly, undeniably excellent, you will gain respect, even from those who once discriminated against you.
Charismatic communication is being able to talk to the discriminators with a sincere smile and teach them to be more respectful. This is the hardest part. If you're angry and still negative, you'll want to scream at them about how terrible they are, how they're wrong and bad people. But that won't change them. That won't deliver the justice for which you starve. If you want people to change, they need to WANT to change.
"YOU FUCKING ASSHOLE, THAT'S DISCRIMINATION!!" That is emotional, ineffective communication.
"Hey there! I appreciate your ideas, but I wanted to point out that the phrasing was hurtful." That could be the start of a constructive conversation in your favor.
You need to be charismatic. You need to be both respectful and respectable. You need to swallow your anger and communicate civilly. And you need to do it over, and over, and over again, every time you encounter more discriminators.
The key to succeeding as a discriminated minority is to be excellent. With these four steps, hopefully you'll be equipped to change the world as you see fit.
Startup Job Hunt Tips: Don't be infatuated with the startup's product
This is a post in the ongoing series Startup Job Hunt Tips. This is only my own perspective.
Let me tell you the story of when I interviewed at a startup whose product I loved.
This occurred in 2012, right after I finished Hacker School. I knew a co-founder at a very small startup. They made a social consumer product, in an industry which I found very exciting at the time. Since I was still a beginner programmer, I wasn't confident about finding a job as a developer yet. But I loved their product and got along very well with the co-founder. The co-founder wanted to introduce me to his CTO for an interview.
I was pumped for this interview. After working in management consulting and investment banking, I finally had a chance to work on a product in an industry which I thought was really awesome. I just had to nail the interview with the CTO!
Thing was, I was infatuated with their product. I extended that infatuation toward the startup itself and the team, including their CTO. This was a mistake.
When I finally got to meet the CTO, I was, to say the least, underwhelmed. The CTO didn't come off very bright. In fact, he was rude. He was an asshole. He was very proud about his chemical engineering background and considered himself better than other developers because of it. It was a weird superiority complex combined with inferiority complex towards other developers. Despite his current occupation as a developer, he said he wouldn't even be working as a programmer or in startups if he weren't at this particular startup. This CTO job was his first programming job, and he'd rather it also be his last programming job before he returned to chemical engineering.
As a CTO, he was also remarkably unaware and disinterested in the tech ecosystem. Uh, excuse me. You're the CTO. Your job is to know about the tech ecosystem. You're literally paid to know the ecosystem. And you still don't wanna do it?
Writing this post also reminded me that he didn't even use the product himself. The rest of the team all had usernames and were active participants in the product. Again, this was a social consumer product. Their value to investors and users derived from their community of users. He was not a user. How can the CTO not be a user? Does he literally only check out the product for development? Really?
Truly unfortunate about his role as a CTO is that he didn't know how to interview or assess other developers at all. If you're a developer, it's pretty clear what your skillset is. I was a new developer, so my skillset was even more obvious. But I was still a developer. I could contribute in very obvious ways. But the CTO insisted I understand slightly more advanced concepts, like efficient sql queries. He told me that he couldn't really see how he'd benefit from hiring somebody like me. Uh, seriously? I can't contribute just because I never used sql before?
I also remember him giving me a technical question which I couldn't answer. He gave me the answer afterward. But looking back, his answer was poorly communicated and not even entirely correct. And it was a very simple question too with a one-word answer. What kind of CTO can't answer HIS OWN simple technical questions correctly?
Maybe he's typically a nice guy. But somehow, interviewing me brought out a rude unimpressive asshole who miraculously became the CTO at a startup. I don't know. Maybe if I met him again, he'd give me a different impression. But that's how it played out. The result was my friend, the co-founder, emailing me that night saying that I was just too junior for them to take on at the time.
The co-founder was completely entitled to his own hiring decisions, and I totally respect that. But later that day, when I logged in again into their product, I finally saw the product for what it was. It was bad technology. It was slow. The design was poor. There were bugs everywhere. The user experience was awkward in many places, signaling to the current me that the api design was probably cumbersome. It was a hot mess. The CTO's actual abilities were revealed.
I realize now that the startup gained users because they hit a good niche. They weren't gaining users because of their technology; they gained users IN SPITE of their technology. And they weren't making any money. When a product benefits from network effects, like this social consumer product, it can grow in spite of its own lack of quality.
I was so blinded by my infatuation for the product that I didn't realize how bad it actually was. Had my conversation with the CTO gone well, I would have ended up working there and learning how to build bad software from him. That is NOT the environment I'd recommend anybody go to, especially when the startup earns no revenue.
Oh, and in case you're wondering, there WAS a way that I could have helped the CTO, despite his insistence that he couldn't see it. I could have made his product suck less. His product would have looked better, and he'd look like he did his job better.
My point is this. Your experience at a startup depends on the team and the quality of work they do. The industry and product can be nice draws, but they don't affect your daily life or your career progression as much. Don't dismiss a startup job opportunity just because you don't think the product or industry is sexy. If the CTO is unimpressive and the product is bad, it doesn't matter how sexy the product and industry are. You'll have a bad experience.
Well over a year after my conversation with the CTO, I have no idea how exactly the product grew. The co-founder is still my friend, and I genuinely hope his venture is successful. I imagine things changed for the better, since honestly there was nowhere else to go but up. But it taught me a valuable lesson. Don't be infatuated with a startup's product. Seek out job opportunities based on the teams.
Startup Job Hunt Tips: Two different strategies for two different types of startups
This is a post in the ongoing series Startup Job Hunt Tips. This is only my own perspective.
There are tech companies which pretend to be startups, and companies that are ACTUALLY startups. I'll call them pretend startups and actual startups.
Here's the difference between pretend startups and actual startups.
Pretend startups are stable and predictable. There's a good chance that they'll still be in business 6 or 12 months from today. They might have positive cashflows with happy customers and managed accounts. They probably have at least some BigCo behavior. But they still espouse silly shenanigans like "but we're just like a startup" or "we're basically a startup." When you hear something like that, give them your hardest side-eye. These companies know that startup branding is cool and advantageous. But they're just simply not startups. They're real companies.
Actual startups are unstable and unpredictable. You have no idea what will happen in 6 or 12 months. You might be in a different office. You might have killed several product and shipped several others. You might be bankrupt and at a new company. Startups, in their definition, are new companies still figuring out themselves and their position in the market.
Although I distinguish pretend startups from actual startups using stability and predictability, you could also opt to use company's business model as the distinguishing factor. Pretend startups execute on validated business models. Actual startups are searching for a valid business model. Pretend startups might consider an IPO a strong possibility in the future. Actual startups dream of stable revenues; only the lucky actual startups can dream about an IPO.
Aside: It's ironic that the term "startup" became trendy. A "startup," in my view, is basically a company that hasn't graduated yet to real company status.
Now, with the two different types of startups distinguished, what does this mean for getting jobs at either type of company? Especially if you have no prior experience in tech?
Pretend startups probably have BigCo resources. They're more likely to take chances on people with zero experience in tech. If you're inexperienced, target pretend startups.
Actual startups are tighter on cash. They tend to require more output from each employee. If you want a job at an actual startup, you can only keep that job if you deliver value greater than your own paycheck. If you're inexperienced, I'd wager that your most reliable way to a full-time job offer with an actual startup is by taking an internship with them first.
Pretend startups will be MUCH more likely to offer non-technical soft-skill jobs like product managers, or process-oriented jobs like project managers and QA testing. They have the budget to afford it. If those are the types of startup jobs you want, target pretend startups.
Actual startups will likely not want to spend any cash on anybody without either a technical skillset or the ability to sell. However, they'll REALLY want those types of roles. If you're able to create or sell tech products, actual startups are strong possibilities.
Startup Job Hunt Tips: Present yourself as a solution, not a smart person
This is a post in the ongoing series Startup Job Hunt Tips. This is only my own perspective.
The following type of interview does not go well:
"I'm a really smart person. These reasons are why I'm so smart. So, you should hire me."
Many people, particularly from business, are in the habit of interviewing like this. It probably works to get you entry-level finance and management consulting jobs. But if you want to leave those jobs into startups, you need a different presentation.
"I can offer these solutions to problems that you have." This is a MUCH more powerful value proposition. The reality at a thriving startup is that you're surrounded by smart people. Simply showing resume fluff is not enough.
You need to prove you can solve real problems for the startups. Programmers, designers, salespeople all have very explicit skillsets for explicit problems that companies face. Do you have a track record of solving these problems? If not, what have you taught yourself about solving these problems?
Most people looking to switch into startups fall into the cyclical inexperienced professional trap. "I need experience to get a job, but I can't get experience without a job!" So when you answer "no" to the question "do you have a track record of solving these problems," you better have an answer to "what have you taught yourself about solving these problems?"
Do not go into startup interviews or meetups thinking they'll be impressed with your intelligence. Intelligence is a bare prerequisite. When they see you're an intelligent hard worker who can solve their problems, the decision to hire you becomes an easy one.
Between 2010 and 2013, I did somewhere between 150 and 200 interviews for various industries and firm sizes. This included typical on-campus recruiting at target universities, a career switch from business to software development, and disorganized recruiting with startups. I've learned a LOT about finding jobs, interviewing, and changing careers as an unproven 20-something.
Some friends and others tend to solicit advice from me about getting jobs at startups, and the advice and anecdotes turn out to be the same. This series of short posts, aptly named Startup Job Hunt Tips, is a collection of my most meaningful and frequently shared observations, experiences, and advice.
My stories are most relevant to currently working professionals looking to make a career change into startups. This advice is probably not entirely relevant for current college students. But hopefully, others will find my material interesting too. Lastly, keep in mind that this is only my perspective. There's plenty of room for disagreement.
If you have any questions or would like to see more content, please hit me on twitter.
Contents of Startup Job Hunt Tips:
Present yourself as a solution, not a smart person
Why does everybody want to be a product manager? (coming soon)
Whether or not to learn to code (coming soon)
Two different strategies for two different types of startups
Whether or not to apply to Hacker School (coming soon)
Are you ready to make tradeoffs for startups? (coming soon)
Beware startup lies and egos
How to assess a startup job (coming soon)
The importance of having an opinion (coming soon)
Don't be infatuated with a startup's product
How to make the interview go both ways (coming soon)
A common way to discourage startups from hiring you (coming soon)
Manager: How much longer will it take for you to finish this feature?
Code Monkey: I'm guessing another two weeks.
Manager: We need this feature asap. If we add another developer, can we finish in one week?
Code Monkey: Uh, probably not, because of domain expertise and maybe minimizing technical debt... there's a lot of nuance which adds to the complexity, but none of it is easily divisible work.
Manager: Okay, but this is critical. What if we add two more developers instead of one more? Maybe then we can ship in three or four days instead?
-- Later in the day...
Code Monkey: By the way, Manager, congratulations on your pregnancy! When is your baby due?
Manager: Thank you, Code Monkey! My baby's coming in about six months!
Code Monkey: Awesome! Hehe, you ever wonder if nine women can work together to deliver a baby in a month??
Manager: Haha, ahh Code Monkey, I don't think it quite works that way...
Last January, I hurt my knee. It never felt like a big injury. My initial reaction was to take it easy for a week or two before going back to my normal active life. But it never got better.
Month by month, my knee pain persisted. I did physical therapy with a trusted therapist, and it still never healed. I did a ton of rehab exercises found online. None of it worked.
Today, an unbelievable ten months after my injury, I'm proud and relieved to have attended my first bboy practice since April and did my first normal footwork since January. My knee felt great before the practice, feels good now after the practice, but was a little sore during the practice. I need to rest a little more before practicing again. But, I'm fully certain I will recover very soon from my terribly persistent knee pain.
I learned a lot from this experience, but here are my main two takeaways:
First, your problems are not unique. Chances are, many people have suffered your problems, and some of them found ways to fix them. Always seek out those who are more experienced. In my case, some writing by Paul Ingraham was the final solution from a truly experienced professional that I needed. If you're having persistent joint pain, especially in your knees, I strongly recommend his material. I wouldn't be almost recovered without his writing. I wouldn't even have begun recovering without his writing. And I thought I tried everything before I found Paul. If you're struggling for answers for your joint pain, I beg you explore Paul's material. Always, always find the people who already fixed the problems that you have.
Second, true strength is patience. It's cool to get pumped up and dominate a workout, but that's hardly a real display of strength. That's showing up and performing one moment at a time. Patience is a constant effort, with no breaks or off-days or rest times. You can't exert patience for an hour a day, 4 days a week, and still see results, like you might for a workout. My bboy friend Jean Laguerre taught me that patience is another difficult form of strength in itself. He was beyond correct. If you cannot master patience, then your impatience becomes the #1 reason you aren't improving.
I'm still not 100% ready to start breaking again, but I'm so, so, so close. I have windmill burns on my shoulders and a headspin bruise at the tip of my head. But there's still a sliver of pain. I can't wait until I can dance freely, as I did up to January. But, until I can hit the floor again, until my knee is truly 100% ready, I'll just have to be patient.
Thanks to Paul, Jean, and everybody else who supported me this year through my knee injury.
If you're about this art form, you should know that this (and many other dance forms especially from the African diaspora) is a hidden language. We learn through exchange (dialogical approach Storm calls it). Whether by battling or sharing, you learn by observation (or via explicit instruction i.e. mentors or workshops) just as you would any language. You are then meant to express your voice through the language (develop your own style) whilst maintaining the traditions (otherwise known as foundation). Some people are tourists and don't understand the culture and just gain a superficial view of what we do. Those are the ones that don't last or think it's just about 'big' moves or difficulty or train with a gym mentality which is the same as learning and using a language to speak to themselves. It's not what u say but how u say it.
Again in the last 30 years programs have got hundreds to thousands of times larger (in terms of code lines) but programming languages haven't got that much better and our brains have not gotten any smarter. So the gap between what we can build and what we can understand is growing rapidly.
snowghoul
titsay
jbbartram-illu
blakekathryn
ellievsbear