DEV Community: Caitlyn Greffly

Non-Technical Frontend Interview Questions

Caitlyn Greffly — Fri, 19 Feb 2021 04:42:30 +0000

I don't know about you, but every time I get to the final round of interviews at a company I get pretty nervous. It feels like I could get asked any question under the sun, and how do you prepare for something like that?! I've often compared studying for the final round of interviews to studying for a history test where you don't know the time period or region of the world.

While I tend to focus on worrying about the technical questions, in my experience that only comprises about 30% of the questions (this guesstimated statistic may be in part due to me being relatively early on in my career). As I recently went through a couple of rounds of interviews, I thought I would share some of the non-technical questions I was asked.

Note: I've shared some of the ways I've answered these questions, but they may not be the best possible answers. Just wanted to share what I can!

Product Questions

Tell me about how you view your relationship with the Product Team.

I love this question because I love working with Product. I love discussing the user needs and what the market is looking for. Chances are this question is going to be asked to you by a member of the Product Team, so focus on some of your positive experiences and leave the comments about how they always make you do work you don't want to do for your diary.

Tell me about some of your favorite apps.

This was a question that I found out after the fact is very common. At the time I kind of panicked. What do I tell them - Twitter?? That dumb game I always play? Why can't I remember any of my apps?? The answer I ended up giving was the Clarity money app because I did think it was a pretty cool app, but unfortunately it wasn't one of the apps I used the most. In hindsight, I wish I would have picked an app I was more familiar with so I could have had better answers for the follow-up questions.

What would you change {on the app you just named} to drive user engagement?

Answers to this question could get pretty complex and interesting depending on the app you've selected and your interest/understanding in product decisions. A couple of ideas that would fit many apps would include adding badges, notifications (be prepared for a follow-up question on how often), adding a gamification feature, or giving some sort of positive feedback for each use.

What would you change to improve user experience?

Put some thought in ahead of time to what doesn't seem intuitive or smooth about the functionality of the app. If it's a beautiful app that runs perfectly, you can dissect why it runs so great and how they achieved that.

Agile Questions

Have you worked in an Agile environment? If so, what kind?

If you have worked in one, be prepared to discuss which kind (Scrum, Kanban, etc.) and what that looked like for your team. Did you do full ceremonies (standup, sprint planning, retros, etc.), or was your team leaner on meetings? If you haven't worked in an agile environment, this article goes through the history of Agile and an overview of the various frameworks.

What do you like and dislike about the Agile workflow?

For me, I love the structure of Scrum. I love having a sprint to get my work done and I love the feeling of a fresh start with each new sprint. I like that we aren't stuck to what was originally outlined and there is room to adjust as we need to. It's also fun to ship work every sprint (in theory) and get the rush of endorphins you feel when you see your code in production!

Ideally, how many meetings per week would you like to have?

Tricky question... what if you say none and they have 10? I've given a kind of circular answer to this one in the past. I enjoy meetings because, as a more junior engineer, I feel like I learn a lot from my teammates in meetings. However, if there are too many it becomes hard to focus on my actual work, so I prefer to have my meetings grouped and have longer stretches of heads down time.

Soft Skills Questions

Tell me about a time where you disagreed with a coworker. How did you resolve it?

This is such a classic question, I've probably been asked it in almost every job interview I've ever had, regardless of industry. In a recent interview, I talked about the push and pull between being a perfectionist and just getting something shipped. It's a disagreement I've seen happen often in development, and I know I tend to lean slightly towards getting code out the door. Not that I don't want the code to be awesome, and I definitely don't want to create tech debt, but I don't want to get so in the weeds on a perfect solution that we turn a 5 point ticket into a 21 point ticket. Your answer also might depend on if a product person is asking you or a fellow developer.

Tell me about a miscommunication you've had with a coworker.

I struggled to answer this question because I couldn't (and still can't) think of a great example. Of all of the struggles I've had as a developer, I don't think miscommunication has been a common one. When asked this question, I redirected to a story about disagreeing with a coworker and finding a way to compromise. Maybe you can think of a better answer.

Tell me about a time you didn't get a ticket across the line in time. Why did this happen and how did you deal with it?

I've been asked this question a few times, and honestly, I'd also be interested to hear how an organization deals with developers not getting their tickets across the line (maybe a good follow-up question to ask as the interviewee?). Fortunately, I've only worked on teams where, as long as they know you are putting in the work, there's no shame in a ticket slipping. It's always been more of a personal pride thing for me to push my tickets to prod in time.

What's your learning style?

Great question! I love to be asked this question because it shows that the team has a learning and growth mindset (which I think all dev teams should). Personally, I learn by reading, doing, and then sharing what I've learned with others.

How do you keep up with ever-changing technology?

Twitter? Haha... no but seriously. I have told many folks that Twitter is one way that I keep track of what is going on in the wide world of tech. I follow a lot of folks who create amazing content that I learn from, and whenever I ask for help I'm flooded with amazing resources. I also throw out some of my favorite podcasts (shout out to Ladybug, Front End Happy Hour and Syntax).

Good luck out there on your interviews! Don't forget to ask for more money :)

Throwback TV Show Zoom Backdrops That Are Guaranteed To Improve Your Workday

Caitlyn Greffly — Fri, 24 Apr 2020 03:38:02 +0000

