Built to Adapt

Rotate, Repave, and Repair “Its idea is quite simple. Rotate datacenter credentials every few minutes or hours. Repave every server and application in the datacenter every few hours from a known good state. Repair vulnerable operating systems and application stacks consistently within hours of patch availability. Faster is safer.” https://builttoadapt.io/the-three-r-s-of-enterprise-security-rotate-re…

It's part of the Credhub vision to do so[0] (supporting "The 3 Rs", being rotate, repair, repave[1]). Pivotal has been sponsoring development. I was on the Credhub team for a while. When you begin to assume that you have (1) an always-on credentials service and (2) that it can serve multiple sides of credentialling (eg, service broker adds a credential, application fetches it), you get to do more aggressive cred management. I was on the Credhub team for about 6 months, while it was being worked on both US coasts. It's now based in NYC. [0] https://github.com/cloudfoundry-incubator/credhub/tree/master/docs [1] https://builttoadapt.io/the-three-r-s-of-enterprise-security-rotate-re…

Been doing sales/solutions engineering for the last 5-6 years. You can find how some companies describe the role: https://careers.google.com/stories/google-sales-engineering-insights/ https://www.facebook.com/careers/life/solutions-engineering-at-faceboo… https://builttoadapt.io/a-day-in-the-life-of-a-pivotal-platform-archit… Pros: + A lot of customer interaction. Could help you boost communication, presentation and sales skills if you want to start consulting + Quite a dynamic role, your agenda is not planned for next weeks but gets filled pretty fast with RFPs, Workshops, Demos, Proof of Concepts, etc. + As you are working in between of Sales, Product and Support/Delivery teams - that gives you a good perspective to provide valuable feedback across the company + Travel (can get boring after couple years though, and check with your partner if he/she is ok with that) Cons: - Some organizations are doing (Enterprise) Sales in old school way, in that case, Sales may just dump on your work they don't want to do like filling RFPs (Excel file with 100+ line of questions) or doing standard demos - Your technical skills may stagnate as you would be less hands-on, but that depends on the type of the product (e.g. SaaS vs SDKs, Platforms) - In terms of career development, you actually would have to choose if you want to go back to tech focusing on Solutions Architecture, or to Sales/Management roles Before agreeing to the role - discuss the actual…

I have yet to find an interview process that works better than RPI (Rob's Pairing Interview)[1] plus a day-in-the-life[2]. It gives both the employer and the candidate a chance to evaluate each other in context. As an employer, you get to see how the candidate performs on two different real-world tasks, as well as how they interact with existing employees. As an employee, you get to see what the company is really like to work with. No amount of whiteboarding can deliver that. And at the end of the day, if that relationship feels good, both parties can choose to continue onwards towards full employment. On the other hand, computer science trivia, by which I mean "implement Dijkstra or quicksort on a whiteboard", is a very poor means indeed by which to test for the ability to do real-world work in a real-world context. Sure, it's valuable to have a broad understanding of algorithms and data structures. But whiteboard interviews on those types of problems only tests how well you would do competing in an ACM (Association for Computing Machinery) challenge, not how well you can deal with "here is a totally new-to-you problem that lacks a precise solution, now work productively with a team to solve it under the constraints of an operating business" [1] https://builttoadapt.io/the-developer-hiring-process-is-broken-672bf27… [2] https://blog.jonrshar.pe/2016/Dec/05/pivotal-interviews.html