When I had my first internships, I remember that I was really hesitant to push code. I'd meticulously self-review my own code dozens of times before pushing my changes, rewriting the same components in a way that was slightly cleaner or more efficient. I distinctly remember a conversation with a more senior engineer on my team that went something like this:

Me: "I'm not sure if this is going to work."
Them: "So push it."
Me: "What?"
Them: "That's the fastest way to see if it's going to work."

And they were right—there ended up being some corner case in production I never would have thought of, and no test would have caught. The only way to really learn was to put the code out there, potentially make a mistake, and learn. This isn't to say you should never test your code or try to refactor anything, but spending too much time trying to get something to be perfect is often a lot worse than calling it done and moving on to the next thing. Making mistakes is okay as long as you're learning, and so don't become paralyzed because you're afraid of making one.

Moderation is such an important part of any community, and yet it's still an afterthought on so many platforms. Companies that are laser-focused on short-term growth might neglect moderation (if we ban users, then we have fewer users!), and people working on the product might not be fully empathizing with the experience of many people in the community. The bottom line is that it's still way too easy to be a jerk on the Internet and have a profoundly negative impact on someone else's life.

So, if I could change anything, I'd want to make technical and structural changes.

Quick, how many web frameworks can you name off the top of your head? Probably at least a few, right? Now, how many content moderation libraries can you immediately name? Probably none. The technical barrier to implementing ML-based moderation should simply be much lower than it is right now. It's certainly a hard technical problem, but one that's solvable. (And this isn't to say that ML is the only thing necessary to implement moderation, but it's a great starting point.)

Structurally, I wish more community products made strong content moderation a core pillar from the very start, as opposed to something that's tacked on at the end. Within organizations, moderation teams need to have a strong voice and ability to influence the product, which isn't the reality in many places today. Quora made moderation a top-level priority early on, and I don't think it would have grown to the same scale if it hadn't.

I love this question! Something we focus on in the early weeks of CS50, Harvard's introductory CS course, is the concept of "computational thinking". Computational thinking is all about framing problems methodically and breaking down problems into logical sequences of steps (i.e., inputs and outputs). Developers naturally do this while writing code—a function, for instance, takes an input, performs some logical sequence of steps, and returns some output. But, learning to logically break down problems is a skill that can apply to any domain and help make anyone a better critical thinker and a better communicator.

For more, here's a clip from CS50's "Computer Science for Business Professionals" course! cs50.harvard.edu/business/2017/wee...

Hiring is really important, and also really hard :)

One natural challenge that someone making their first hires or looking for a co-founder might run into is that nobody has heard of your company or vision yet! So, it's really important to articulate a clear vision for what problem you're solving, why you're solving it, and how you're going to do it. Putting this together in advance of talking to candidates can make those early conversations be productive.

Along the same line, when designing your interview process, be deliberate and specific about what you're looking for at each step—"good code" and "culture fit" are not specific! Instead, think about what a successful person in the role would do. Maybe you're hiring for a growth engineering role, where iterating fast and experimenting are more important than perfect code, or maybe you're hiring for a backend infrastructure role, where stability and performance are top priority. When looking for a co-founder specifically, think about what your strengths are and where your gaps are, and look for someone to help fill in those gaps. Maybe you're a great backend engineer, but you don't have experience with products or design—looking for a co-founder with some of those traits can help create a more balanced founding team. It's important to build a diverse team with a wide variety of skills and perspectives so you're ready to tackle any challenge that might come up.

Then, design your interviews accordingly. In many cases, simply asking a whiteboard, algorithm problem isn't going to be high-signal, because that skillset might not have anything to do for the role you're hiring for. (In fact, that process alone will likely cause you to miss out on huge number of great developers.) Instead, create a process that's reflective of what that person would do day-to-day, so you can get a better picture of how they'd fit into the team.

Finally, communication is a critically important skill in co-founders and early hires, but one that's often overlooked. At a small company, things will be moving fast and constantly changing, and if the team can't effectively communicate together, it's really easy to end up misaligned or have things slip through the cracks. Make sure that you're able to collaborate well with anyone you bring on, whether through pair programming or brainstorming on a problem together.