So we've been working from home for a while, and if you're anything like me, you are bored of the wall behind you. Totally scientific and completely fictional studies show that adding a fun zoom background can improve your mood by up to 95% during your workday! So I've compiled a list of some of my favorites based on tv shows. I obviously have some extra time on my hands here, but I am sure this beer-fueled activity will bring great value to many.

Central Perk

Of course this list starts with Friends. And honestly, no one did tell me that life was going to be this way...

Luke's Diner

One of my favorite spots to virtually hang out, especially because it suits my desperate need for coffee. Just remember, no cell phone's allowed.

Dr. Crane's Apartment

This is an especially good background for those rainy days when you wish you were in Seattle sipping fine wine and listening to the smooth radio sounds of Dr. Frasier Crane.

The Creek

Have your colleagues been a little melodramatic and you need a backdrop to fit? Visit your old friend Dawson and have a good cry on the pier.

The Forman Basement

If you want to give your meetings a little edge and keep your coworkers guessing as to where you actually live, might I suggest this smoke-filled scene from That 70s Show.

The Chef's RV

Another great work-friendly backdrop to keep your colleagues guessing about your latest side hustle (if they can't place the iconic Breaking Bad RV).

Office Interview

The perfect backdrop for those honest conversations you'll have while looking straight into the (zoom) camera.

High Tea at The Abbey

The dowager requests your presence at Downton, formal wear not required. Now where is the footman with my tea?

Jerry's Apartment

Passable as your own apartment, minus the chunky computer in the background. Too bad Kramer won't burst in during your call to entertain your coworkers.

Pawnee Parks & Rec Department

Have an important meeting and need to channel the confidence and energy of Leslie Knope? Don't stress, afterward you'll get waffles.

Norm!

Where everybody knows your name, and no one judges you for having a beer at any hour of the day.

The Banana Stand

There's allllllways money in the banana stand.

There are literally hundreds more. So many zoom backgrounds you could have a new one for each day and never get bored. Your colleagues may get bored, but you won't.

Coming soon: Harry Potter themed Zoom backgrounds.

Being a Junior Dev in the Time of COVID

Caitlyn Greffly — Thu, 02 Apr 2020 14:57:51 +0000

There is a lot going on in the world right now. I often find myself oscillating between being anxious about the wellbeing of myself and those I love, being grateful for my situation, and being nervous about my career growth and goals. It may seem like small beans to be thinking about career growth, but it's been hard for me to work through feelings of how that is inevitably shifting.

It's an interesting time to be a junior dev. I'm only six months into my first tech job and I have been very bright-eyed and bushy-tailed when it came to my career path. I was gunning to go from Associate Software Engineer to Software Engineer in the next six months and regularly consulted my list of things I needed to accomplish to make that jump. Now, I find myself sitting in my boyfriend's music room turned into my office space trying to focus amidst a global pandemic. The first week of working from home I even switched my backend database ticket with a coworker for their friendly front-end API calls. I feel less likely to grab a complex backend issue because what would have felt difficult in the office now feels near impossible. That notion both makes me feel like I am not pushing myself hard enough, feels reasonable considering the circumstances, and makes me worry that I won't continue to learn at the same rate I have been. Compounding that, I also feel acutely aware that if layoffs were to hit our company, I'd likely be the first to go.

I have definitely been feeling the lack of physically present coworkers. Slacking (instead of speaking) all my thoughts and questions made me realize how many thoughts and questions I had, and it was hard not to try and pull back from that a little. I also often found I didn't really have a question, I just wanted to talk through my issue with someone beyond my dog. I would stare at the slack channel trying to guess based on recent chatter who might be swamped and who might have some downtime, which is significantly harder than spinning around in your desk chair. Beyond having people there to help out, I realized (especially as an extrovert) how much energy I get from the people around me. My challenging tasks felt like they drained me more quickly.

Up until this recent shift, I have been so full of energy and plans. Suddenly all of that seemed to hit a brick wall. I was so excited to attend my first real big tech conference and then that got moved online (still great for learning, but definitely not the same). I was looking at CFPs and starting to put applications in but many of those got pushed or canceled, and it feels harder to keep myself motivated to apply for events that may not happen. I had started a shadow program, but that was obviously put on hold for a while due to the current circumstances. I worry that this change of pace will kill my momentum, that when all of this lifts in a few months I won't be able to come back with the same energy and excitement that I had before.

All of this might just sound like a lot of complaining. First world problems, am I right? And often I go back to a place of gratitude for still having a job, and for having the people I love in good health. But at the same time, I acutely feel the challenges of being a junior dev in the time of COVID, and I thought that if I feel it, others probably do as well.

So what is a junior dev to do? I don't have a great answer for that yet. Some of my goals include being as talkative as ever in slack form, and if people want me to bugger off they can tell me to do so. I know I need to exercise more because that might give me back some of that usual energy I had. I need to be compassionate with myself, knowing that although my growth may in fact slow I am still growing. And I need to be honest with others about how I am feeling and where I am at, even when that's hard or scary. Hence this post.

Until then, there are always fun Zoom backgrounds to keep me happy!

How to Support the Junior Dev on Your Team

Caitlyn Greffly — Wed, 11 Dec 2019 01:27:39 +0000

With fresh new devs popping out of CS programs, bootcamps, and self-taught paths every day, chances are you are going to end up working with one. Maybe you're dreading it because you fear lots of hand-holding in your future, or maybe you're stoked because you get a chance to pass on your well-earned wisdom. Either way, there they are, and it's in everyone's best interest that they succeed.

I have been lucky to be extremely well supported at my first dev job, but I know that's not always the case. If you're looking for some ideas for how best to do the same for your new junior, you're in the right place.

Know It's Not Easy

No matter what kind of education they are coming from, they are walking into a completely new environment with more real consequences for the code they write. They are likely feeling overwhelmed, confused by the codebase, intimidated by the expertise around them, and pressured to succeed. There's a lot going on and this transition is not easy, so try to treat them with compassion.

Check on Them

They probably have questions. Likely hundreds. They might be afraid to ask them, or to ask too many and take up your time. They will greatly appreciate you taking the time to ask how they are doing and if they have anything you could help them understand.

Host Office Hours

You're very busy and important, so it might slip your mind to go and check in on the juniors. So get them to come to you by putting office hours up on your calendar! This is a great practice especially if you are a senior dev or have a title like DevOps, SRE, Product, or something similar that I for one was completely confused by at first. You will probably get non-junior visitors as well and you'll see how valuable your time can be to your coworkers.

Learn Together

Whether you've been a developer for 2 months or 20 years, one of the great things about this field is there is always something new to learn. If you know there's something you'd like to learn, a Udemy course you'd like to take, or just a topic you need to brush up on, invite them to join you. Being new can often feel like everyone knows everything and you know nothing, so seeing that more senior developers are learning too is a huge relief.

Ask Questions

This is something junior developer hear ALL THE TIME. If you don't know, ask. We will continue to do so, but sometimes it can be intimidating to be the only one asking questions. If you are a more senior dev, asking a question in a meeting not only gives you the answer (hopefully), but builds a welcoming environment for everyone to feel comfortable doing the same.

Be Supportive of Their Efforts

They might write some code that you see and think to yourself "My goodness what hot garbage is this?!", but know that they likely spent hours or days struggling to find a way to make it work, and they're proud of that feat. You will of course have time to (see below) give feedback to help them improve the work, but show them that you see how much effort they put in. Personally, I know some of the easy tickets that take me 3 days to complete could likely be done in an afternoon by a senior dev, but I appreciate that the team makes me feel that I add value. It makes me want to work harder to contribute more next time.

Give Constructive Feedback

Of course it's important to be supportive, but that should go hand in hand with helping them improve. With every code review, you have a great opportunity to give constructive feedback. This will not only help their code be better next time, but you lay groundwork for the standards and expectations that are specific to the company. Feedback is necessary for their growth, just try to make sure it doesn't come from a place of frustration, impatience, or superiority.

Pair

There are going to be tasks that are way over your junior's head to the point where they might not even know where to start. Instead of letting them attempt and fail and get stuck and frustrated and doubt themselves, this can be a great opportunity to pair and let them watch your thought process. You can even put them in a position to drive while you point them in the right direction, which depending on their learning style may help them understand even better. Ask what they're comfortable with.

Have a Book Club

Personal experience - this was one of my favorite things that I was invited to do in my first few weeks as a junior dev. Someone suggested a few of us, ranging in experience, read Clean Code together and meet every week for coffee to chat over the most recent chapter. Not only was it a great way to discuss best practices for our code, but it gave me some allies at the company right off the bat. It's also nice to walk away from staring at your screen for a bit sometimes.

Be Patient

We know we might have learned how to do this in school, or you might have told us once before where the answer was but there is A LOT sloshing around in our brains right now. I have it on good authority that even more senior devs have to google the same thing multiple times, so try to be patient with us as we learn what you may consider to be the basics. Remember, you were a junior once too.

Translating Bootcamp to Real Dev Job

Caitlyn Greffly — Tue, 26 Nov 2019 18:14:40 +0000

If you decide to go the coding bootcamp route, chances are you are going to have a few months of absolute madness. You are trying to change careers and pick up a mass of technical knowledge in a condensed amount of time. It's a lot.

As I was going through this process, I didn't really know if my life as a developer would look a lot like my life as a code school kid or not. As I transitioned into my first dev job, I encountered some surprises and realized I had had some misconceptions. Some things were the same, like getting stuck on a bug you never think you'll solve and then somehow figuring it out, but most of my day to day life is much different now.

Codebase

Bootcamp: You get to start every project from scratch on a beautiful blank slate. You copy the up to date examples from the coursework and it looks great.

Real Dev Job: There are tens of thousands of lines of code already written by 200 different people over 8 years in 3 different frameworks. You try to use the existing code as an example to build your own code, but your PR gets sent back because that code was poorly written 3 years ago. Not only do you still have to learn to code, but you have to learn to do it better than the devs that came before you.

Volume of Code

Bootcamp: You often write 200 lines of code in a day. You can get the wireframe for a new app up and running in 2 days.

Real Dev Job: Read 200 lines of code. Write one line of code. Research. Read 50 lines of code. Write one line of code. Break something. Delete one line of code. Google for an hour. Write five lines of code. Submit a PR but get suggestions for changes. Repeat the process.

Code Quality

Bootcamp: If you make it work, you're stoked. Often you won't have time (or energy) to refactor it, you'll have to move on to making the next thing work.

Real Dev Job: Of course you have to make it work. But then you also have to make it readable. Make it consistent with the current code. Make updates if the current code is old. Make sure you didn’t add any code that doesn’t actually do anything. Make sure your variables are named well. Make sure you don't override the parent CSS file. Make the changes your colleagues suggest. Make the changes your QA manager suggests. Don't forget to get UX approval!

Meetings

Bootcamp: Coding is 90% of what you do with your time.

Real Dev Job: There will be stand up. And design meetings. And team meetings. And company-wide meetings. And code review. And sprint planning. And sprint review. At many companies, you will find yourself adding value outside of the code that you write, which is awesome. Meetings can also be a great way to soak up the knowledge of your more experienced colleagues. But that also means that some days you won’t write a single line of code.

Timeline

Bootcamp: You just learned React last week so this week you will write an entire React app in 2 days.

Real Dev Job: Because your time is not only made for writing code, but all the other things I've mentioned, the pace is a bit slower. This sprint you might only have one or two tickets to work on. They might be seemingly simple, like adding an error message for when a user tries to do something stupid. But when you're new, nothing is as easy and straight forward as it seems. Hopefully you are on a team that understands and supports that pace.

Money

Bootcamp: Maybe you are a badass continuing to work while you put yourself through bootcamp, but if you're like me and thought that seemed impossible, you might have been feeling the financial strain. Buying an almond milk latte suddenly seems like a treat yoself moment for the elite.

Real Dev Job: cue Nsync song Just Got Paid You worked your buns off, and now you get to keep doing so BUT with a paycheck on the other side. Good for you! Go buy yourself an extravagant beverage. You earned it!

Balancing Confidence and Imposter Syndrome

Caitlyn Greffly — Sat, 16 Nov 2019 23:03:37 +0000

I am a month into my career as a developer, which is pretty much as new as you can get. I was reminded of this when I received a very direct comment on my last post: "The term "imposter syndrome" doesn't really apply if you are actually an imposter."

While on one hand, I wanted to dismiss this as just another internet troll out to make me question my worth, I realized that I did slightly feel the need to defend my opinions based on my newness to the field. Part of me wanted to be proud and confident, and the other part wanted to hide so that no one would see me for the imposter I was. Either way, I knew that someone would be there to try and talk me out of how I felt.

So how do you balance being new and knowing you have a ton to learn with the confidence that will help you succeed? I'm not sure, but I'm gonna work through my thoughts right here.

Humble Beginnings

Being new to the developer world is humbling. You walk into your office on day one and see the massive amount of knowledge, technical ability and years of experience you are suddenly surrounded by. That feeling was awe-inspiring for me. I felt proud to have landed the job, but also keenly aware that I was likely the least knowledgable person in the engineering department. Instead of letting this make me feel like an imposter, like I didn't belong, I felt humbled to have been invited to learn from all of these people. It's actually kind of a great spot to be in, where you can only learn more and move up the ranks as you grow. I won't be the least knowledgeable person forever!

Confidence vs Competence

“Perhaps most striking of all, we found that success correlates more closely with confidence than it does with competence.”
― Katty Kay, The Confidence Code: The Science and Art of Self-Assurance

I read a fantastic book last year on how confidence plays into personal success, and was not surprised, although a little bummed, to hear their findings on confidence playing a larger role in success than competence (guess which gender generally shows higher confidence - a topic for another day). I've kept this idea in the back of my head ever since, knowing that just focusing on mastering a skill won't necessarily be enough to reach my goals in life. It's played into my current job when I push even the smallest bit of code into production, I confidently celebrate the win and fight my instincts to tell everybody the details of how it took way longer than I expected or that I basically copy and pasted to get it to work. Projecting confidence makes me feel stronger about taking on my next task, and ultimately makes me feel more competent.

Asking Questions

It seems obvious to ask questions when you don't know what someone is talking about, but that action can come with a lot of feelings. I have sometimes felt like I might be exposing myself for the imposter that I am if I admit to not knowing something that should be obvious or fundamental. But when I have spoken up, I have never been met with any kind of negativity, and have even been applauded on my questions a few times. Once I asked what DLQ was (a dead letter queue as it turns out) and someone else in the room breathed a huge sigh of relief that I had asked because they had been wondering the same thing for a while. For me, there are a couple of stages to contributing in certain meetings that right now feel over my head:

Observe and absorb, taking in as much information as possible
Ask questions about what you don't understand
Actually being able to contribute to the conversation

The the moment, I am focusing on stages one and two. I don't have enough knowledge or experience to be able to add my opinions to an architectural design meeting, but I also know I am not going to get any closer if I don't ask about the bits and pieces that don't yet make sense.

Speaking Up

Right now it seems unlikely that I could come to a meeting and point out something that no one else has seen. Everybody is far more experienced and versed with our code, how could my few weeks of work find something they didn't? This, like asking questions, can sometimes feel like a super fast way to expose the fact that you're an imposter to the world. Recently I spoke up about a part of a ticket I disagreed with, and although it was quickly decided I should complete the ticket as written, a senior engineer later approached me to thank me for speaking up and to say I made a good point. Although I might be overruled, I want to start creating good habits. I want to be the kind of person that feels confident enough to speak up when I see something that could use improving, and that confidence will ultimately lead me to be a more valuable member of my team.

Take Chances

"Don't pretend to be anything or anyone - simply take action. Do one small brave thing, and then next one will be easier, and soon confidence will flow. We know - fake it till you make it sounds catchier - but this actually works.”
-Katty Kay, The Confidence Code (again)

I love this quote, because it gives an actual path to building confidence. It can sound great in theory to get over imposter syndrome and be more confident, but how does one actually do that. The first time I submitted a PR it was pretty scary, but the next time was easier. The first time I took on a 2 point ticket, it felt scary (and took WAY longer than it seems like it should have), but next time I will know it can be done. But, I still don't feel like I have taken any huge chances yet. I have only taken on front-end tickets that have issues that seem remotely in the realm of resolution to me. Heading into month two, it's time to start scaring myself a little. Scary C# back-end tickets here I come!

To me, imposter syndrome feels similar to fear of failure. Building confidence is a great way to fight that fear. Every time I take on a task that feels scary or seems like I can fail, when I succeed I am proving a little part of my imposter syndrome wrong while building my confidence to take on a larger task next time. If all else fails, just remember you're in good company - FreeCodeCamp quoted a study that says up to 70% of people have felt imposter syndrome at some point in their career. It's not just you trying to find this balance.

Why Not Having a CS Degree is Awesome

Caitlyn Greffly — Tue, 05 Nov 2019 23:03:38 +0000

I didn't know what I wanted to do for a career when I was 18, and I feel okay about that. I also shouldn't have been trusted to pick a romantic life partner at that age (sorry Steve from the pirate-themed frat party). It's wild to see so many job postings ask for a specific kind of degree. Your employer is saying that one of the requirements for the job is for you to have always wanted to do this kind of work, since you were a freshman in college and decided on your major while nursing a hangover and clutching a jar of Nutella (or was that just me?).

I got my degree in Psychology. I loved studying Psychology, and at the time it seemed like something I could do for the rest of my life. Spoiler alert: I never got a job related to my major (unless you count bartending, which I kinda do). Instead, I ended up in the beer industry and then again, at age 31, realized that wasn't a path I wanted to continue down.

At 31, knowing I wanted to buy a house and have a couple kids in the next few years, the idea of going back to get a second degree scared me. That might cost me 40k, take 2 years, or 3 if you tack on another year just to apply and be accepted somewhere. And then would I have to move if I didn't get accepted in my current city?? It felt like this option was not aligned with my life goals at all, and was quickly crossed off my list.

Enter bootcamps. A solution for employers who are having trouble hiring as many engineers as they need, and a solution for people who want a more efficient way to change careers. Win win. With a bootcamp, you get the technical skills and hands-on coding experience that you'll use on the job. You may not have all of the theoretical knowledge or know the history of binary, but I'll bet you can find a job that doesn't require you to know those.

Without a CS degree, you might not be able to explain Big O notation, but you might have great interpersonal skills. Maybe you came from being an architect and you'll be great at drawing up the flowcharts for how the front-end of the app communicates with the database. Maybe you used to be a pre-school teacher, and you'll be the go-to person for communicating the engineering team's needs to the marketing team in a way that makes sense to them. No matter what field you came from, you'll have a unique skill set you can offer your future employer.

As an employer, you know the strongest teams are the most diverse teams. If you had 100 engineers and every one of them had a CS degree and had been an engineer since the day they left college, I would argue you don't have a very strong team. No matter what kind of app or project you are working on, you are going to want diversified points of view to make sure you see all the perspectives and catch any weaknesses. You may need engineers to dive deep into the code and spend the majority of their time behind the screen, but you'll also need some who will work with the design team, and how cool would it be if you had an engineer that came from being a graphic designer?! Sounds like that person (without a CS degree) might be the ideal candidate.

If you get your education through a bootcamp, you are also going to be learning the most recent, most popular languages and frameworks. If your employer wants to transition to React, likely all of their CS employees are going to go learn React anyway, so why would they care if you also just learned React? You might be a great resource for them in that situation, and be able to point your colleagues towards relevant tutorials and documentation.

As a new developer, it can be easy to let your imposter syndrome get the best of you because you feel inferior to those with a more traditional degree. You may see job postings that say they'd prefer a candidate with a CS degree, and not even apply for those jobs. But instead, how about you march up to that employer and tell them all the awesome skills that you bring to the table because you have a different background. Don't feel bad that you majored in Basket Weaving or joined the workforce straight out of high school. 18-year-old you did what made sense at the time, and current you is older and wiser and killin' it.

Networking for Newbies

Caitlyn Greffly — Wed, 30 Oct 2019 02:35:10 +0000

When I decided to change careers into tech, I knew exactly one person in the industry. As an extrovert who gets a lot of their energy from interacting with others, this made me nervous. I needed to make friends and I needed to do it fast.

Networking does not always come naturally to everyone, and even as an extrovert with a background in sales, I felt uncomfortable at certain points. But I put myself out there and in 7 months I've met some pretty great people, learned a lot, and landed a job. So I thought I'd compile a list of some of my best tips for how to build a community when you're starting from scratch.

Start a Tech Twitter Account

I did this on the first day of my bootcamp because it seemed like the least intimidating and low effort way to go. I quickly learned that by hashtagging #100DaysOfCode, #WomenWhoCode and #CodeNewbie, I could connect with people going through a similar journey. By simply writing about what I was learning and what my interests were, I was able to make connections and start to build a community, making me feel less alone. I connected with people in my city and then began meeting those people IRL at meetups and conferences. This not only became a great networking tool, but a way to be up to date with the trends and lingo that made me feel like I could talk about tech in a more natural way.

Stalk People on LinkedIn

This is a classic cold call sales tool that came in handy when I wanted to get a foot in the door at target companies. Here's what ya do:

Go to the LinkedIn page of the company you'd like to work at (doesn't matter if they're currently hiring or not).
Click on "See all employees on LinkedIn".
Filter based on location.
Filter down to your first or second connections to see if you have any, if not that's fine.
Start reading profiles and looking for commonalities.

From there, I went the route of looking for people who shared a similar background as me, specifically coming from a bootcamp. I looked for people who were in the first few years of their career because I (rightly or not) assumed they might not have as many time constraints, and honestly I'd be less intimidated by meeting with them. Once you've found your target person, send them a nice intro message that is personalized, points out what you have in common, and lets them know that you are looking to learn from them (not just ask for a job). And then you can ask them to coffee!

Ask People to Meet for Coffee

Once you've found someone you'd like to chat more with, whether it's through LinkedIn, Twitter or at a Meetup, the next step is getting them to sit down with you so you can really pick their brain. This can be scary because you could get rejected, or what if they say yes and then you have to figure out what to say?! Chances are, this person is going to know exactly what you are going through and how you feel (if you've picked someone with a similar background), and meeting up with them will help assuage these fears.
If you already have a job, but just want to make more connections without the pressure of being in a room full of 100+ people, this is a great way to go. If you're still on the job hunt, this person could give you a glimpse into your future life in which you've successfully made the career switch, and maybe even help you make that career switch. Let them know that you're on the lookout for a great opportunity and that admire their company. As you're saying goodbye, don't be afraid to ask for who you should send a resume to in case anything ever opens up. Then make sure to send a thank you note afterward.

