11 karma · joined July 25, 2014
Would you refuse to work with a trainer if you were trying to improve at a physical activity? Would you reject a professional mentor in your field if it was on offer? Would you refute a doctor’s care if your physical health were impaired?
Also, it’s strange to refer to women as “females”, or treat all women as interchangeable, unless you run a crooked bar on a space station.
If we can start with the idea that interviews are a very blunt instrument, the process becomes at least somewhat compressible: it selects for people who recognize the parameters and perform well within that context. At best, that pattern-matches to success. At worst, it filters out talented folks who don’t interview well, but could code well.
GreatHorn (Techstars '15) is a new kind of cybersecurity platform that secures cloud-based communication systems, detecting and stopping spear phishing and credential theft attacks in realtime.
This is an opening for a full-stack developer with a strong background in Javascript, CSS, SQL, and data stores of all kinds.
You'll help to define the future of cloud security, work directly with the founding team on a wide range of (we think!) interesting problems, and have a material impact on the growth of the product from the ground up. This role will work across the entire product stack, from database connectors to UX, and define new ways to capture, analyze, and report on customer security data, along with helping to grow a system of services distributed across machines, languages, and networks. The ideal candidate will have experience working with cloud services (Google Apps, Azure, AWS, etc.), as well as a history of working within startup environments.
You can reach me directly at kobrien@greathorn.com, or apply online via https://www.ziprecruiter.com/job/be6442a3.
I've spent the last 17 years working for (and now running) tech startups in Boston; the worst of them ceded all fun to cube farms, but the best of them never went all-in on the culture described here. Perhaps there is an east/west coast division here?
I look at the folks working alongside me now, building an incredibly sophisticated machine learning engine for cybersecurity, and I wouldn't think to draw upon a Lego metaphor for what they're doing. It's hard, substantive, mathematical work, and certainly not akin to playing with toys. I expect my senior engineers, sales guys, and marketers to be both protective of the brand we're building and understanding of the need to grow fast and expand our teams.
As far as Linus' statements go, saying that security is imperfect by design isn't a new take on it, and I'm in complete agreement with you that it needs to be something that regular users can benefit from.
Have a clear, clean pitch deck. Know your unique value proposition, understand your competition, be able to demonstrate that there's a market and that it's significant. Show traction, team, and ability to execute.
For clarity's sake, I've sat on tremendously effective boards at the companies I have either run or had a senior role at, and I think there's incredible value to be had from a good VC relationship. The economic realities of raising can be frustrating, but it's a reflection on the industry rather than the individuals, I believe.
Early stage investment is just plain hard, and I think your point about the quantity of deals led is key.
So far, angel investors have been much easier to work with, although admittedly we chose to focus on customer growth once we had that first round of disappointing VC results.
I think, per the other comments, your background makes a difference (assuming you're talking post-Matasano) in how the message was delivered.
It doesn't make starting a company from scratch easier, but it does mean that (a) there are few "hard conversations" that can compare to the ones we've already had at some point, (b) trust is implicit, and (c) we can communicate very efficiently and effectively.
If founding is like marriage, then marry your best friend.
> No they don't.
A better approach is what the rest of the comments here are suggesting:
(1) store your secrets (API keys, certs, credentials, whatever) in a highly-secure system, with both strong encryption and immutable audit logging around their access and modification;
(2) expose those secrets at run/compile-time via variables, such that the secret is never stored on-disk anywhere other than in the highly-secure system from (1) and in transient storage while in use;
(3) wrap an authz layer around variable access, so that only authorized services/users/hosts (those that have authenticated properly and who are allowed access via the authz policy established here) can read/write/mutate the secrets
It's (basically) the "privileged identity management" space; the challenge is that the commercial software in that market hasn't kept up with the combination of automated ops infrastructure and cloud-hosted dev tools. There are some ideas around how to do 1-3 better, with a devops/cloud-native design built in. (Full disclosure: I'm part of the founding team at a company doing this.)