How do you know if one developer is better than another? скачать в хорошем качестве

How do you know if one developer is better than another?

I think hiring developers is especially tough. It's tougher if you are not technical, because a lot of the quality of what they're doing is not necessarily apparent on the outside, like it might be in another role. A good developer is going to be someone who not only is writing nicer code than someone else, but you could take a bad developer and a good developer and they might produce something that looks very similar, but one is just structured much better, or might be much faster because of how it's written, or might be much easier to update than another one. They say that the difference between a good developer and a bad developer can be 100 times, a good developer might be 100 times better than a bad developer. Whereas, with other roles that's really not going to be the case, you might be twice as good. That's one of the toughest things that I think for people to swallow initially, is when you see a good developer might be making $150,000 a year or more, and big companies like Google, you're going to be making way more than that. But a bad developer is not really making that much less, unless they're very entry-level, right out of school, for example, so you might want to try to save money by hiring someone that's less expensive, but what you're really doing is getting a tenth of the efficiency or a tenth of the quality just for half of the price. Which isn't really worth it. So how do you decide? Do you have any tips for what you would look at if you had... I know you care about sourcing a lot, so having maybe 5 to 10 applicants, is that pretty much what you hear? I think there's a few things. You're looking for characteristics of good developers, and a few things to look at would be being really interested in the kind of technical problems that your product is solving. The kind of interest that would lead someone to... If you hear stories about them not having known how to do something, and then learning how to do it overnight, being able to turn stuff around quickly is a great sign. As a developer, you're always learning new things. Mastery doesn't mean that suddenly you know how to do everything. Mastery often means that when you're faced with a new challenge to deal with, that you've never solved before, that you're able to pick up on that very quickly. And so one great story that we heard about our developer was someone gave him the challenge of this mobile app that he had to, not develop from scratch, but he took someone else's mobile app and he had to totally change it around and they thought that this is going to take him 2, 3 weeks at the very least and he had it done in 2 days, and he's never done it before. So you want to figure out stories of, "Tell me about a time when you were able to quickly learn something, what was that like? "What were the frustrating things about that?" You really want to figure out how are they going to deal with these challenges. One bad side would be over focusing and over fixating on a specific problem that may not be important. You want them to be able to prioritize, to be able to step back and say, "This may not be worth my time, right now." And that's a problem that everyone runs into, but it can be especially bad for a developer if there is a bug in the code. That's the kind of thing where you might waste hours of your day trying to fix, and if you're managing that developer they're wasting your time, and you might not know that. And so, to have that ability to step back and see that will save you time. Working with people is really important. So, the ability for them to explain something complicated to you in ways that you understand, that's tough thing to find, but it's going to be so, so important for you. Because otherwise, you're going to end up in these conversations where you don't know what they're talking about, and so it's going to be frustrating for you, or you might just nod along and pretend you know what you're talking about, but they may be asking you something important. So, it is possible to explain something in a way that you understand. And so it's a bit more of a challenge, it's a little more than being a good developer, but if these people are ever going to be working together as a team, then it's going to come in handy when they're working with you as a non-developer, or when they're working with other developers as well. The relationships that come about when even 2, or 3, or 4 developers come together matter a lot. 'Cause you can have someone who's an amazing developer, but people don't like working with him, or he doesn't like working with people, and that's also not very helpful. So those are just the personality levels. Read more about front-end and back-end developers on our blog: https://learn.onemonth.com/front-end-... Or get more insight into how programming works with our One Month Programming for Non-Programmers course: https://onemonth.com/courses/programm...