Ask to Shadow

This was one of the best and most surprising things I did while I was in bootcamp. I sent a tweet out asking if I might be able to shadow anyone, and I ended up with 6 opportunities to meet with people in 6 different companies.

Not only did this give me an in at each of these companies, but it was a great way to learn which direction I wanted to take my career in. I realized I was much more excited by my days shadowing those focusing on front end, and got intimidated by places that felt too quiet and spent 90% of their time in heads down. I also met some really great people with inspiring stories and careers!

Go to Conferences

Conferences can be a great learning experience, not to mention the networking opportunities. Some conferences are more geared towards newbies and include talks on accelerating your career, sometimes even having mentors available to give individual resume and portfolio advice. Even if a conference seems more advanced, there will be booths sponsored by companies where you can ask directly about job opportunities. Plus, free food!

Conference tickets can be expensive. One way to get in for free is to volunteer. You'll usually have to work a shift or two, but then you'll get to spend the rest of your time hopping between talks and networking. Women Who Code and Diversify Tech list some ticket giveaways and sponsorships as well.

Join all the Slack Channels

Slack channels are a great way to make personal connections with people you don't know at all. Many of the community tech slack channels you can join will also have specific job boards, where you can set an alert every time someone posts. When you see a job posting you're interested in, reach out via direct slack message to the person who posted it to introduce yourself and ask a thoughtful question about the position or application process. This can help your resume rise to the top, and give you more insight into what the company is looking for. In Portland, the slack channels I kept a close eye on were PDX Women in Tech, Women Who Code Portland, and PDX Startups. Ask around to see which channels you should watch in your area.

