DEV Community: Living Security Engineering

From Bootcamp to the Trenches

Dan Schoonmaker — Thu, 27 Feb 2020 23:25:57 +0000

Hello! We’re the Living Security engineering team. A (currently) small group of engineers, within a startup company of around 20. We’re all working hard to build a world-class Cybersecurity Awareness training platform for enterprises.

We started this blog to share our daily victories and struggles with the world. Our hope is that as we continue to grow, sharing our experiences can help others learn and grow as well.

Today’s blog post is an interview with our newest hire, Gideon Ibemere, Jr.. Gideon recently graduated from a coding bootcamp, and with this becoming more and more common these days, we thought others may find his story informative.

Dan: Hey man, I’m glad we finally have a chance to sit down and do this, how’s it going?
Gideon: I’m living the dream, no complaints, man. Definitely looking forward to sharing my experience as a bootcamp grad and hope it provides some sort of guidance to others in a similar situation.

D: Yea, so let’s start off by having you tell the world a little about yourself.
G: So yeah, my name is Gideon Ibemere Jr., I moved up to Austin to join the Living Security engineering team just over a month ago. Before that I was at General Assembly’s Software Engineering Immersive bootcamp. So from April 2019 till July 2019 I would park my car on the East side and scooter down to 6th and Congress where I spent about nine hours a day, 5 days week working on code.

D: Damn, that's a legit bootcamp. What led you to pursue a coding bootcamp to begin with?
G: I’d been working on a remote agency with some friends and I’ve always been entrepreneurial, but execution made things slow down or come to a complete stop--execution as in getting a production ready site or product for people to interact with. I just didn’t have the complete skillset to do that. Also, the job I was working at was offering a stipend for furthering my education, so it all fell in line.

D: What sort of tech stack was taught there? Were there different tracks to choose from, or was it a pretty set curriculum?
G: Yeah, so, the curriculum for the GA bootcamps is created based on the demand in the area. So for my cohort, we had a “global” classroom with students from Austin, Dallas, San Francisco, and Los Angeles all learning the MERN stack (MongoDB, Express, React, and Node) and also Django + PostgresQL.

D: You said April to July, so a 3 month bootcamp?
G: Spot on--something like a minimum of 500 hours in class, 12ish weeks.

D: Before that, did you have any software development experience?
G: More like web development--I studied Art at Austin College in Sherman, TX--long story short, one of my senior shows was based on the intersection of [my] real life and the internet. I used basic HTML, SASS, and JavaScript to recreate the old discovery page of Snapchat with videos from 30 or more concerts I’d been to over my college career. It’s somewhere on the internet if you wanna check it out.

D: Once you started interviewing, did you feel prepared entering the job market? Did you feel like you were lacking in any particular areas?
G: Technically, I definitely needed to continue practicing authentication with JWT and definitely SQL/Relational databases. Also, I’d say I realized how I could improve my interviewing skills after my fourth or fifth go at it. General Assembly has a career focused portion of the curriculum called outcomes. This was extremely helpful in preparing for the job search, but I wasn’t very good at following the curriculum--I think if I had taken better advantage of that I would have had even better results. All in all, the bootcamp gave me a really good toolset to build upon while also job searching.

D: Do you keep in touch with anyone from your cohort? How are they doing finding jobs?
G: This is a funny one--they jokingly gave me a superlative related to this: “Most likely to not talk to anyone after the cohort.” I mean, they weren’t exactly wrong, I kept up with some of them for about a month or two after. A few were interviewed during the final week(s) of the bootcamp, others had jobs within the first month post-grad. Thinking about my most recent inquiry, there are probably two or three that are still looking for full-time opportunities.

D: Ok, let’s shift over to after you were hired by Living Security, how’s your first month been? How have things compared to your expectations?
G: Candidly, it has been sick! I’ve gotten to work on some pretty cool stuff that required a few different approaches. As such, I’ve learned a lot more than I could have imagined.

D: How was the interview process here compared to others? Any feedback on our interview process?
G: The interview process was part of the reason I was eager to accept the offer. I really enjoyed the collaborative nature of the interview even though I did feel like I could have performed at a higher level. To that point, the openness you and Matt showed helped to quell most of my nervousness. There were some interviews that felt like they were made for me to fail, some that I had the gall to ask if the problem I was solving had a real product connection to the job. In those cases I was met with gatekeeper attitudes versus the collaborative attitude you’d expect from an engineering team. Hope that makes sense

D: Yea, for sure. Where were some of the other companies you interviewed for? Were you always interested in joining a small team?
G: I interviewed with Lightspeed Systems, Sock Club, AnswersNow and a few others. I actually don’t have a preference in terms of team size. I’ve had experiences with small teams and gigantic teams, so I was and still am open to either or.

