Working at Texas State University
WOW! The past three months have flown by. I’m so honored and excited to announce that in November I accepted a position as a Front End Developer with the Texas School Safety Center. This blog is simply an opportunity to reflect on my first three months with this wonderful company, some tips concerning the entire application process, and how Flatiron set me up for success as a Front End Developer.
The Texas School Safety Center is a Research Center devoted to empowering school safety in regards to gun violence and tobacco use in schools. TxSSC provides resources for teachers, administrators, school-based law enforcement, and students across the state of Texas regarding these issues. Our small team manages the apps and creates content for these resources, making them accessible to schools across Texas. We have roughly 30,000 users across the state who are all required to participate in virtual or in-person training on safety in K-12 Public Schools.
From Application to Offer
The entire process from application to official job offer was incredibly fast, lasting only 10 days. I applied on a Tuesday, received a follow-up call on Friday, and interviewed the following Wednesday.
I received and accepted a job offer the day after our Zoom interview. Here are some things I learned from the interview process.
Find a company that you want to work for
This is easier said than done. When you’re looking for a job, you’ll apply to tens of hundreds of jobs. I personally applied to almost 150 jobs, and this was the first company to take a chance on me with an interview. What I didn’t realize, going into the interview process, is how my previous experience would influence the kind of company I would work for. Before coding, I taught middle school choir for four years in the Texas Public School System. In fact, while teaching, I was required to take some of the training programs that I’m now creating for the state of Texas. Understanding the apps from a personal UI experience, and helping fellow teachers with their own training programs is what helped me stand out from their pool of applicants.
Write a great cover letter
Do your best to write a great cover letter that shows your personality. Yes, you can talk about your experience, but don’t concentrate or try to “show off” in this area — that’s what a resume is for. Rather, talk about your personal connection to the company. Maybe you’re passionate about what they do, or you love their product. Dive into why you want to apply, and bridge off of that foundation. I have lived in San Marcos, Texas for four years, and I love how beautiful Texas State University’s campus is. So, I made that personal connection first, then dove into my experience as a teacher and related that experience to their position. If you only talk about how good you are at programming, you won’t make it past the initial cover letter scan. However, if you’re able to write a personal letter to the company you want to work for, you’ll have success.
Study, Study, Study…
Before the interview, keep studying and reviewing your fundamentals. I had some higher-level questions (explain MVC structure, what’s your approach to designing User-focused interfaces, etc.) and some lower-level questions (what’s the difference between a GET and POST request). You never know what you’re going to get, but here’s what I did to prepare:
- Write out a list of the required languages
Every job description has a “required” section. These are the skills that you must know in order to get your job done. Write out each language/library, and study the fundamentals of each language. Even if you already know a topic (ex: scope in JavaScript), take some time to review that topic and read an article or two on it.
- Write out a second list of the “good to know” languages
The “good to know” languages are ones that are listed as optional languages in the job description. They are the “extras” at a company. For example, Texas State uses Linux-based servers. We have a Network Specialist on our team, so I didn’t need to know Linux “lingo” going into the interview. However, I researched some basics on Linux servers so that I wouldn’t be phased if they asked me a question or two on Linux.
- Talk through coding challenges on your own
I did not have a coding challenge in my interview. However, I practiced going on LeetCode or Code Wars and literally talking through my process out loud. There are tons of articles and resources on this on the Medium and beyond (I embedded a link with 100+ coding interview questions… Just do a Google search to find even more!). Find a process that works for you, and practice it until it’s muscle memory. Basically, interviewers just want to know your thought process as you figure out a programing problem.
Be a human-being
This may sound tacky, but just be yourself throughout the entire process. When I had interviewed for teaching positions (previous 6–8 Grade teacher here…), I always acted like someone I wasn’t. I was impersonating a tough, but soft-hearted person, trying to fit into their perception of who a teacher should be, and I simply wasn’t being ME. I didn’t want to stumble into a job as a fake version of myself, so of course, going into the interview I was a nervous wreck. This was my first ever tech-related interview (besides the technical project reviews at Flatiron School), and my nerves were at an all-time high. Interviewing during Covid was… interesting. Normally, you commute to see where you’ll be working, see the office spaces, and have personal, face-to-face interactions with your potential coworkers. I honestly think that by having the interview from home via Zoom, I was able to be more of myself, because I was comfortable. As soon as my true personality shined, I was able to see my future coworkers’ personalities shine as well. Of course, we had the factual/technical portion of the interview. However, since I was me, Michael Bade, a normal human-being, the cultural portion turned out to be amazing.
What is their “why”?
When we’re asked the classic “what are your strengths/weaknesses” or “tell us about yourself” questions, we get an opportunity to shine. We can frame our experiences in a positive light, talk about our passions as programmers, and bring a wonderful energy into the interview. At the end of the interview, when they’ve given you the floor to ask questions, ask them why they work at this company. You’ll get to see each person’s reason for working at this coming, which can show their passion, or sometimes (unfortunately) their lack of passion. This can be a huge green flag to want to accept a potential offer, OR it can be a huge red flag to steer clear of this company once the interview is over. Most importantly, if your interviewers love where they work, they will show their enthusiasm and passion.
Negotiation
Once the official offer comes in, don’t be afraid to negotiate salary/benefits. Coming from a teaching background (which has a fixed pay-scale that is based off of years of experience), I never knew how negotiations worked. As a teacher, I was always taught to “do it for the kids, not the money.” So, the idea of bringing up salary was tricky for me. The key to negotiation, is knowing how to read the room and sense when you should negotiate. Never, ever bring up salary in an interview, unless the interviewer brings it up. If you bring up salary, the interviewer will think you’re only there for the pay raise or financial aspect (which I hope isn’t true — life is too short to focus on $$$, but that’s a whole other blog post in itself). Everyone has their own opinion, but I think a salary negotiation should happen in the interview when the interviewer brings it up or when a verbal offer is extended. Before you sign a contract, of course, you should know what your compensation is going to be. So, don’t ask too early, but don’t ask too late… When the time of negotiating comes up, make sure you’ve researched the average amount for the position AND location you’re interviewing in. A junior developer in Kansas City may make between $60k — $65k, whereas the same position in San Francisco may start at $110k. Don’t overshoot your expectations, be considerate, and have market-led research to back up your claim.
Three Months in…
I learned a LOT in just the first month. Since I’m working for a University, I started the job and two weeks later, I had a two week Winter break! So, this was definitely a great time to learn their stacks and codebase, refine my skills, and push some code into production.
Languages, Frameworks, and Libraries, Oh My!
In the first two weeks, I was assigned several tutorials, LinkedIn Learning courses, and Docs to review, in order to prepare myself for the languages and tools this organization uses. I was hired because I have experience in Rails and React/Redux (which the future of these apps will depend on). However, I had to learn some new (some “older” and some are modern) languages, in order to understand how to upgrade each app to today’s technologies. These other technologies included:
- Ember.js
- Backbone.js
- LESS
- SASS
- Haml
- Grunt.js
- NoSql
- Handlebars
- Linux-based CLI and Servers
Take great notes
Along with learning and reviewing these languages/tools, I realized the importance of taking great notes and documentation. Along with these languages, I was shown how to set up my local machine, how to deploy code after approval, submit code reviews, create bug tickets for my team, etc. Learning how your new company “works” takes a lot of time and practice. Every company has their own day-in, day-out procedures. Taking great notes helps chop down this learning curve, shows your commitment to the company, and creates an even more positive relationship with your coworkers. It shows that you can learn and adapt quickly. Since day one, I made a point to take at least 15 minutes after each meeting to review the procedures I used during that meeting, and write down a step-by-step process for every task we worked on. This will help you understand what you did, what your steps are for the future, and it will help you feel confident to contribute to updating README documentation as well.
Thanks, Flatiron!
All of this achievement is due, in large part to Flatiron School. I started the online self-paced program at Flatiron on May 11th, graduated October 21st, and had an offer on November 19th. The process was incredibly fast for me, which I’m so thankful for (especially during a pandemic). Two summers ago, I knew I wanted to be a Software Engineer. Flatiron provided the curriculum and job guarantee to make it happen, and they definitely followed through. Flatiron taught me how to learn by showing the fundamentals to programming, which ultimately set me up for success in this position.
Thanks, Texas School Safety Center!
Also, I can’t end this article without saying thanks to Texas School Safety Center for taking a chance on me. I feel a natural, easy-going-yet-no-slack connection with the team. The work environment with TxSSC is perfect for who I am. I’m so thankful to have my first SE position at a company writing “code that matters” for the entire state of Texas. After teaching in Texas for four years, I’ve seen the drug/weapon abuse in schools first hand, and this research center is providing resources and apps to help students and teachers feel safer at school. I’m so excited to have finished three months at TXSSC, and I can’t wait to see what the future holds!
Thanks for reading! To view Michael’s portfolio, click here. Michael is currently a Frontend Developer at TX School Safety Center. He recently graduated from Flatiron School, and is always happy to talk code. Feel free to connect on LinkedIn! Questions or comments are always welcome as well.