These are some of the techniques I used to build a community, but it by no means is a complete list. If you have some other tips and tricks that have worked for you, leave them below in the comments!

The Cost of a Coding Bootcamp

Caitlyn Greffly — Tue, 22 Oct 2019 18:55:33 +0000

When I was researching coding bootcamps, one of the scariest parts was the cost. 10k, 20k, even 30k, how could I possibly afford that? Not to mention if it was a full-time on-campus program, I wouldn't be able to keep my job. But on the other hand, how do you put a price on leaving a job that makes you unhappy to find a more satisfying career?

My solution was to make spreadsheets. I put in the cost of each program, the salary the program suggested I could make on the other side, how much I had in savings, and how much income I could expect to make while learning. I decided what kind of debt I was comfortable with (for me, very little), and ultimately decided on a lower-cost flexible and remote program. But in hindsight (even though I was happy with my program), I realize that a six-month full career change is worth more than I originally imagined.

Let's talk projected income for a minute.

Glassdoor lists the average national income for the following job titles as follows:

• Technical Support Engineer: 63k
• Junior Developer: 66k
• Entry Level Web Developer: 71k
• Full Stack Developer: 80k
• Associate Software Engineer: 83k

I followed up this data with a couple Twitter polls. The responses are international and have some of the usual downfalls of a basic Twitter poll, but I wanted to include them nonetheless.