D: What are things you're doing now on the job that you feel maybe bootcamp did not fully prepare you for?
G: DEVOPS for sure. Deploying code to services other than Heroku and understanding different build options--webpack vs rollup etc. Also design patterns in writing code. Matt (our head of engineering) recommended I use a factory pattern on a project and I was like a kid in a candy shop when I read up on what it was.

D: Now that you're on the other side, do you think what you learned at bootcamp could have been learned on your own for free (or nearly free), even though it would have taken more time?
G: I think I could have learned it on my own, but the structure and proven curriculum was a better catalyst than my own will.

D: So overall, it sounds like you’ve had a pretty positive experience. Do you think you would recommend a coding bootcamp to a friend?
G: I have done and would continue to do so--it’s a cheaper alternative to a CS degree and you are able to impact the workforce as close to immediately as you can be. While job searching, I was able to help friends and family with their businesses and personal projects as ‘real world’ experiences post bootcamp. I’m not sure if I’d have that skill set directly after graduating from CS school.

D: This has been awesome man, it’s been great having you on the team. Can’t wait to see how you continue to grow.
G: Thanks for taking the time to do this! I’m excited to grow as an engineer at Living Security!

Why we take a "collaborative coding interview" approach

Matt Ward — Tue, 18 Feb 2020 17:10:12 +0000

The first time I interviewed for a position as a software engineer my experience was probably like most other engineers: I had a phone screen, I did a code challenge, and next I had an on-site technical interview.

Of course the on-site technical interview has its place. And for many companies and it is absolutely necessary, but in my experience (having been an interviewee many times) most companies follow the same rigid process to evaluate technical abilities of a candidate that will never even be used in the real world.

I concede and agree that there are also many companies where this type of technical interview is critically important in determining whether or not a candidate will be able to contribute to the success of the product. But as a hiring manager when you are deciding what type of process to run your candidate through you need to really take a step back and align your business priorities with your hiring process.

Particularly in a small company or a company comprised of small teams, soft skills are equally important to technical skills. In my experience as an interviewee, evaluating team cohesiveness was typically an afterthought.

In nearly all of the processes that I have gone through to “prove my worth” as a developer, a common theme was: I was sat in a room with multiple people who gave me a problem and watched on as I tried to solve it in a text editor (because IDEs are a crutch in an interview, but apparently not after you get hired.) In most cases, the problem I was given was clearly something that would never be encountered on a day-to-day basis - or possibly ever at the company.

There is a place for quantitative assessment in the interview process, and I believe in a basic code challenge up-front for that purpose. It provides you with a baseline for assessing candidates.

But once you have a candidate in the door, your mission should be to determine how you believe you can work with them, assessing their ability to learn, desire to grow, and assessing their ability to communicate and collaborate with the other team members. What’s more, you should be demonstrating to the candidate how you view them: as a peer and future team member. This person is not your adversary - they are a potential teammate.

I believe in a collaborative interview process which involves my team, the candidate, and myself. It is important to me that my team feels that the person we are interviewing is someone they can work with on a day-to-day basis. It is equally important the candidate feels comfortable interacting with the team as they may be a future team member.

To that extent, for an on-site, typically for the first 15-20 minutes we’ll just break the ice between everyone involved in the process and keep things very informal. I prefer to have some of my team members meet with the candidate without me so that there is less pressure.

Once everyone is feeling a bit more relaxed we typically move into the technical phase of the interview. As I mentioned, I believe this phase of the interview should be collaborative - as an assessment of how we could all work together, while also exercising the candidate’s technical abilities.

To feel collaborative, it is essential that everyone involved is trying to solve the same problem. To accomplish this, I will typically design a problem that spans 5-6 problem areas, based on a real-world problem and covers about 5-6 topics relevant to our development. Often, I will design the problem shortly before the interview, so that even I have questions. I prefer to not let my teammates know what the problem is until right before the interview as well, so everyone is on equal playing field.

When I present this problem to the candidate I make it clear that I want them to operate in a “real-world” setting. I want them to collaborate with me and my team, ask questions, use Google or any other assets at their disposal, and work together to come to a solution.

Of course I prefer that the candidate solve the problem entirely on their own, but even then, with my team not even sure of the solution themselves we can ask questions and engage in discussions and better assess our fit as a team.

Using this method - in addition to weeding out candidates who snuck through the initial technical assessment - we can better evaluate candidates on culture fit and soft skills while simultaneously evaluating technical ability.

I like this approach because it treats the candidate like a human. And by introducing a problem that no one on the team is prepared for it eliminates hubris, keeps everyone humble, forces everyone to pay attention and also provides the candidate an opportunity to actually teach the team something they may not have thought of.

If you are a technical leader and believe in building great teams I challenge you to work through an interview with a candidate on a problem you’re seeing for the first time. I believe you will be surprised and see unsuspecting candidates excel.

Preventing Accidents in the Workplace - with AWS

Matt Ward — Thu, 06 Feb 2020 17:44:01 +0000

