Before I started as a consultant at Red Hat I knew little beyond the title of the role what I would be doing on a day to day basis. People ask "... tech consultant? What is that?" And I've seen it described as a career path that is "less traditional" for those going to work in the software industry. Today I thought I'd dispel some of the mystery around the role of a software consultant and talk about key goals, roles, and terminology related to successful technical consulting.
What I learned through the Grace Hopper Celebration about getting hired
EDIT: Hi, Tiffany from 2019 here, I wrote this a year ago and never published it. Here is my experience interviewing at Red Hat while I was a computer engineering student at the University of Maryland in 2017. It was surreal getting to go to GHC with other Red Hatters so soon after joining, (and once again to do technical screenings in 2019). I wanted to write about my experiences not as a full-time associate at Red Hat but in the shoes of myself when I still figuring out where I wanted to work coming out of college. So without further ado…
During the 2018 Grace Hopper Celebration of Women in Computing (GHC), 22,000 attendees flooded the George Brown Convention Center in Houston Texas to network, learn and share information in celebration of women technologists. Students had the opportunity to pack their schedules with conversations, sessions, interviews, and a large list of companies to visit at the expo hall. For students at GHC, the expo hall also doubled as a career fair. Recruiters, engineers, scientists, and technologists were stationed in company booths to talk about their workplace. They screened resumes, interviewed candidates and shared their experiences. This year for the first time, I was able to attend GHC, not as a student seeking a position, but as an employee of Red Hat.
There’s no mistaking the Red Hat booth, even on the crowded expo floor. The first thing you notice is the bright Red Hat red and logo with the famous Shadowman. Best of all, smiling Red Hatters eager to tell you what life at Red Hat is like and, most importantly, learn more about you.
In my last year attending GHC as a student, I was drawn to the Red Hat booth with a number of attendees gathered around bins filled with packets of flower seeds, and booth walls decorated in Post-It notes spelling “innovation.”
I knew about Red Hat Enterprise Linux already but was more excited to hear about the day-to-day life of a Red Hatter when the recruiter approached me. It hadn't been as easy conversing with people at other booths, often the booths would be too crowded to stand and talk to anyone from the company, or the recruiters would be faced inward with conversations between each other.
At the time I had been interviewing for software engineering roles at other companies, but I wasn't quite sure if software engineering was what I wanted to do. It was definitely the most common path coming from university, where most graduating students I knew were aiming to become a software engineer. I also knew coming out of a few internships that no reasonable starting salary would pay enough for me to agree to work for a company where I would not be happy.
So I told the recruiter I had been seeking out alternatives to software engineering work to get insight into what I would enjoy most. “Great," was the recruiters’ ecstatic reply. She proceeded to ask if I had an interest in consulting after looking at my resume which stated an interest in full-time opportunities. Funny enough, consulting was an alternative to software engineering I was considering at the time. I knew that I had a knack for technology and sharing what I knew in order to solve problems. Next thing I know she's texting another recruiter to schedule an interview slot to learn more about the position. Luckily they had a single slot left for me on the last day of the conference.
At Red Hat we do many things differently, interviewing at GHC was one of those things. I came into the interview thinking I could predict the flow, I would talk about my resume and my experiences before asking my prepared questions related to culture, process, and organization.
Instead, we had a conversational interview with an introduction to the company, and questions that dove into my interests and passions related to technology. Red Hat cares not only about how much you know, but also about your talents and your passions. We believe that associates at Red Hat should be at the intersection of all three, enabling talent and passion with the necessary domain knowledge to succeed. The interview was around 25 minutes, not enough time to make a decision or compare prospects yet, but enough to pique my interest.
Friday after GHC Red Hat sent me a HackerRank invite. HackerRanks are timed (typically anywhere from 30 minutes to 2 hours) quizzes measuring technical aptitude used to screen candidates. A good score may move you forward, a bad one may end the process. Some comprise generic questions that can be practiced through Leetcode.com or studied through in the book Cracking The Coding Interview.
Red Hat’s HackerRank quiz was one of many that had been sent to me from my time interviewing during the hiring season. In typical Red Hat fashion, I was blown away by how different the coding challenge was compared to other HankerRanks. It was actually fun. At the end of the challenge was a bonus challenge that involved completing a task after SSH-ing into a VM with RHEL installed.
More than two weeks later, after completing the HackerRank submission, Red Hat invited me onsite to the headquarters in Raleigh, North Carolina. Due to a busy semester, I decided that this would be the last visit I would do to a company before making a decision on what offer to accept. As part of the visit to Raleigh, Red Hat hosted a casual networking dinner the night before the interviews so that candidates could meet people from the consulting organization. This was another chance to find out what consulting at Red Hat was like and to see Red Hatters interact with one another.
I learned that fellow Red Hatters cared about making a difference and that part of Red Hat's culture is to embrace "open collaboration." Being an open organization means that ideas can come from anywhere. Red Hat thrives on the ideas of others, and individuals have the willingness to adopt feedback and new ideas. After the final visit to Raleigh, I returned to classes eagerly awaiting the final decision. Red Hat was my choice during the flood of opportunities that came with that hiring season.
Motivation for Scientists
This week I want to write some content for those pursuing or planning to pursue a scientific field. Understanding the purpose of science may serve as some motivation to get over initial hurdles that are often found in STEM-related fields.
There exists quite a debate on the discovery of science. Some people argue that science started during the Renaissance when the scientific method was developed. The scientific method gave became the baseline of building findings within the field since it provided a way of verifying findings. The consensus seems to be that science came from the ancient Greeks, great thinkers of the time: Hippocrates and Aristotle, about 460 - 322 BC. Greek philosophers asked essential questions related to how things worked, questions of how we came to be, or how the land could float on water. These thinkers sought non-supernatural explanations for natural phenomena.
Medicine became a field that was studied by Hippocrates and his followers, who were set on describing the human body, diseases, and medical conditions. In Egypt, Euclid laid foundations in mathematical foundations, introducing the concept of definitions, axioms, theorems, and proofs. Linguistics gave way to generative grammar. Astronomy let us understand the world around us. Science all around the globe became anything from a religion to a way of thinking to an everyday tool to be used by people. It may also be how to earn a living. I think no matter what we do or how we think of science, it does not change its goal of understanding the natural world around us.
Scientists seek information to expand our knowledge and help us live better lives. I think that is a great thing to be able to contribute to the understanding of the world (it can be through products, papers, research, etc.), and although it may be difficult or tiring: knowledge sought is knowledge gained.
More Like This
Package Managers, Compilers, And More?
Ever had an inkling to try something new? I think many people have wished they were a bit more tech-savvy. Especially when technical jargon gets thrown across think tank spaces, industry, and even the news now.
No matter your tech-inspired goals, I think a good start to navigating and understanding how to develop software can from understanding the frameworks and utilities available out there. So today I'll be talking about package managers and host of other topics to get a little more in tune to the tech space.
You may be wondering what package managers are and how they apply to get more stuff done and developing. If you are ready for a small aside, please humor me through this.
Imagine that you are writing code for an airplane or a mobile phone. You are not going to code all of this from scratch. The nice thing about coding is that language has its standard libraries for reading into data, opening files, etc. These libraries consist of methods or functions that, given a little bit of information, can carry out a process. Imagine having to write the same code over and over again. It'd be hard to read. That's we like to organize our code and modularize it into methods.
Furthermore, it would be challenging to create products if you had to learn programming without the use of any standard library methods. It'd require understanding much computer architecture before even getting to see anything similar to an airplane or mobile app software. And imagine mapping bits and bytes to actual processes on the hardware... ick. No, often, we code software that takes our syntax or coding language and turns it into ones and zeros for our hardware to execute. Note that anytime one language gets translated into another, it's called compiling. Compilers do the work of compiling, and often they are savvy enough to provide additional optimizations and features to our code.
Package managers allow you to download libraries and utilities onto your computer without having to go onto the host site to download a zip file, unpack it on your computer, install in the right place, make sure your computer knows where it is... and then repeat this process every time there's an update to that utility!! If you noticed the meme above, you only have to download and install the package manager for your computer's operating system once, and then you can use that package manager to install any other utility you need. If you are in the tech space you'll often hear things like apt-get install .... or yum install ...
These are the commands you would type into your terminal or computer to execute the package manager and to tell it you want to install a particular library or utility. You can check out a list of package managers here. You'll notice they're operating system dependent.
Last week I saved a ton of time when I installed a cross-compiler to take my C code and compile it into an executable binary code file that my raspberry pi could run. It's called a cross-compiler because it makes the code I developed on my machine (which has an Intel CPU) and compiles it into code an ARM CPU (processor) can read and run. CPUs or central processing units are the brains of a computer. Different CPUs from different companies often don't play very friendly together since the hardware is created differently, so a command of ones and zeros can mean something completely different or gibberish on one machine and be everything nice and understanding to another.
I think that often there will be this talk up for how difficult getting started is because you need a virtual machine (VM) or a certain operating system (OS). A lot of times we can get around this by simply installing some software utility that we can run from our current system.
Comment below what you would like to read about next! And let me know, what you think? Was this helpful?
More Tech Posts
Understanding Bits and Bytes
One of the first concepts covered in computer science class is the bit. We've come to know that it represents either a one or a zero, but what does this really mean? How do our computers process these ones and zeros to give us the functionalities we have today?
No worries, that's what part 1 of this post will help with!
Alright-- So we know that bits work like switches: on or off. The on state is represented by a one, in real life, this corresponds to the presence of some voltage beyond a certain threshold. The off is, similarly, represented by a zero.
Ok great this means we can represent two states with one bit. That's great if we spoke in binary or only used two letters to communicate with one another.
What if we add more bits together? Well, now we have quite a few combinations of ones and zeros. If you start to draw out the possible combinations you'll notice that we can have many states: 2^(number of bits) to be exact.
A byte is a group of bits. Of course, you can also say you have a 4-bit number or an 8-bit number and so on. (For terminologies sake, in case you were curious).
Anyway, with so many bits, we can represent the alphabet and make sentences or strings as its commonly called in the field. The goes the other way as well: imagine writing some code or a program, our text gets manipulated and processed into groups of bits for parts of the CPU (the brain of the computer) to execute the various logic commands.
That's the basics of bits and bytes for now. Leave me a comment, was this helpful? What would you like to learn about next?