Poll: What was your salary for your first full-time job as a developer?

As you can see, there is a pretty big discrepancy between this poll and the Glassdoor results. However, a lot of people in this survey answered that their first job was in the 90s, or in the UK where salaries are lower.

Poll: What should a junior developer expect to make for their first full-time job in 2019?

This poll feels more in line with my experience in Portland, Oregon. Of the very small sample size of 4 post-bootcamp devs who shared their starting salary with me, we all fell roughly in the 50-70k range.

Resources

There were a couple of helpful links left in those Twitter poll threads, so you can do more research based on your specifics:
Stack Overflow Salary Estimator
Payscale Salary Survey

Glassdoor also suggests that within 4-6 years as a software engineer, you should be expecting to make around 100k. Just something fun to keep in mind, in case you want to buy a boat someday or something.

Doing the math.

I spent 14% of my starting annual salary on my bootcamp. That feels like a really small number to me if you think about it. Especially considering what I spent on a bachelor's degree, plus 7 years of work experience that got me to roughly the same income I have now. 6 months plus paying 14% of an annual salary vs 11 years plus 120% of an annual salary. That's a pretty quick return on investment.

Benefits count too.

Tech companies (in the US, can't speak for elsewhere) that have gotten past their start-up phase can have pretty solid benefits. They want to attract top talent, and know that people care about benefits ranging from healthcare and 401k to free lunches and PTO. Don't be afraid to ask about those things in a job interview, because the cost of those benefits will add up to increase your salary. Right now, I have the benefit of getting medical and dental covered at 100%. I might as well add another 5k onto my salary.

The priceless stuff.

I was really unhappy at my last job. I had no work/life balance, I felt underappreciated and overworked, and that unhappiness trickled out into the rest of my life. I took a bit of a pay cut to change careers and it could not have been more worth it.

Also realize that many tech companies are allowing more and more employees to work remotely, either part-time or full-time. How much is that worth to you? How much would that save you on gas, parking, or childcare?

To sum up.

It's worth it (one woman's opinion). I could have spent twice as much on my bootcamp as I did and it still would have been worth it. Spending a lot of money can be scary, but if you really look at the cost/benefit analysis, it's a worthwhile investment.