When in production preventing data loss is often one of the highest priorities as an engineer, usually next to availability. Typically preventing data loss is focused on customer data, but what about losing the data the drives your application? Many applications today store static assets in some object store in the cloud and serve via CDN. Included in these static assets are typically things such as front-end application bundles which are the heart of the end-user experience.

If you’re working in the cloud, most cloud providers offer extremely durable storage solutions, AWS S3 offers eleven 9’s durability for example. This durability doesn’t help if someone accidentally deletes something though. Of course there are access controls to mitigate this scenario; you could lock out all engineers from resources that you feel are critical to your operation, but then you’ve created another problem - “zero trust” is a roadblock to productivity for most teams and in many cases is overused.

Assuming you trust your engineers to access your static resources, how can you mitigate production mistakes - i.e., deletion of resources? There are many solutions depending on your RTO or RPO objectives. Of course you need to weigh your tolerance for downtime with your cost of implementation and your ROI.

When talking about storing objects in S3 there are a lot of options at your disposal. A feature introduced at the end of 2018, S3 Object Lock, is a great feature that enables you to prevent the deletion of objects in S3 during a defined retention period. A caveat of this feature is that it doesn’t actually prevent overwriting objects. Another caveat of this feature, is that if you have a bucket that was created before November 26, 2018 it isn’t available to you!

If object lock is available to you though - you created a bucket after November 26, 2018 - you are well on your way to preventing accidental deletion of objects. What can you do to prevent overwriting objects though? Enable object versioning. Object versioning alone is going to protect your objects for the most-part. When coupled object lock and object versioning are going to give you a lot of protection against accidental deletion and modification. The difference is, object lock will prevent malicious deletion.

Great. What if you’re on working with a bucket created before November 26, 2018? And what if you do want to have zero trust to some extent - i.e., pure immutability. Enter S3 replication. With S3 replication you can choose to replicate cross region or same region to another bucket - replication effectively copies all of your newly added objects - after you have created the replication policy.

S3 replication will replicate your objects to another bucket of your choice cross region or same region. There is some nuance to how your buckets are configured and you can read more about that HERE but in general once you have replication configured, you can also configure zero trust on the destination bucket, object lock, and versioning giving you piece of mind that your data is backed-up, secure, and highly available (S3 offers 99.99% availability).

With data replicated to another bucket either cross region or same region you are well on your way to creating a highly available system for your customers. In a future post we will show you how you can use your replicated storage to use as a failover when needed.

Hello World

Dan Schoonmaker — Wed, 29 Jan 2020 15:08:16 +0000

The net economic value of creating another tech blog these days is near zero. That's my fear, anyway, as I set out on this journey.

Trust me. I don't want to just add to the noise. But there's something special about our team here at Living Security, and I would love to share that story.

Ghandi said, "whatever you do in life will be insignificant, but it’s important that you do it anyway." Because even though it sometimes feels like everyone around us already knows the information that we know, that is definitely not the case. We all have valuable information within our heads that may seem trivial to us, but to someone who is just starting out, may be invaluable.

So here we are. A small startup engineering team, fueled by coffee and determination, helping to build a cybersecurity awareness ed-tech company that we hope can make a small dent in the universe.

As for myself, my name is Dan. I joined the Living Security team in July 2019 as our 2nd full-time developer, and the person tasked with making our offline, experiential-based training more digital. To understand what that means, allow me to explain what it is we do here.

Living Security was founded in 2017, by two of my close friends, Drew & Ashley Rose. They knew professional organizations needed to do something to improve their boring cybersecurity training programs, so they went out and created an escape room product that an enterprise could use to train their employees on the latest security awareness concepts, relative to their industry. Their hypothesis was that this form of immersive training was exactly what companies needed to reduce the greatest security threat to their organization - their employees.

Once the Living Security escape room product got off the ground, and began making a name for itself, it was time to develop a SaaS product for ongoing cybersecurity awareness training. That's when the first version of CyberEscape, our online training platform was born. Our CEO Ashley went out and found a consulting company here in Austin to help her build an initial MVP version. This allowed her to share her early vision with potential customers, investors, and most importantly, us! Her eventual engineering team 👾.

Today, just over a year later, our online training is used daily by employees from all over the world, at some of the largest companies on the Fortune 1000 list.

For me, the opportunity to work at an ed-tech company, focused on an industry as important as cybersecurity was really enticing. In previous roles I never really felt like the work I was doing was making a positive impact on the world. Here at Living Security on the other hand, it's refreshing to know that the people using our software are learning important skills that will help protect not only their employer's sensitive data, but their own personal data as well. And in today's world where our data is commonly over-shared, sometimes even without our consent, keeping our sensitive data secure is more important than ever.

I hope you find our journey as entertaining and informative as it will be for us living through it. We would love to get to know you, hear your feedback, and hopefully provide value to the worldwide developer community.

Until next time, stay secure!

Dan