I met Todd Albert, the founder of Boca Code at an AWS networking event hosted by CloudHesive. He got a kick out of the fact that I was a plumber before I got into IT, so he invited me to speak to the 9th cohort of the Boca Code Developer Bootcamp
It was a great experience! The facility is cozy and everyone was super friendly. They also had great coffee and an awesome selection of laptop stickers!
I spoke about my journey from being a plumber to being a Sr. Architect at the leading Amazon Connect integrator, there were jokes, laughter, and most importantly - questions!
About 3 years - but you can get there sooner! The first 2 years I worked alone and didn’t have anyone to compare to, so I assumed I wasn’t very good but I kept studying and kept at it.
The 3rd year I worked with a team of sub-contractors on a project that got scrapped - so I figured that wasn’t a very good metric.
In my fourth year, I moved to another company with a full internal dev team - and I realized that in many respects I was ahead of guys with 10-15 years of experience. They knew A LOT, but much of that tech was already dead. I knew a lot MORE than them about the current tech.
Don’t forget that as a boot camp graduate, your education may be more current than the other devs. You still have to get experience, but I promise you are doing much better than your imposter syndrome is telling you.
Typically the onboarding material includes reading, and assignments to get you familiar with the toolset. If you are spinning your wheels for 2 days on something - and the answer is in the reading, this is a strong negative.
- You did not read the assignment and you just wasted 2 days because you are afraid to ask for help.
- I would rather you do the reading, do some googling, and when you are stuck for 4-8 hours, reach out for help. This work requires communication - maybe the requirements were unclear - being able to clear that up on your own initiative is very impressive!
Corollary - don’t ask for help for every little thing. Do your due diligence. Also, take notes - don’t ask the same thing over and over again.
I like to gauge a candidate’s skill level, and then dive a little deeper based on their response.
- For a Jr role, I may ask what is the difference between an RDBMS and a NoSQL DB.
- Followup: When would you choose one over the other and why?
- For a Mid role, I would ask them to name the 3 types of testing (Unit, Integration, Manual).
- What is the difference?
- How would you design your code to make testing easier? (expecting mocks & dependency injection)
- For a Sr role, I would have a conversation about design patterns.
- I always love to ask about personal or favorite projects. You have to love this work to be exceptional at it. If you don’t have any code you are proud of - it’s a turn-off.
- What is the most impactful project you have participated in? What was the impact - social, financial, etc? You have to be able to speak about your work in terms of return-on-investment
Be collaborative. If you are asked design questions they may be intentionally vague - ask the interviewer clarifying questions.
If the question requires a succinct factual response, and you don’t know the answer immediately, you can ask questions to get partial credit.
- I am not familiar with the term X, would you provide a short description and I may be able to able to answer the rest of the question.
- I have never used that in my work, but I think I know what it does based on your description - can I try to guess?
Remember not to B.S. during a technical interview. I prefer someone says honestly “I don’t know the answer, but am willing to try anyway if you give me some hints”.
In the real world, you will rarely have all the facts. You will have to reach out to the client who reported the bug and ask them to do a screen share so that you can see what is happening. Asking good questions is part of the job.
I work in an AWS shop. I would take an AWS certified bootcamp grad over a non-certified grad every day. It’s probably less relevant if the company is not using AWS, but it still shows personal initiative and a willingness to learn.
If you are applying to work for an AWS Partner, they have to have a minimum amount of AWS Certified engineers to maintain their partner status. Having a cert in this case is extremely useful.
During my talk, I mentioned a couple of concepts and a student asked me to elaborate on them.
I work in the call center space - for each minute a customer is on a call it costs the company $1. If you have thousands of agents and tens of thousands of calls per month, these figures start to add up!
Reducing the average call handle time for a call by 1% for a sufficiently large business can reduce costs by millions over several years. If I can contribute that improvement consistently - my career is made.
Typically IT is a cost center, not a profit center. You cost money. If you are doing your job well, you cost a lot of money.
You should NOT be doing work that a computer can do faster, better, and more consistently. For this reason, you should be on the lookout for automation, DevOps, scripts, or processes that reduce the amount of repetitive/manual work that you do, so you can focus on real innovations.
Example: If some nightly job runs for 3 hours - don’t bother spending 3 days speeding it up. It starts at 12:00, finishes by 3:00, and the first person that needs it is at 8:00. There is a 5-hour buffer - but you just cost the company 3 days for no economic benefit.
Not everything needs to be a script. If some work only happens once a month and takes 15 minutes - a How-To guide may be more appropriate. Next time you have to do the task, you can do it in 10 minutes, or simply hand it off to the new guy :)
If you can make yourself (and others) more productive through automation and/or documentation you will also go far.
It was fun to reflect on my journey and share some personal experiences with budding new developers!
Boca Code is an intense 40/hrs a week, for 10 weeks, software development bootcamp. Having spoke with the class and founders - I highly recommend them!