« All Episodes

Reddit CS Career Questions

Published 7/18/2016

In today's episode, I'm answering a few random questions from Reddit's r/cscareerquestions subreddit.

Questions from Reddit:

Today's episode is sponsored by Rigor! Head over to http://spec.fm/rigor to get a kickoff call scheduled today.

Transcript (Generated by OpenAI Whisper)
Hey everyone, welcome to Developer Tea. My name is Jonathan Cutrell, and in today's episode, I'm answering random questions on Reddit. Today's episode is a little bit different from the average episode of Developer Tea, because I've decided to pick a few questions, sort of that random, from the Reddit, the sub-reddit, CS career questions, you guys know that I like to pick questions off of this list, because I think some really good ones come up there, and there's some really common questions that are popping up on the CS career questions. I like to do these because they are not super technical usually. A lot of them end up being more generalized discussions about, you know, the career path for a developer, and that's something that we're really passionate about here on this show. So I like to pick questions from here. Today's episode is sponsored by Rigger. Rigger offers effortless monitoring and optimization for companies that need to manage digital performance. We will talk more about what Rigger does for developers later on in today's episode. But first, I'm going to kick things off with this first question on Reddit. The first question is actually more of a story. It's coming from the Reddit user Frisky Business. I'm sure we're all aware of the creative user names that people come up with for Reddit, but Frisky Business says we hire a guy who can't code. Our worst nightmare happened. I don't know how it happened, but we let somebody in who doesn't know a thing about coding. Forget failing FizzBuzz. The guy doesn't even know the difference between a variable and a string. And this is rough stuff. Frisky Business and anyone else who has ended up in the situation, the one thing that very clearly has not happened is some direct evaluation of that person's coding ability. And we're not talking about going back and searching through that person's GitHub account. Because there are many ways that you can spoof the GitHub account, right? You can go and steal code from someone else. You can copy and paste code. You can take boilerplate code. And so very clearly, whoever this person is was not sat down in a room and asked to code something. And it doesn't have to be that formal. It doesn't have to be an on the spot kind of pressured situation. Instead, what I recommend at least is to give the person some kind of project. This requires a hiring process that spans a little bit longer than a day, of course, but get the give the person a project to work on over the course of a week or two weeks that allows them to exercise some of the same exact skill sets that you need them to have in the workplace. There are ways to do this on the spot as well. I don't like doing coding challenges on the spot because a lot of the time, they don't really simulate the environment of a real project, right? The person is not on their own. They're actually being watched in a coding challenge. The person is also not able to use Google easily, which is unrealistic. But there are some benefits to a coding challenge, for example, figuring out how someone thinks, how they go about solving a problem. How quickly can they react when a problem occurs? How quickly do they recognize when a problem begins to occur? So there are some things that are positive about actually watching that person go through the process of coding, but really in either scenario, what you're really trying to do is determine the actual technical abilities of this person. In the history, their coding history on GitHub or a project that they send in themselves, that's not sufficient. You need to assign some kind of problem for this person to work on. Now a little bit of some clarification or I guess some advice for you if you're planning on doing this with another candidate in the future. Do not assign them client work that you're going to make money off of. That's a bad faith move on your part. Don't try to make money off of somebody who is applying for a job. If you actually charge your client and the person who is applying for a job, you give them a project that you're going to deliver to the client. Don't do that. Because if you're making money off of someone, then you should be able to hire them. That's the whole concept of an interview. I've seen companies that will pay someone for the work that they do on a project during the interview. I've also seen companies that say, if we choose to use this work, we will pay you for the time that you spent on it. My preference is to do exactly that. Give the person a project that they will likely continue working on if they get hired. In other words, that project that they did is a part of their interview process. They're just going to keep on working on that when they're hired. They know exactly what they're doing on day one because they've already been introduced to the client or they've already been introduced to the product that they're working on. That transition is a whole lot smoother. For people like Reddit user, Frisky Business, and anyone else who ends up in this kind of situation to avoid it in the future, quite simply test the abilities of that person. Do so with something new. Don't go back and try to deduce what their abilities are based on their past history. Test them directly with a problem that you know the solution to. It brings up an interesting point about problems and solutions for front-end developers. This is a little bit different because the solution is one of many possible solutions. This is true for other code as well, but typically you can't run the result of front-end development through a series of tests to determine if that person succeeded or not. There's a lot of subjectivity that comes along with certain parts of these tests. You are testing some of those subjective measures as well. This is particularly important for the front-end developer because if that front-end developers' responsibilities do not include the aesthetic side. In other words, if they are not the ones that are creating the design for the thing that they're ultimately going to be translating into the browser, then it's possible that their previous work doesn't have the aesthetic value that you are looking for. If your company is hiring a front-end developer, it's easy for you to judge that front-end developer's work based on the way that it looks. It could be that that front-end developer was working on a project with a designer that isn't in the same style or quite simply isn't as talented as another designer. It's very important that you test your candidates based on your standards. It's important that you provide them, for example, with something that is similar to the work that they would be doing in your office. If you have a designer on your team, you should provide them with a designer from that designer. Ultimately, what we're saying here is make sure you're testing the abilities of the people that you're hiring inside of your situation, inside of your context from your values and test them by your standards. The next question comes from user Dawson J. Bailey. I'm going to have to do a little bit of censorship here. You all know that Developer Tea is clean, so we'll jump over a couple of these words here. Dawson says, going into college soon, pursuing computer science. Am I screwed if I have very little experience with coding yet? And goes on, I'm scared that everyone else going into this is already a WizKid who has made iPhone apps, and I'm just a guy who likes video games and wants to work with computers for living. I have no real experience except for a Python class I took in high school, and that was still pretty hard for me. Dawson, the answer is you are not screwed if you have very little experience with coding. In fact, when I went to college, I went for music. I hadn't touched a piece of code in my life when I went to college. The same is true for many, many other developers. And what you are experiencing with this idea that other people are the WizKids who have already made iPhone apps, that's called imposter syndrome. And it's very common, especially amongst developers. But it's also common by the general population. We think we're imposter into a new field, especially in the beginning stages because we come in thinking that everyone else knows more than we do because we know pretty much nothing. But the truth is Dawson, you and everyone else who codes, they have to start somewhere. And today may be the day that you start coding. There are many other people who will be joining your class when you choose to go for a CS degree. There are going to be many other people in class with you who have never touched code. Are you going to encounter someone who is far more talented with code than you are in your life? Of course you are. You're going to encounter tons of people who are better at certain things than you are. How good one person is at something does not define how good another person can be at something. In other words, just because you encounter other people who are better than you are at coding doesn't mean that suddenly you have no hope. Now I'm not giving you an excuse to drag your feet. I think it's important that you go in with this idea of it being a mountain to climb. But don't not climb the mountain just because you're at the base of it. Obviously it's not easy. It's not easy to get to the top of the mountain. And just because these people started climbing earlier than you doesn't mean you can't climb it to you. Dawson and anyone else who is entering college this coming fall, good luck to all of you. If you have questions for me, if you are a college student and you have questions for me and you found this podcast, please do reach out. You can email me at Developer Tea at gmail.com. I'd be happy to provide advice and any answers that I can for you, especially regarding your career. We're going to take a quick sponsor break and then we'll come back for one more question on Reddit. Today's episode is sponsored by Rigger. Rigger offers effortless monitoring and optimization for companies that need to manage digital performance. In other words, developers, if you have ever experienced the issue of an API going down and you not knowing it had gone down for maybe hours into your debugging session and finally, you think to yourself, maybe I should go check the status page of this API. That's the exact kind of situation that Rigger is made to solve. With Rigger, you can monitor availability and the performance of your API transactions. But not only that, you can also get ahead of UX issues before they ever impact real users. Rigger also allows you to see how your site stacks up against competitors sites. You can find and prioritize performance defects and you can automatically download optimized files or images with Rigger. Here if it's seamlessly into your development process and makes it simple to compare performance before and after deployments. Or you can push alerts to systems that you already use like Slack or HipChat, Page or Duty or Ops Genie. Rigger is great for developers and business users and there's no installation required, which means you can get started right away. Book a kickoff call with the Rigger team today by going to spec.fm slash Rigger. Thanks so much to Rigger for sponsoring today's episode of Developer Tea. Of course, that link can be found in the show notes at spec.fm. So I'm going to take one final question from the Reddit, the subreddit CS career questions. This question comes from Reddit user Labradoral84. The question is, if I wanted to write a program to show off my programming skills for employers and then put it on GitHub, what type of techniques or methods would they be looking for? There's a couple of answers to this question or perhaps there's tons of answers to this question because it kind of depends on who that employer is. For example, at Whiteboard, since we are primarily a web development company, then if you want to apply to work at Whiteboard, it's best to have something on the web. Right? That's kind of obvious. But it's not so obvious for everyone, for every employer, what exactly will impress them? There's a couple of safe bets that you can make, though. The first one is they're going to be impressed by you doing something that is similar to what they do. Now if you can do something similar to what they do, then they start seeing you as a part of their team. In other words, they start seeing the value that you could bring to the team. But perhaps a more valuable thing or a more impressive thing would be to do something that your employer aspires to do. So if you are wanting to work for a company that works in iPhone development, and let's say you have enough information to know that they want to work on a building apps with Swift, and most of their developers currently only know Objective-C. Well, it's probably a good idea for you to build something with Swift. That's kind of a contrived example, but the idea here is to accomplish what the employer, what they want to accomplish, show them that you can help them reach their goals. Now I do want to make a quick side note here. Your goal here is not to impress your employer. There's a lot of people who can write code that is totally outside of the wheelhouse of a potential employer, and they wouldn't really fit on the team because the code that they're writing doesn't really complement the team, right? Your goal should be instead to figure out a way to convince that employer that they need you on their team. It doesn't matter how impressive you are, what matters is how effective you are. It's not a bad thing to impress, but the more important piece is to focus on being effective for your potential employer. I hope you guys have enjoyed this slightly different version of Developer Tea today. I will include a link to these questions in the show notes. I hope you have learned something or have been inspired by today's episode. If you have questions for me, you can always send them to developertea@gmail.com. Thanks again to today's sponsor, Rigger. Rigger offers effortless monitoring and optimization for companies that need to manage digital performance. If you want to start monitoring your performance, the APIs that you're using and measuring how effective your sites are against your competitor sites, go and check it out. Spec.fm slash Rigger and set up a call, a kickoff call, today with Rigger. Thanks again to Rigger for sponsoring today's episode of Developer Tea. And until next time, enjoy your tea.