8 ms·

Hey there, one of the young guys here, trying to weasel my way into a job, I have a few questions for you If you don't mind. You said this: More likely I am n

• lazyseq 12y ago
  Well honestly, that part about Github was a bit of a joke grounded in some real-world experiences. Mainly I was just referring to people who act mighty about something that is in essence, nothing. Further, I am referring to people who obviously are struggling over basics, but are not humble enough to recognize it. Amazingly, people love to brag about things they are actually not skilled in at all. As for public facing programming-related artifacts and sites, I don't think it's a good idea in general to judge people on things like Stackoverflow, Github, etc. It's not that I don't at all and not that my colleagues don't, but rather we place appropriate weight. Mainly when we asks for things like this, we just want to see what your writing and code looks like to get an idea. If a candidate said to me, I don't have a Github account or I have better code I can send to you, then that's fine. There are so many arguments why judging people this way is bad that I would end up writing a book in reply. This is why sometimes we'll do a coding test regardless because then we can at least have greater confidence that the person actually wrote the code we are looking at and that they are capable of executing the type work we are interested in doing. Even for coding tests, we mainly put weight on the explanation the candidate gives rather than the code. You learn a lot about how someone understands problem solving by asking them to explain their code and walk you through it. Moreover, it helps weed out the cheaters, pretenders, and liars, of which there are many. Regarding your case, I would never really penalize someone that harshly based on their commit history, at least in isolation. As you explained, there are many factors at work. If a candidate explained why there were so many commits and 3 months ago, he did x and then now he's doing y, I wouldn't care. I would actually just look at the explanation itself, rather than the commits. Be wary of any employer that cares too much about your Github. Although one should be humble in interviews, you also to a small degree are seeing if the company and people are a good fit for you. If the interviewer is placing too much stress on things you feel are irrelevant, it may or may not be indicative of other future problems with them. I have noticed for instance that people that I have co-interviewed someone with sometimes become very antagonistic when they feel threatened by the person they are interviewing. That is, their ego gets in the way of doing a constructive interview. If I had to pick specific things I look at when viewing anyone's work including Github: 1. Clean code with a consistent style. This is rather subjective, but I think that most of us develop a feeling for the things we want to see. A good developer searching for other good developers should recognize that good is not simply coding very similar to yourself, but rather that the code has easily identifiable merits, even if you disagree on some choices. Simple things like namespaces and following the standards of the language are easily identifiable and hardly debatable. 2. Understands the material. In the case of Github and your commits, part of that might be understanding how to use git. Things like rebase vs. merge come to mind, cleaning commit history and branches, and so on. We all make mistakes and do stupid things like use git to move things between machines to get something done fast. It's fine, just keep things tidy and use the tool properly most of the time (preferably all the time obviously). If it's a programming language, don't write Lisp like C++, don't write JavaScript like Java, and so on. 3. Recognizable that it is actually the person's work and not plagiarism. Bigger problem than you may think. 4. Obvious that something of value has been created. I've seen a lot of node.js projects linked to me by candidates that are in essence doing nothing but wrapping something else, then outputting it to a pretty UI that came from someone else, i.e. Bootstrap. A lot of this can be fine, but there better be a point to the project and the description given by the candidate should match reality. If it doesn't, it just feels like bs or a lie. It's OK to use tools like Bootstrap, but just don't take credit for those parts as if you did it all yourself, from scratch in assembly or something. 5. Good behavior. This can mean a lot of things. For example, how does the candidate interact with issue submitters? Is the documentation broken? Do they seem to post a lot of crazy, false, ridiculous stuff everywhere (your language sucks type stuff, sweeping false generalizations, etc).
• lazyseq 12y ago
  Let me also add some more specifics for your case: 1. Program whatever you want. Don't go for popularity. If you don't do what you want, then you won't finish. 2. Corollary to the first item, finish what you start. 3. Anyone who judges on stars as an idiot. I will use the sweeping brush. In the same way it's hard to make a hugely successful startup, being good and being popular are two different things. Without naming languages, frameworks, etc., I personally find a lot of the most popular stuff to be among the worst tech wise. 4. Consider making some of your projects private if you are really that worried. Github is for open source, public collaboration. Although it provides private accounts for pay, I am not sure it's always the best deal financially. If something needs to be private, then hosting on a public service may not be the best idea anyway. Either self host, or at least comparison shop. More generally, don't put things out there you don't want people to see. I'd even add people need to stop putting things out there that are not worth seeing as it just makes it harder and harder to find what is a toy vs. a real project. 5. For Github profiles, mainly I look at what I mentioned in my other post. Code quality over quantity, good behavior, and claims match reality. Finally, I will add that you should not take on things that are too ambitious. While it is good to challenge yourself and you learn, it is much better to take on projects you can finish. This is a hard thing because it requires motivation and the related skill of picking something that is challenging enough to keep it interesting, but still feasible. I say this as the author of multiple past game engines that I never fully finished and released for instance. I often tell colleagues the following rules about projects in general (again, challenge yourself within reason and for mental exercise, but consider below general statements about programmers): 1. Don't make a programming language. You probably aren't the guy to do it. There is most likely exactly two people in this world in every generation qualified to do this well and you probably are not one of them. Unfortunately, many people have made programming languages who should not have without naming names. 2. Don't make an operating system. This is hard. Really hard. Same points about #1 hold, only you probably also need an army of people helping you to do this right. Obviously this may not apply for some small scales and it's find to experiment, but your OS isn't going to change the world. No one will care about it and realize that the software usually makes the OS, rarely the other way around. There are a lot of abandoned/nearly abandoned OS code-bases that are much better than anything we use, but they didn't have developers, weren't cost effective, etc. Console wars have shown the same thing in the past. 3. Don't make a database. You probably will do it wrong. Your database will be fast and fix all kinds of problems the past ones had, but when you start adding in the real features, things change. Soon you will realize that your database now has similar problems to the ones you wanted to fix because as you had to do things like transactions, clustering, backup, logging, and so-on, your optimizations could not work anymore. A lot smarter people than you worked on these problems a lot longer. If they could have magically fixed many of these problems, they would have. While it's true legacy code and corporate politics get in the way here often, that doesn't mean that the same won't happen to you. If you do need to make a #1, 2, or 3, please sit on it for a few years first and talk to people smarter than you before you start. And don't neglect security either. 4. Pay attention to the past. Someone probably made what you made many times before. The first or second time was probably the best, but everything since has just been worse with the benefit of faster hardware. Instead, just simply dig up the past if you must and do what they did in a modern context, giving acknowledgement and credit where it is due. Learn from the mistakes of others as well. 5. Whatever you built is insecure. Ask a security expert or 50 to review it, and then get some coffee because you probably have twice as much work to do to fix it as when you first built it. Better you ask these people before you even write a line of code or at least very early in the process, or hell will descend about you quickly.