My First Week In Tech

Caitlyn Greffly — Mon, 21 Oct 2019 01:44:36 +0000

Four months ago, I was sitting amongst my colleagues in the beer industry, bro-ing out over the hottest barrel-aged beer and discussing profit margins on our newest can package. This week, I found myself on the 7th floor of an office building, adjusting my new blue light glasses while sitting at my cubicle, and trying to answer the question "So you're the new engineer right?" with a straight face. I felt a bit like I was role-playing someone else's life.

But I wasn't. This was my new life and I had to take a moment to be in awe of the full and rapid transition of career paths. I had actually done it, gotten out of a career that no longer suited me and positioned myself in an industry that would (hopefully) be a better fit.

So as a COMPLETE newbie to not only tech but office life, I've decided to reflect on some experiences and observations from week one.

Onboarding was extensive.

There is so much to learn when joining a new company on the tech team. First, I had to learn what exactly it was that the company did. There were a lot of legal terms to learn (it's a legal software company), a lot of people in different departments to meet, and a lot of security training videos to watch. Onboarding pretty much took up the first 2.5 days of my week, which helped to ease my fears of being thrown straight into complex legacy code.

Setting up my computer system was quite the project.

It took a full day to get my computer up to snuff with the company standards. Even with what would have been an easy one-step install, there ended up being errors and new versions and a variety of different steps I had to take to get it all working. On top of this, I had to get logged into about 15 different applications and keep track of 15 new passwords.

There was not a lot of coding.

I didn't get the code pulled up on my machine until Wednesday afternoon, and didn't start working on my ticket until Thursday afternoon. For me, that was great because it gave me some time to get comfortable in my space and with the people around me. Then when I finally got into editing the code I was super excited to dive in, and not as nervous as I had felt Monday morning.

They went easy on me.

My first ticket was a CSS ticket WOOHOO! I just had to fix some buttons where the centering was funky, and it was the least intimidating ticket I could have gotten. That being said, it took me 4 tries to get my fix approved because I wasn't familiar with the whole site (I accidentally messed up the print button on another page I didn't even know existed) and I wasn't up on company standards. Luckily, each time my issue got kicked back to me, a friendly face also showed up at my desk to talk me through what went wrong.

