Onboarding new Developers

How do you onboard new developers? Here is our problem:

We run an event twice a year where we ask people in the company to write some code for it. Most of them are NOT developers but more engineers so this isn’t their full time gig. Here are the challenges and what we’ve tried so far.

  1. This is a side project not their main job so they can’t invest a lot of time into it.
  2. We have an FAQ (granted it needs work) but no one read it.
  3. We have examples of the code in our Github but not many people referenced it.
  4. Developers are all over the world so time zones and language barriers can be a challenge. Makes it harder to do a lot of mentoring/shadowing.

The project is mostly CloudFormation templates that build some infrastructure, mostly EC2s some Service Catalog items and some Lambdas in there as well. Everything is checked into GitHub.

Any thoughts on things we could do? I thought about having them sign off that they read the FAQ or something. Open to ideas.


Where are they running into challenges? Are there tasks you’re asking them to do that aren’t part of the core objective? Are there ways that those tasks could be streamlined so that they push a button and it happens? You mentioned CloudFormation: are you already using launch stack URLs?

If onboarding has multiple steps, is there something you could do to orchestrate the process, like an app or chatbot that literally takes them step by step through what they need to get done, with an option to escalate to a human for help?

@raphabot can help me explain better.

Let me get more specific on the environment. So these are Capture The Flag events where each challenge builder has to come up with their own unique challenge. Simple example might be 2 EC2 instances where one is launching a network attack against the other. The builder has to create a CloudFormation Template that creates 2 EC2 instances and one has attack software maybe something in cron that just runs an attack. Super high-level example but a challenge can be serverless functions or a Kubernetes cluster or any number of AWS features. Those CFTs are launched by our backend system. The backend system loads them into a game board that players use. There is a Verify button that launches a lambda that can check to see if the player did whatever was necessary to block the attack as per the instructions in the challenge.

Issues we’ve seen with builders (just some examples):

  1. One didn’t know we had a Verify lambda and tried to write one themselves.
  2. Need to make sure all AMIs have SSM installed and IAM needs to have that enabled.
  3. Security groups too wide open. Players have to be restricted, otherwise they could get into parts of the AWS account that could give away too much info or maybe we don’t allow them access into the ec2 instance itself to see what’s happening. Same issue with IAM.

Happy to show you everything offline @glb if you interested.

1 Like

Oh, some of those are tougher than others and get right into “people are difficult” :joy:

  1. What does the problem statement you give to folks look like? I’m guessing you have docs that already say “don’t write a Verify Lambda function, we have done that for you” but maybe it could be streamlined?
  2. Do you allow developers to provide their own AMIs or can you say “you have to pick one of these”? If the first, then it’s trickier; you’d probably need to have testing that spins up the image and looks for the agent. I’m way out of my lane here (haven’t used EC2 in forever) but could you mandate that the user data / boot script installs the agent? Checking this and IAM permissions fit into the next thing.
  3. Have you met cfn-lint / cloudformation-guard? You can write rules that validate CloudFormation templates and help people self-correct before they get to you. I’ve found cfn-lint super-helpful for setting up guard rails for our teams.

Sounds like there is no “good way” to onboard people. :wink:

  1. So we are working on docs now. We are fairly new at this so our docs were brand new last time we tried this and we found a lot of holes. I’m attempting to writing a better doc and this time we will put it in Github along with the sample code and see if that’s better. Last time we tried a wiki in Teams but I think putting the build docs closer to the code will help. One stop shop.
  2. Thought about restricting the AMI but seems a bit anti-cloudy? Meaning the code should always deploy the latest thing yadda yadda. We do have a IAM role base that most people should use so I think we can do that pretty easily. To your next comment, we’ve really started leveraging linter stuff so we could probably have something in there to check for it. The other thing I thought about is that we could use sorta the canary account concept. When testing, deploy the AWS account like we would for a game and then run a few different security products against it. In this case, we’d be looking at things like Synk and Trend Micro’s Cloud Conformity. Conformity has rules to check to see if SSM is installed. We may end up with a hybrid of the last 2 items. (side note - funny to think that EC2 is starting to sound like “legacy” technology already)
  3. From what I’ve gathered, yes we are using linter but we could add some more rules. But that’s probably always the case with any project.
1 Like