The idea is to use private repos on Github, not public ones, which just tell you that yes, someone can read a public repo and misuse a key. Not that your private repos have potentialyl been compromised.
What: We are building a cybersecurity automation platform (IFTTT for security). We have an awesome, technically savvy team that has built multiple products and companies in the infosec space. Work with Go, Docker, and React to build a modern platform for security teams. PS: we're also fun. We routinely make breakfast together in the office, we're a diverse team across a wide age range + genders.
Culture: Team players, world class talent, no brilliant assholes. We have a culture of ownership + responsibility. We are all experienced devs and have great tooling/process even for a company so young.
Jobs: https://angel.co/komand/jobs. We're hiring primarily software engineers. Security background not required, but an interest helps.
Interview Process: We have a very collaborative interview process. We are looking to measure skills, not whiteboard ability. First, after an initial phone call, do a coding exercise offline and then come meet the team and pair with us.
"Imagine doing lots of small allocations - you can cause a lot of fragmentation resulting in needlessly having to resize your heap which in dire scenarios can result in thrashing."
The article repeatedly talks about how managing memory manually increases the risk of fragmentation. And that this risk somehow goes away with gc managed heaps.
...so garbage collectors don't also have to manage their own internal heaps and have fragmentation issues? Hm, not sure I buy this.
> Are there seriously investors that only back purely female teams? That seems ridiculously sexist and financially stupid to eliminate so many good startups that aren't all female.
I meant this to mean they have invested in all-female founding teams, not JUST all female teams. I have edited it to hopefully reflect that better.
Regarding your second point: I don't think the author's goal was purely to stop sexism in VC. She was describing her own experience. It's not a waste of time to educate people about the poor behaviors you see, regardless of whether or not she has a solution for it.
I sympathize with you, having also experienced subtle sexism in both the tech and investment world (I'm a technical co-founder, and I've fundraised successfully). Here's a couple of points I hope are helpful.
- You should look to connect with partners at firms that have female founders (ideally purely female-founding teams) among their portfolio. There are also a few female partners out there as well -- get access to them, with your YC network it should not be hard. Listen hard and press them to get honest, specific feedback when given "no"s.
- While the sexism is unfortunate and it's hard not to get frustrated, you may want to look long and hard at your pitch and company. If you've really talked to 40 investors and sent out ~500 emails, and this is a hot space for disruption, it's very unlikely that all of them are dismissing you due to gender; something isn't connecting. I's very easy to dismiss all feedback ("their feedback means nothing; they are rejecting me because I am a woman") just because you are soured by your bad sexist experiences.
Ask yourself these questions honestly: Are investors giving the same criticisms and feedback for saying no? Are there questions you struggle with in the pitch about your business? Is the value prop clear? Is the product demo well orchestrated? Try to examine all of the feedback you've gotten objectively, and see how can you improve the pitch. Find someone who is ideally involved in the venture community (e.g. as a partner, associate, EIR) that you can trust, that can give you brutally honest feedback on your pitch and business.
- Fundraising is hard for everyone. It's going to be harder for you. It sucks, but that's the truth of life. You are one of those pioneering women who are paving the path for others so hopefully in 20-30 years, it's not even an issue. It would be great if you didn't have to deal with this, but that's not the reality of the world. What doesn't kill your company will make you AND your company stronger.
IMO as long as the research in these tools are being funded by corporate entities (e.g., Microsoft) then there's little hope of any open research.
Fortunately, there's money to be had for open source and research projects that are willing to organize and look elsewhere for some cash. Look at projects like Bro and Suricata -- commercial security tools which are government and educator funded.
I would be more worried about the costs of licensing as a startup. What kind of sprawl will your architecture have? Do you have to pay for SQL server? Acquisition is sooo far ahead of where you are.
not true if they are taking on money. any investor will require a vesting period over 4 yr w/ usually a 1 yr cliff (which resets every time you take money)
It's missing some key features (Generics anyone?) that put it somewhere in terms of usability between C and Java, and it has nowhere near the same tooling or performance characteristics as the JVM. So, it has a while to go yet I think but would love to see a serious JVM competitor here.
I would be interested in the stats of 'successful' startup investments (for YC and otherwise), how many of those technical founders actually started programming at age ~13 (vs 17 or 18).
Would also be interested in seeing what the relative success/failures of investments with startup founders at 23 w/ 10 years experience (started programming in teams), vs 28 (who started programming at 18).
+1. If you want threads, build a node c++ addon that manages your threads/high performance work (and try not to pass too much back and forth with your Javascript, because of the performance overhead of marshaling described above). Which means you are just writing a lot of C++, and your javascript simply becomes a convenient interface to start/stop the processing and script actions on values emitted from your c++ addon.
Or, like everyone else recommends: use processes and ipc (e.g., the cluster module).