There were a lot of meetings.

About three a day. Some were introductory meetings that won't be a part of my day to day going forward, but many were sprint meetings, design meetings, team meetings or company-wide meetings that will continue to be part of my workflow. I like this, and knew I was going into a company that managed their time this way, but it's a good thing to ask about in an interview if you're the kind of person that wants to have more heads-down time. I like to have plenty of opportunities to talk through issues and learn from my teammates, so I'm a happy camper in meetings.

Offices have perks.

Not that I would have picked a job just for the office perks, but man do I love the snack wall. And catered lunch Mondays. And being in an office with tons of natural light. And my sweet mechanical desk so I can switch between sitting and standing as I please. These things have a bigger impact on my day than I would have expected.

My coworkers were incredibly friendly.

People were constantly coming up and introducing themselves, checking in to see if I needed anything, and more than happy to answer any questions I had. It made it much easier to interject in a meeting to ask about an acronym being used because I knew they wanted me to learn. They all seemed to understand what it's like to be a junior dev in your first job, and wanted to help make it as accessible as possible. Plus, I think they're just good people.

The work/life balance was on point.

About 80% of the office takes off at 5pm, if not a little before. People stroll in sometime between 730-9am, and no one really keeps track of what time you get in. You're just expected to get your work done. If your car breaks down, your dog gets sick, or you've got a headache, just work from home. We get two hours a week set aside for "Personal Development", there are monthly game nights that start at 4pm, and there's a great culture around actually taking your vacation time. I lucked into some of this, but would definitely suggest asking about these built-in perks in an interview.

I feel very lucky to be looking forward to waking up tomorrow morning and getting back to work. This is why I put myself through the madness of a coding bootcamp. It's already completely worth it, and I haven't even gotten my first paycheck yet!

Why You Should Do #100DaysOfCode

Caitlyn Greffly — Mon, 07 Oct 2019 18:25:12 +0000

If you're on Twitter, you've probably seen the hashtag #100DaysOfCode floating around. I'm here to encourage you to participate.

