In today's episode, I'm answering a few random questions from Reddit's r/cscareerquestions subreddit. Today's episode is sponsored by Rigor! Head over to http://spec.fm/rigor to get a kickoff call scheduled today.
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.
Hey, everyone, and welcome to Developer Tea. My name is Jonathan Cottrell, 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 at random from the Reddit, the sub Reddit CS career questions that 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 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 episodes. 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 want 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 usernames that people come up with for Reddit, but Frisky Business says, We hired... We hired 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. Man, this is rough stuff. Frisky Business and anyone else who has ended up in this situation, the one thing that very clearly has not happened is some direct evaluation of that person's code. 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 pressure. It doesn't have to be a structured 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 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 codings. The coding challenge 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 can they react when a problem occurs, how quickly can they react when a problem occurs, how quickly can they react when a problem occurs, 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. And 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, right? 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, right? 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 In other words, that project that they did as 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. And so that transition is a whole lot smoother. So 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 and 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 kind of the solution to. That brings up an interesting point about problems and solutions. For front-end developers, this is a little bit different, right? 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. So you are testing some of those subjective measures as well. This is particularly important for the front-end developer because if that front-end developer's responsibilities do not include the aesthetic side. So in other words, if they are not the ones that are creating the design for the thing that they're ultimately going to be training for, then they're not going to be able to do the same thing. So if they're not translating into the browser, then it's possible that their previous work doesn't have the aesthetic value that you are looking for, right? So if your company, this is the case for Whiteboard, 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, right? And 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 isn't as talented as another designer, simply as a product of their situation. So it's very important that you test your candidates based on your standards, right? So 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 design from that designer. So ultimately what we're saying here is make sure you're testing the abilities of the people that you're testing. So if you're testing a designer, you should provide them with a design that is similar to the work that they're doing in your office. So if you're testing a designer, you should provide them 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, and 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. But Dawson says, going into college soon, pursuing computer science. Am I screwed if I have very little experience with coding yet? Dawson goes on, 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. Dawson goes on, Dawson, the answer is you are not screwed if you have very little experience with coding yet. And I'm going to have to do a little bit of censorship here. The same is true for many, many other developers. And what you're experiencing with this idea that other people are the whiz kids 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 imposters 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 too. Dawson and anyone else who is entering college this coming fall, good luck to all of you. And 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 developertea 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 Rigor. Rigor 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 Rigor is made to solve. With Rigor, 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. Rigor 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 Rigor. Rigor fits 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, PagerDuty or OpsGenie. Rigor 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 Rigor team today by going to spec.fm slash Rigor. Thanks so much to Rigor for sponsoring today's episode of Developer Tea. And 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 Labradoodle84. The question is, if I wanted to write a program to show off my programming skills for employers and the program would be a good idea, what would I do? And the answer is, I would write a program to show off my programming skills for employers and the program would be a good idea. If I wanted to 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, that 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. Right? 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 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 are the right person for the job. 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 this. I hope you have learned something or have been inspired by this. I hope you have learned something or have been inspired by this. If you have questions for me, you can always send them to developertea at gmail.com. Thanks again to today's sponsor, Rigr. Rigr 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 competitors' sites, go and check it out. spec.fm.com. And set up a call, a kickoff call today with Rigr. Thanks again to Rigr for sponsoring today's episode of Developer Tea. And until next time, enjoy your tea.