7 ms·

It is very mature that you want perspectives and I appreciate people who are not afraid to say what they mean. You touch on a lot of hot topics here including a

by lazyseq 12y ago

It is very mature that you want perspectives and I appreciate people who are not afraid to say what they mean. You touch on a lot of hot topics here including agism, hackathons, "hacker" culture, brogrammers, and so on. I'll try to write a few replies to address your concerns. I am one of these "older engineers" as you describe. Mostly I am well-respected by anyone who works with me because I tend to intimidate, but also be very helpful and mentor people. I do feel a lot of disrespect from younger people I meet in the industry. I actually look extremely young for my age, but I can hardly pass as a 22-year old. Anyway, I'll start by discussing your generation stereotypically. I've been hiring people from universities for a few decades now and I am increasingly disappointed as time passes. Maybe I am just becoming a grouchy aging developer, my patience is wearing thin, or perhaps what I see is just reality. When I hire someone, especially out of school, I never expect them to know much about XYZ technology we use, ABC framework, or anything else I am using at the time. Simply, I look for smart people who I think my team can get along with in the workplace, are at least a tiny bit motivated to work, and are honest in every sense of the word. I learned the hard way it's better to hire someone who is a good, honest, hard worker than someone full of great ideas that can't execute or pisses everyone off each day. Unfortunately, I find myself disgusted by the type people who show up for interview and that I have to deal with from other companies. I do not ask for much. Perhaps in the words of William S Burroughs, a few "words of advice for young people" are needed: Do not turn on your cell phone during an interview, show up on time, do some basic research about us before you arrive, understand at least bullet item we wrote on the job description, etc. I'm not your dad and most definitely not your bro. Do not show up to the interview in your free give-away Angular.js t-shirt you got. That technology or framework you are named dropping and then trying to use to feign knowledge about? Well, you aren't fooling me, I probably used it or read about it, tried it, and realized that my instinct that it was garbage was true. I use more new technologies than you do because I am doing actual work as I have done for decades. Just because I am older than you doesn't mean I don't understand Ruby. Just because I don't seem impressed by your node.js github project doesn't mean I don't get it. More likely I am not impressed because your code is terrible and I am shocked that it took you so many weeks and commits to do what you would be expected to finish in 1 day at our office. Remember that class where you decided the professor was as a-hole and that it was just too early in the morning to go to anyway? Was it called data structures 101? Well, it's going to bite you one day when you interview with me and you can't tell me when you would use a hash table and when you would use a list. Remember when you interviewed with me and you didn't get the job which you thought it was because I just didn't like JavaScript? Well, you are wrong, you did not get the job because you could not explain basics in JavaScript, your favorite language. Go ahead and criticize us for using Foo technology, because even though it's rock solid stable, works great in real-world production, and is making us millions, we were waiting for you to tell us to rip it out and replace it with Bar, which your buddy just put up on Github yesterday. But that's OK, because we're a lame company, and everything is our fault. We just need you to turn the ship around, so by all means, act like an idiot because there is no way we can live without your genius. Do you want to impress me? Tell me what you know. Explain to me what will make you happy and motivated you. When you do not know something, admit it instead of trying to bs me. I hear enough bs from sales guys, marketing people, and VPs of the department of nothing to recognize bs before it leaves your lips. When you do not know something, do not give up. Tell me how you would do it differently or how you would go about finding the solution. If I give you hints or part of the solution, use it or even ask me for another hint. I am trying to help you because I am tired of interviewing people just like you. I want to hire you so I can get back to coding. I have already seen ten of you today, and I am currently considering offering a 5 million bounty for the next person who can sit in that chair and have even 20% of what we need to do the job. You can be relaxed, just not too much. Most developers who have been at it for awhile really need to stay relaxed and do not take everything too seriously. You can have fun with us and talk to us. That does not give you a license to fool around, act unprofessional, or like an idiot. This is a job, and it takes very little else but hard work like any other job. Things are done by doing, not talking. People worth impressing are impressed by actions, not words. /rant

r00nk 12y ago
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 not impressed because your code is terrible and I am shocked that it took you so many weeks and commits to do what you would be expected to finish in 1 day at our office. I have a github account, and I use it to host a few of my projects. Right now I'm working on writing a operating system. It's been somewhat successful so far, but as operating systems are a deep and complex field, and I'm definitely still learning, there's a lot of embarrassing mistakes and bad code throughout the git log. For example, I just recently learned how to properly write makefiles , and a day on my project was just on writing a somewhat simple in hindsight makefile (because I was reading the man page at the same time). Should I just not host said projects on my github? Also, when you look at a github profile, what do you look at? Asking because I can probably get more followers if I make more node.js whatever, but I really like my C and I tend to go for more challenging projects then popular ones. Is that a bad idea?
- 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).

by lazyseq 12y ago

r00nk 12y ago

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 not impressed because your code is terrible and I am shocked that it took you so many weeks and commits to do what you would be expected to finish in 1 day at our office. I have a github account, and I use it to host a few of my projects. Right now I'm working on writing a operating system. It's been somewhat successful so far, but as operating systems are a deep and complex field, and I'm definitely still learning, there's a lot of embarrassing mistakes and bad code throughout the git log. For example, I just recently learned how to properly write makefiles , and a day on my project was just on writing a somewhat simple in hindsight makefile (because I was reading the man page at the same time). Should I just not host said projects on my github? Also, when you look at a github profile, what do you look at? Asking because I can probably get more followers if I make more node.js whatever, but I really like my C and I tend to go for more challenging projects then popular ones. Is that a bad idea?

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).