When I first joined twitter in March 2019 (yes, I was that late to the game), I thought it was mainly used to stalk celebrities and fight about politics. I knew exactly zero people in tech and really had no idea where to start. I stumbled upon some tweets with #100DaysOfCode thrown in and saw that it was tech people, mostly code newbies, sharing their struggles and triumphs. In an attempt to connect with the tech community and not feel so alone in my journey, I decided to join in.

If you aren't familiar with this hashtag, here's how it works.

Write a tweet about something you're working on today that's code related.
Add the hashtag #100DaysOfCode at the end, along with which day you're on (Day 24 #100DaysOfCode).
Repeat (100 times, to be exact).

That's pretty much it.

There are some official rules about how to participate in this challenge and whether or not you're allowed to take days off, but I am here to tell you the official rules don't matter. I took breaks during my 100 days, some electively because I just needed a break, some mandated by being out of the country without a laptop. I left for Ecuador on Day 45, was gone for a week, and when I came back I picked back up at Day 46. Guess who noticed and called me out? Exactly no one. The point is to track your progress and connect with the community, so don't worry about the details.

So why am I trying to convince you to use a hashtag? If you are new to tech or Twitter (or both), hashtags will help people find you. You'll suddenly find yourself getting encouraging replies from strangers, or even tips on how to fix the bug you're working on.

Check out this tweet I posted simply asking for help because I was on the React struggle bus:

I had about 250 followers at the time, but this tweet, a tweet ASKING FOR HELP, got me over 500 people looking at my profile (where I had my portfolio site posted in my bio - hello job opportunities), and 47 people replying to help out! Not only did this make me feel way less alone in my struggles, but I came out of it with great resources and connections to up my React game.

I learned so much in my #100DaysOfCode from other people as well, finding new tools for debugging, great new VSCode plugins, and hearing about how others landed their first tech job. Without having used this hashtag (along with #CodeNewbie and #WomenWhoCode as two of my other favorites), I would not have found some Twitter friends that have become real friends, and I wouldn't have found half of the resources I use on a daily basis, both of which likely contributed to getting my first job. It's also just downright inspiring to see someone do some amazing project and end it with "Day 86 #100DaysOfCode" and think to yourself, will I be that awesome at Day 86?! And then BOOM you totally are.

So if you're going the self-taught route or participating in a bootcamp, try it out. Just don't go overboard and hashtag 20 other things along with it. #dontbethatperson

Coding Bootcamp Realities

Caitlyn Greffly — Wed, 02 Oct 2019 23:00:44 +0000

I recently spent 6.5 months in a coding bootcamp, which probably sounds like a shorter time period than it felt like. I definitely thought I knew what I was getting myself into (thought being the operative word). I did my research and knew I was driven enough to push myself, but there are some realities I wasn't totally prepared to face. So I'm sharing them with you, in case you decide to embark on the same journey.

It's more of a time commitment than you think.

Your program may have suggested you'll spend 20 hours per week on the curriculum. This may be true in the beginning when you're learning HTML and CSS basics, but after that just assume everything will take you twice as long to understand. When a new topic is introduced, you'll likely have to look to outside sources to really understand it. If you think you have one simple error to fix, it may take you multiple days to resolve it. The sooner you can make peace with that, the better.

They'll give you instructions on how to build a BBQ, and then the assignment will be to build a house.

Bootcamps want to teach you a valuable skill - how to problem solve on your own. That's great in theory, but you'll likely wildly underestimate the amount of trial and error, googling, and swearing at the computer that will happen between encountering a problem and solving it.

Say goodbye to hobbies.

So you like to read murder mysteries in your spare time? You're a rock climber? You hunt bigfoot on the weekends? Not anymore. Your hobbies are now coding, thinking about coding, dreaming about coding, tweeting about coding, and seeking out other people that want to talk to you about coding. Don't worry though, you'll get your hobbies back in 6 months.

Apologize to friends and family in advance.

You have taken on a monumental task, changing careers to a complex and challenging field written in a foreign language in just a few months. You are likely going to be a bit of a brain zombie, and cannot be held accountable for forgetting basic details. You also will have much less time for the people in your life, and may not be the great household contributor you used to be (just ask my boyfriend who cooked 90% of meals during my bootcamp). If, like me, you are short on time and money during this period, make sure the appreciation is in full force.

Learning to code is only part of the journey.

Remember that part when I said it's more of a time commitment than you think? That's true for learning the curriculum, but that's only one of the aspects of how you'll spend your time. You'll also be constantly updating and reworking your portfolio (arguably the most important thing you'll be creating during your bootcamp), writing an impressive resume despite zero job experience in the field, applying to jobs, writing cover letters for those jobs, studying for interviews, going to networking events, stalking companies and people from those companies on LinkedIn, convincing the people you stalk to go to coffee with you, and don't forget to leave time for questioning your recent life decisions.

You'll get a euphoric high when you resolve a bug.

You'll spend 2 days trying so hard just to get that damn button to do what you want, and when it works BOOM! You'll look around triumphantly for high fives from strangers and show your significant other what a cool button you've created (be prepared for false enthusiasm if they're not in tech). You'll suddenly feel like you're in the right place and everything is going to be fine. Remember these moments of joy, you'll need them when you're stuck again tomorrow.

You'll meet some great people.

People are nice, y'all. If you put yourself out there, you'll meet some great ones. If you get the courage to go to a networking event, you can meet friends in your area. If you post on twitter about learning a language, people will offer help and advice. Besides this being a great way to network, it also just helps to not feel so alone. You'll need people to share your successes and failures with, and having that community will make your journey so much more enjoyable!