20 ms·

Resumes are dangerous?

• gopaz 4y ago
  I also look for github links, especially for sysadmins, it can give an insight of how they solve things. Bonus points for pull requests. However, if the person doesn't have a profile, or an inactive one, I don't put any weight on it, it's more an alternative way instead of asking interview questions for me.
• quanticle 4y ago
  The first thing I look for in a resume is a GitHub URL. If I can find that, I stop reading the resume and start reading code. Doing open source is not a be-all and end-all by any means, but it's a good starting point. After five minutes of reading through a candidate's code I have a good handle of their skill level and style, making the interview run much more smoothly. All this makes me want to do is delete my entire Github. I do not want a future employer judging me on the basis of the half-finished amateurish experiments I knock off on my free time as I'm learning a new language or messing around with a new framework or just screwing around in general because I'm bored. If all this person is evaluating me on is my Github, they'll think that I've never advanced beyond an amateur level despite my having over a decade of experience in the industry... all because I treat my open source work as a hobby rather than as a second job.
  • 0xbadcafebee 4y ago
    A good employer will not judge you based on your half-completed personal work. The point isn't to see perfectly executed programs, it's to get a sense for the kind of interests this person has. Seeing a couple half-finished Go projects is better than seeing nothing at all.
  • laurent123456 4y ago
    If you don't have much to show on your GitHub profile, simply do not provide the URL. It's just one data points among others, but it's true that it's useful to see the candidate's coding skills in advance and the easiest for that is open source code (since anything else probably can't be shared).
    • Cthulhu_ 4y ago
      I've googled people's names + github if their GH wasn't provided, just out of curiosity.
    • tsukikage 4y ago
      +1. Additionally, in general, I personally prefer to keep work and leisure separate. Things that I bring to the awareness of potential / future employers are selected and curated, and distinct from places where I keep the half-baked stuff I do for fun for my own consumption. It's certainly possible to get from my real name to my leisure activities and vice versa with a concerted effort, but the first page or two of a casual Google search won't do it.
    • Aeolun 4y ago
      > it's useful to see the candidate's coding skills in advance Yes, but only if it’s representative of their work. Good luck finding the one kind of sensible library I’ve written in the 100 forks and experiments.
      • lolinder 4y ago
        That's what pinned repositories are for. It's your opportunity to highlight the projects you're actually proud of. Any half-reasonable prospective employer will look at those first, and probably only those. And again, if you have nothing worth pinning, there's always the option to leave it off your resume.
  • isthisfree 4y ago
    As an employer that does the same thing as the person who wrote the article; I do, of course, look at the seriousness of whatever is on that Github profile. I am usually easily able to tell if it is a half-baked project for some hobby-thing or active participation in e.g. a well known piece of open source software. Someone who does this, is likely also skilled enough to separate those things. I don't only look at the user's own repos but also at contributions/comments etc. to others. And just as the author, I too experience more often than not that people have NO idea how to set the level for own experience.
    • TheaomBen 4y ago
      Could you list some things that are red/green flags when perusing someone's public code/projects? I'm preparing to publicly release a project with the intent of building it up to demonstrate my own experience level. I'm asking as someone with next to no prior public code despite developping back-end almost full time since I dropped out 10ish years ago. I guess I'm asking for external criteria for whether I'm impostor-syndroming!
      • theshrike79 4y ago
        Just a few things I usually notice when going through a potential hire's GitHub: 1) All projects have a bad commit history. Just one commit and that's it. Usually it's something for school with really basic stuff inside. Most might be IDE provided "generate code" boilerplate. Even a single commit beyond the GitHub provided initial commit example is enough. Multiple ones in a sane cycle is even better. Even if you just update some comments. 2) Does the project run? If I check out the project, is there a clear way to run it or does it rely on the compile & run commands being on the submitter's bash history? Add a make/magefile or run.sh or anything. 3) README. Does it exist? GitHub pushes you really hard to add one, if you're lacking even the default one, you clearly don't understand how GH works. 4) Bonus task: does the repo have integrations or GH Actions enabled? If the project automatically runs some tests or builds on commit, it's a big green flag for me. If I'm going to be paying you over 100€/hour, I don't want you spending your time doing stuff manually if it can be automated with 15 minutes of boilerplate work.
  • tym0 4y ago
    This was also my reaction, the way I write code when I have a 20 minutes of free time after work is really different from the way I write code for production. The author is lying to themselves if they think that most people Github projects are any more representative of the work they'll do once hired than their resume is. I think looking at the Github of applicants is useful as a conversation starter however: "Oh I see you've built X with Y, what was interesting about that? What did you learn?"
    • mikepurvis 4y ago
      I agree with the conversation starter part, but I think there's still something to be said for seeing how someone's code looks when they're writing it not-for-production. Like does that just mean overly long functions? Lazy symbol naming? Linter violations? Lack of tests? Those might all be reasonable through the "not prod" lens, but there's other pretty important stuff that can still bubble up, like the person reinventing the wheel where a well known library could have been used, or using obviously non-idiomatic structures like an indexed loop in Python. None of this should be a deal breaker, but if you're seeing stuff that's obviously like "I would be annoyed to be reviewing this code" then it's worth talking about.
      • whiddershins 4y ago
        What if I wanted to reinvent the wheel to increase my knowledge?
        • lbotos 4y ago
          Make a readme that says "This project is me exploring how to do Y so I can learn the ins and outs". Solved.
          • reificator 4y ago
            And what if I’m not tracking that in such detail or even thinking about viewing it like that because it’s a side project? My repos are hidden specifically because I do them for fun. I’d make them public if tinkering were an understood thing but its not. > If you give me six lines written by the hand of the most honest of men, I will find something in them which will hang him. Better to have a clear separation between work and play.
  • dkdbejwi383 4y ago
    If all a person has to evaluate me on is public Github contributions, it'll seem like I only work one day every 3 years or so. With all the other things I do with my life (sport, art, socialising), I very rarely have any time (or motivation) to program in my free-time. Having all of these "extra-curricular" activities is probably good for my mental health and makes me a better engineer than I would otherwise be if I spent all my time both at work and in my own time working on software.
  • idop 4y ago
    Please don't delete your GitHub account because of this one person's article. I have interviewed over a hundred of developers over the years, and I have actually adopted the habit of _not_ looking at their GitHub profile because I find them to be very non-representative of the person's skills and abilities 9 times out of 10. The article isn't bad, by the way, and OP is making very true points, most prominently that resumes are mostly bullshit and shouldn't be relied upon by themselves, but that's what the interview process is for.
  • Cthulhu_ 4y ago
    > All this makes me want to do is delete my entire Github. I do not want a future employer judging me on the basis of the half-finished amateurish experiments I knock off on my free time as I'm learning a new language or messing around with a new framework or just screwing around in general because I'm bored. This is my Github too; part of me thinks I should finally arse myself, remove unused repos, and build a portfolio with some example projects of how I build software (hopefully allowing me to skip a technical interview assignment), and maybe build some libraries for various purposes. Doesn't have to be anything unique. I mean my CV is impressive (according to recruiters / employers), but it's a high level overview of projects I've been involved in, it doesn't really boil down to my individual achievements because projects are generally team efforts. I do believe this is the danger of judging someone by CV alone though; just because they were a part of a project, doesn't mean they were big contributors to it. I've seen plenty of people who do one small commit per week and call it a day. There's always the one team member who gets carried by the rest of the team, just like in school. (childish as it might be, I do believe managers should review individual team members' contributions and to let people go if they're only along for the ride.)
    • hdjjhhvvhga 4y ago
      > This is my Github too This is a very common problem and I solved it in a very simple way: one account for playing, experimenting, testing and enjoying, and another for showing off. This is not fundamentally different to how people treat HN accounts.
      • Juliate 4y ago
        Why should some specific people (employers, recruiters in this case) should have a relevant authority as to pretense what a GitHub is supposed to be for. If someone's GitHub profile is a mess, mixing experiments, serious work, goofy stuff, etc. as a result of their multiple uses of it (it's a _tool_ per se), that's up to them and it's up to no one to say "well, that doesn't look very professional to me, does it? your worth doesn't look great here".
        • 4y ago
  • kwhitefoot 4y ago
    In the Soul of a New Machine Tracy Kidder relates how toward the end of the development of the Nova that Data General started rejecting applicants who had anything computer related as a hobby or spare time interest. If memory serves, they believed on the basis of experience that people with a broader range of interests were better team players and more resilient to burn out.
    • skeeter2020 4y ago
      While this may be technically accurate, the rest of the descriptions on how they interviewed & hired was brutally narrow-minded and biased. You're missing the part where they basically didn't hire anyone with a life outside of computing because you were being hired for an all-consuming death march.
      • kwhitefoot 4y ago
        No, I didn't miss that point. That was the reason they finally changed their opinion.
  • ekianjo 4y ago
    Why include your Github URL then if you think its only awful code?
  • deepstack 4y ago
    > If all this person is evaluating me on is my Github, they'll think that I've never advanced beyond an amateur level despite my having over a decade of experience in the industry... all because I treat my open source work as a hobby rather than as a second job. Thanks you for bringing that up. That is one of the reason I don't use GH. Other being the acquisition by MS.
  • beej71 4y ago
    Private repos are great for those half-baked projects you don't want people to see.
    • antholeole 4y ago
      I think this is forcing me to choose between two evils - do I want to look like I can only write half baked weekend projects, or do I want to look like I don’t write any code in my free time at all?
      • bodge5000 4y ago
        Fair point, for me its the latter. I cant put on my CV brief descriptions of side projects I'm working on, during an interview I can give more details on those, etc... Still not ideal because they'd probably want to see the code, but its the lesser of two evils for me
    • deleted 4y ago
      [deleted]
  • lbotos 4y ago
    You can do that or you could also put a readme on your GitHub that it's a place where you explore hobby projects and you are interested in "x, y, and z". When I go to a GitHub as a hiring manager, I try to get as much signal as I can. You are scared that I'll solely judge you on the code, but I'm looking for metadata. Is this person interested in or exploring problems/technologies that are related to the problems/technologies we are using here? Oh, They are exclusively doing music based coding? INTERESTING. Let's talk about that in the interview. Oh, They've contributed a bug report to an open source project, lemme see what that looks like. Nice, repro steps are clear. And yes, some hiring managers are gonna say "welp, this candidate isn't an open source ninja so we don't want them." But that's not all hiring managers. What is a big turn off for me personally is the "I'm gonna slap something on github to tick the box" group. I had someone submit a resume with a link to their website and a link to their github. The website was literally just a demo site, but they had changed all of the blog titles so it looked like real posts, but if you clicked through, it was all lorem ipsum. The GitHub was also just the code for this site. I'll take a graveyard of personal exploration everyday over a half-baked sham site. (Note: They could have just been playing around BUT TELL ME THAT! Because it sure looked like an attempt to look the part.)
    • soneca 4y ago
      > ” And yes, some hiring managers are gonna say "welp, this candidate isn't an open source ninja so we don't want them." But that's not all hiring managers.” So probably is good risk management to not include your GitHub ever when applying.
      • bruce343434 4y ago
        This strikes me as unnecessarily bitter and cynical. Application is a two way street. Would you even want to work for a company like that?
        • slothtrop 4y ago
          A company doesn't necessarily begin and end with the person hiring.
  • starkd 4y ago
    He's talking about the case where the applicant explicitly provides a github link in their resume or profile. In that case, they could have been expected to pin their favorite projects or remove the ones they don't want seen. Plus they are merely suggesting it be used as a jumping off point for conversation with the candidate.
  • coffeeblack 4y ago
    I do not want a future employer judging me on the basis of the half-finished amateurish experiments I would not want to work at a company where the tech people are not aware that most repos are precisely that.
  • mrfusion 4y ago
    Perhaps consider a personal account and a professional account. Only put your best work on the professional one.
    • em-bee 4y ago
      unless they changed it githubs terms of service do not allow multiple accounts. you'd have to split them over multiple hosting services, which, depending on the project, may not always be practical or possible
  • arinlen 4y ago
    > All this makes me want to do is delete my entire Github. I do not want a future employer judging me on the basis of the half-finished amateurish experiments I knock off on my free time as I'm learning a new language or messing around with a new framework or just screwing around in general because I'm bored. I don't understand your complaint. We have free code hosting platforms which support private projects, such as GitLab. You only showcase the projects you want to show, as a public profile is also your portfolio. It makes no sense to showcase half-assed projects you care nothing or feel ashamed to show, as no one forces you to make a git repo public. It's perfectly fine if you do not curate your portfolio, but you also get the same problem if you don't curate your CV. Personally, I received job offers based on my GitHub profile alone, as I happened to have a pet project which uses a particular tech stack used by a company. I know people who were automatically excluded from job applications as they claimed expertise on tech stacks they showcased in their GitHub profiles, and their pet projects included blatant eggregious problems which can only result from incompetence. Companies hire based on the skillset they can evaluate, and if you make it your point to showcase shoddy work then that's a problem you create for yourself.
    • dottedmag 4y ago
      GitHub is not a portfolio website. It's a code sharing platform.
    • swatcoder 4y ago
      Has GitHub introduced some “showcase” feature, because this is the first time I’ve heard that a normal public repository should be a treated as a showcase. Historically, public repos were just where you put code that didn’t need to be private, like hobby code and experiments, just as much as showcase work or supported open source projects. Has the culture changed so much that this way of using GitHub isn’t familiar to you? How do others here see it?
      • autarch 4y ago
        > Has GitHub introduced some “showcase” feature, ... Yes, you can pin repos to your profile. But you can also create a profile repo. See https://docs.github.com/en/account-and-profile/setting-up-and-managing-your-github-profile/customizing-your-profile/managing-your-profile-readme https://docs.github.com/en/account-and-profile/setting-up-an... I wrote a blog post about this and the profile generator I made for myself - https://blog.urth.org/2022/03/28/yet-another-github-profile-generator/ https://blog.urth.org/2022/03/28/yet-another-github-profile-...
  • bgroat 4y ago
    This. Whenever an employer wants to look at my GitHub I tell them, "Look, this is all going to be half finished tutorials... as soon as I'm halfway decent with a technology I go out and build something proprietary"
    • pferde 4y ago
      Do people really put stuff like "half finished tutorials" and little exploratory non-projects up on the Internet? What for? That stuff normally does not need to leave your local harddisk. Maybe exceptionally, if you want to explicitly share it with someone you have been discussing it with. Maybe I'm getting old and no longer "with it", but to me, this is just like teenagers entering way too much personal info on social media just because there are empty text boxes available. I have a "code" dir with dozens of subdirectories where I keep all that stuff. Some of those are local git repos because I'm starting to do something actually non-trivial there, and yes, some of those eventually get the "git remote add ..." treatment, and get published on a public code forge somewhere.
      • bgroat 4y ago
        > Do people really put stuff like "half finished tutorials" and little exploratory non-projects up on the Internet? What for? If I want to track version control across multiple machines without rolling my own git server or bothering to mark the repo private? I don't think it's an old thing. I think it's a HN crowd not really understanding user experience thing
      • Hackbraten 4y ago
        I publish as much as I can, and deliberately so. Not so much for internet points but because: 1. It forces me to write a README. No matter how small the project, I afford it an introductory paragraph, installation instructions, usage instructions, and a license. Doing that all the time helps build good habits. If it hurts, I’m not doing it often enough. Doing it often enough helps overcome resistance one day when it actually counts. 2. I contribute something back. It’s not exactly curl, but who am I to judge whether my project will be too trivial to be useful for others? I prefer to leave that decision up to the visitor. 3. Future me is going to get a README for free a couple of years down the road, when the details are long forgotten. Example: this repository [1] is for a 50-line Bash script [2]. [1]: https://github.com/claui/aws-credential-1password https://github.com/claui/aws-credential-1password [2]: https://github.com/claui/aws-credential-1password/blob/main/aws-credential-1password https://github.com/claui/aws-credential-1password/blob/main/...
  • polishdude20 4y ago
    Also, my public repos are all code I've done before I started working. My code has improved a lot since I've been coding every day for my job but it's all private.
  • lmarcos 4y ago
    Agree. I do have a GitHub account, but I do not link it in my CV (nor I link my personal website). I like to write "toy" software that more often than not does not leave my laptop. In the rare occasions I believe the software I write could be of help to others, I do publish it. But man, I code in my free time for fun! I couldn't care less about following guidelines or the latest patterns or using docker, or whatever.
  • MisterBastahrd 4y ago
    I'm never going to work for a company whose hiring managers require me to post hobby projects on Github. Won't even entertain interviewing with them. I shouldn't have to spend thousands of hours a year working on shit outside of work to prove that I can do my job. If it's not obvious from the interview and whatever test I'm given, then we have nothing further to discuss. One of the reasons I don't suffer from burnout is that once I'm finished with my full time job and my consulting side-gig, I leave it alone. I might dabble in some new technology from time to time, but there's no reason to announce that to the world.
  • ensignavenger 4y ago
    So don't put your github URL in your resume? If you don't want a potential employer to look at something and judge your ability based on it, it doesn't belong in your resume.
    • tmp_anon_22 4y ago
      Lots of resume aggregators and ATS require or at least present a Github URL field whether you like it or not.
      • mdm12 4y ago
        In such cases, I stick with the tried-and-true 'N/A'. I still get offers, so it doesn't auto-delete my application!
  • renewiltord 4y ago
    That's a strange thing to do, in my opinion. That makes me want to put my Github (which is half half-baked nonsense, including this stupid `hello.S` from when I was barely learning amd64) on the resume. I do anyway, but it is now a reason to double down. After all, if my hiring manager can't correctly evaluate which code is toy and which code is real (I have both on my Github), I don't trust his competence and I want to not talk to him so it is important that he filter me out. This way, my time is not wasted with incompetents.
  • pizza234 4y ago
    > I do not want a future employer judging me on the basis of the half-finished amateurish experiments I knock off on my free time as I'm learning a new language or messing around with a new framework or just screwing around in general because I'm bored. In this case there's no need to publish this type of code; Github offers private repositories for free. If one is convinced that there is value for other people from half-baked experiments, it's definitely worth publishing them in the open (it's possible that they're valuable), but if there isn't, why doing it? I also notice that many people display private commits in their profile stats; this way, one can signal the amount of activity, if they want (within the limits of what's possible, as certainly commits don't necessarily correlate with intense activity).
  • ozim 4y ago
    That is one person so I would not read too much into it. When I read CV and I see github link it is "nice to have" so I check it after I consider that person has enough work experience. I have only seen "meh" code on GH. If someone would have contributions to some real OSS project he would probably jump queue to front, but it is not like I would throw away application because person is trying just stuff out on GH. That said - I don't see value in putting my own trash projects on public GH profile. I can have it in local repository or in private repo if I want to synch it between computers or deploy to VPS.
• mcv 4y ago
  Of course a resume could be full of lies. That's why nobody hires blindly based on the resume but always has an actual interview. During the interview, talking about code, you'll notice soon enough whether the candidate knows what they're talking about. And that doesn't have to be (whiteboard) coding challenges or questions about obscure language details. Just talk about how they code, what coding style they prefer, how they organise their code, etc.
  • denton-scratch 4y ago
    Not sure what a "whiteboard" coding challenge is. The last interview I did, I was asked to find and fix a bug in a small code fragment. On my own, I'd have fixed it in a jiffy; with two interviewers looking over my shoulder I was nervous, and it took longer. But if you're interviewing on the basis that the candidate claims in their resume to know language X, then a brief test of that is essential; and an online test doesn't cut the mustard - it could be anyone doing the work.
    • mgas 4y ago
      A Whiteboard coding challenge is the exact thing you describe. But instead of interviewers looking over your shoulder, they look at the whiteboard as you stand in front of them and write code on the whiteboard.
  • beej71 4y ago
    I've found this works to great effect. I ask the prospective interviewee ahead of time for an example of some code they wrote that they're proud of. And then in the interview, I ask them to teach me how it works, what could be improved, etc. I might not know anything about it, but I can tell when someone's pretending to teach a thing. Once had someone bring in a device driver in C for a JavaScript position. Now, I've never written a device driver, but I know the general concepts, and the applicant's description was cogent. They got the job, and they were a great hire.
• Distozion 4y ago
  It's an interesting duality of engineers - love the coding challenges when they are the ones evaluating, while refuse to do them themselves :)
  • rmbyrro 4y ago
    I'm usually open to coding challenges when the challenger is going to dedicate at least 10% of the time I've put for a feedback. Some people think it's OK to ask the candidate to dedicate 2 hours, then send an automated email rejecting. I don't think this is polite, let alone respectful. At least have the decency to dedicate 10 minutes to writing down three bullet points for why they were rejected.
    • Yhippa 4y ago
      You even get a rejection email?
      • deleted 4y ago
        [deleted]
  • higeorge13 4y ago
    People use the take home tests the wrong way. They should be sent to a small number of candidates that are close to the final stage. But most people send them after the first filter. Then they waste both candidates’ and their time and also spend zero time to send any valuable feedback since the pool of candidates is big at that point. And this creates a frustration to experienced engineers not wanting to spend any time on such a process.
    • dvtrn 4y ago
      > But most people send them after the first filter. I once got sent an automated email after applying to an org with a coding challenge before the first filter. Before even any recruiter/HM or anyone actually at the organization sent me an email acknowledging they received my application. I initially bristled, and reached out to the generic "recruiting@" email that was present in the HackerRank email for the company, asking if I could at least have a screening call at minimum before committing time to a coding assessment. They said no. In the position of "needing work yesterday", I did the challenge. And was promptly ghosted.
• baazaa 4y ago
  There's like half a century of IO psych literature showing resumes to be very poor predictor of job performance. Good to see this guy's own experience confirms what everyone (besides managers) already knew.
• didcot 4y ago
  *I'm only upvoting this article in hopes that people will read the comment section.* "The first thing I look for in a resume is a GitHub URL. If I can find that, I stop reading the resume and start reading code. Doing open source is not a be-all and end-all by any means,..." I really enjoy coding in my few hours (read < 1 hour) of spare time after my son goes to bed, and while I could spend that time preening immaculate projects to impress employers and keep my commit history alive, that would kill the joy of programming for me. I would seriously consider a career change if maintaining code as a second job was required to keep my career alive. Additionally, I have seen many job candidates attempt to make github accounts specifically for resumes and the results are mostly mediocre due to the lack of time and motivation required to build something informative enough to effect the outcome of a hiring. If anything the general consensus from looking at theses github accounts is on average more negative than positive when we see repositories of "bootcamp" exercises. The author states a disclaimer "Doing open source is not a be-all and end-all by any means" which may be true in his case, but what he is doing is encouraging this behaviour in other workplaces. IMO resume-github showboating has lessened in the past few years, but I would hate for us to regress again.
  • fer 4y ago
    Yep, fully agree. I'm considering writing a small library that I've always needed at every job I've had (and always had to half-ass implement part of its functionality due to time/budget constraints). To have it slowly cooked, pristine, fully tested, reliable and a pleasure to use for people. Because that's what I wanted at those times in those jobs. Not only I would love working on it, but would also help with an aggressive "if you like it, good, if not, good luck with your coding tests" approach to being hired. Disclaimer: I do poorly in tests. But if I was required to have that, I wouldn't ever had a job until now, simple as that.
• k__ 4y ago
  "first thing I look for in a resume is a GitHub URL" Ah yes, gatekeeping at its best. Because every skilled person has time to build stuff in public.
  • rmbyrro 4y ago
    It doesn't have to be a real-world open source project. Could be a project you built to learn a language or framework, for example. Or some library you wrote for your own personal use. If there's nothing sensitive, you can publish it under an open license or even without any license at all...
    • nemetroid 4y ago
      My employer doesn't allow publishing code that was written during working hours.
      • Gravyness 4y ago
        Why would you publish code that was written during working hours? Why not publish an university project, a learning exercise, or something you built for fun? Surely there is more reason to create something than you're getting paid to do it, right? Or are artists just silly?
        • nemetroid 4y ago
          I think some of my university projects are published. But they're quite old by now, and not representative of the production code I write. I do learning exercises quite frequently when getting into new libraries/frameworks/languages, but again, that's on company time. I don't begrudge others that do, but I don't code in my free time, I have other hobbies. Thus getting back to the original point made: > Because every skilled person has time to build stuff in public.
        • marssaxman 4y ago
          I publish practically everything I write in my free time, whether it goes anywhere or not, but I would never link to that playground on my resume!
• rmbyrro 4y ago
  Wouldn't hurt adding a (2012) to the title.
  • verytrivial 4y ago
    (Or editorializing to add an accented-e. I honestly thought I was about to read a story about resuming some process after it was interrupted!)
• Juliate 4y ago
  The whole article gives a strong "never work with this type of person" vibe, with a big NO to their own 3 closing questions. From the naive "GitHub profile is relevant" take, through the "a developer MUST know the ins-and-outs of their techs anytime or they're just not worth it", through the "code is the one thing that matters" (sheeesh...). I would happily fail and laugh out from an interview with that kind of employer profile.
• irjustin 4y ago
  Resumes are dangerous, agreed - but only if you give them enough power to be dangerous. The point is, resumes should only open the door to live interviews and be very rough notes about what a person can do. You always need a way to test what the candidate claims. I'm not sure if this is obvious, but I work in the loan underwriting space now and any piece of data that the clients have the ability to control, we take but we must verify with other pieces of data that the client doesn't have access to manipulate. i.e. Accounting software like Xero needs to be back with bank transfer data. Seems like a prudent route with resumes.
• kerberos84 4y ago
  resumes can be full of lies, github profile as well. that is why you have an conversation (interview) with the candidate and get to know them.
  • keskival 4y ago
    People keep saying that, but I have never encountered an untruthful resume. Fraud is a crime.
• 7speter 4y ago
  I see a lot of comments here deriding githubs, but what if you’re breaking into the industry? Surely in this case its a good thing to have a github link on your resume? For me, being one of those people trying to break into tech, I curate my github with projects, whether success or failure, to show the sum of my own initiative and research, whether borrowing code structure from a given online course for a bigger project, or practicing a concept on my own (I got much better at this recently). While I may not have a degree or previous work experience, I think my github can be a useful indicator for a prospective employer; whether I’m at a place they are fine with and/or I’ll be someone they could get up to speed with if need be. Maybe I’m wrong…
  • watwut 4y ago
    There is difference between judging people based on what they claim to be their portfolio and based on everything they have on github. What you describe sounds like a portfolio. But for many people, their github is more of free backup space. They dont curate it. The whole "stop reading what they done seriously and look only at what is in their github" is the issue.
    • 7speter 4y ago
      Oh, I have a portfolio too, which is a distillation of the “complete” (enough), mostly front end projects I’ve worked on. My github has those as well as attempts at fullstack projects for whom I get hung up with affordably and practically hosting… I think both can help create a picture of where someone is.
  • pydry 4y ago
    This'll probably get me downvoted but I suspect the comments come from a position of insecurity as older tech people with kids and without much spare time are afraid a line on their CV might not be competitive with 20 somethings with a shiny github profile.
    • 7speter 4y ago
      Whats more absurd is I may end up like these people rather soon since I’m a 30 something :)
• makach 4y ago
  Hiring people comes with a high degree of risk. That is why you have a probation. Reading code is also risky. I usually forget why I did what I did and more often than I would like to admit the BLAME is mine - a resignated "..who wrote this?" often turns into - a-ha, it was me. Resumes is good in the same way grades are good. They might get you to the interview, so don't knock it down just yet. The hard skills are absolutely important! But the soft skills are equally so. When you talk to your candidate your first impression will be the most important indicator on wheter you will be able to endure working on varieties of task in the immediate future and far away future. My favorite soft metric is to take them to lunch and observe how we can interact, talk and <sic> hygiene.
  • the_snooze 4y ago
    I think more organizations should have candidates (especially senior ones) give a job talk. It's standard practice in academia, but academic job talks tend to be overly long and high-stakes; basically an hour-long lecture about one's research. An industry job talk could just be a 15-minute presentation about a technical topic of the candidate's choosing, followed by Q&A. The candidate has full control over what the topic is, and the audience (i.e., the hiring panel) gets a good feel for that person's interests, communication skills, and soft skills.
    • Cd00d 4y ago
      This is what my company is currently doing. First step after a screener call is a 45 minute meeting with the hiring panel to present anything the candidate wishes - some presentations try to fill the full time, some are brief and there's more discussion. We started doing this to get rid of the repetitive background summary the candidate has to give with each member of the hiring team in 1:1s. Overall, I think it's working well, and wish that places I was interviewing for myself would follow a similar process rather than multiple hours of 1:1 before a tech screen.
• eric4smith 4y ago
  I saw something here a few days ago in about "reading code for an interview". We were in the middle of hiring. And I decided to give it a shot. It was eye opening. Our stack is Elixir and I made the programmer tell me what a few functions were doing line by line and he aced it. I'm hiring him. (He does not know Elixir). This is completely right. Resume's are a waste of time. They don't tell you about any of the capabilities of the candidate. If anything some candidates are smart enough to make a really beautiful resume to fool you.
  • deleted 4y ago
    [deleted]
• gitgud 4y ago
  People that lie on their Résumé's, may also lie on their Github profiles... but that's admittedly a bit harder to fake
  • jeroenhd 4y ago
    It's pretty easy to grab some open source project from Gitlab, alter the commit history to pretend it's all you who wrote it and uploading it to Github. You can also grab some inconsequential JS library, change the name, and publish it to NPM. If you're putting in the effort to take your resumé, you might as well fill out a fake Github. After all, the "hiring experts" only seem to care about the code you've pretended to write.
• lordnacho 4y ago
  Huge problem with this, apart from not everyone has a GitHub, is that code and expertise are not the same thing. You may spend years learning about some field like systems programming, and then when you make a contribution to the Linux kernel it's only a few lines. There's no way to know from that how well you actually understand the kernel. You might have a lot of experience, but so did previous contributors, so it looks like you only did a little bit when actually you know quite a lot. Also there's a lot of work in coding a few lines of code that isn't just those lines. You may have taken apart very large systems and grepped huge amounts of logs to understand something, while having written many intermediate versions of a solution, only for you to figure out the problem could be elegantly solved. For me the smart way to interview has always been the open ended technical discussion. People who don't know the vocabulary show this very quickly. Imagine pretending to be a surgeon, you'll last one minute. People who are close to the work but haven't done it will last a bit longer but there are so many technical terms they will also drop out, typically when you ask for some sort of judgement on A Vs B. This still hasn't gone wrong for me, my only dud hires have been people who wanted to do something else rather than couldn't do it.
  • gwd 4y ago
    > Also there's a lot of work in coding a few lines of code that isn't just those lines. You may have taken apart very large systems and grepped huge amounts of logs to understand something, while having written many intermediate versions of a solution, only for you to figure out the problem could be elegantly solved. If that's the case, then that should be evident in the commit log. My one commit in the Linux kernel mostly just moves a few assignments / variables around; but the commit message should make it clear the effort that went into it. https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v5.18-rc4&id=a5ebe0ba3dff658c5286e8d5f20e4328f719d5a3 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...
• davidhyde 4y ago
  > "Then, come the interview, the guy can barely code, much less know the ins and outs of variable scope. It turns out there is very little correlation between how good a resume is, and how the interview actually pans out." I think that this is more of an argument about how inaccurate and dangerous interviews can be compared to how dangerous resumes are. You can practice interviews and get better without actually becoming a better developer. Same with algorithmic coding tests. Developers who are happily employed rarely get to practice interviews.
  • keskival 4y ago
    I'll second this. It is more likely the interviewer has misjudged the ability of the candidate for any one of myriads of potential reasons in the interview proper, than that the resume was somehow deceptive.
• thunderbong 4y ago
  This article is talking about seeing only aspect of the interviewee. In my opinion, although coding capability is obviously required, there are so many aspects of an individual that needs to be seen before they can be hired. Also, Github is not the only code repository in the world!
• smallerfish 4y ago
  As a hiring manager for a tech startup, I find resumes useful as a filter. There is a class of applicants who produce 3-4 page resumes filled with tedious details, with every technology they ever used bolded, and turgid prose describing internal software projects as if they should be common knowledge. It takes me probably 15 seconds to move on to the next candidate if I see one of those. The next thing I filter on is choice of employers. If I see health insurer, big insurance, blah fortune 500 firm, government contractor, ... over and over again, then unless there's something in the first half of the first page of the resume that otherwise catches my eye, that resume is also going in the discard pile after 30 seconds. Finally I'll scan for interesting projects. I generally want to find people who have done more than just CRUD UIs, and show some passion about the technology they've built and worked with. For somebody who makes it past this point, I'll have spent max 60 seconds with their resume. I then customize and send the message in the ATS and invite the applicant to check out the company and job posting.
  • htkibar 4y ago
    This is horrifying to read. So much bias...
    • smallerfish 4y ago
      Tell me one you find horrifying and I'll explain the rationale for doing it.
      • tqi 4y ago
        What kind of projects are the people you hire working on, and is it more than just CRUD UIs?
      • ensignavenger 4y ago
        The Fortune 500 one is a bit disconcerting. I know there are a lot of Fortune 500 developers that would not fit well in a startup, but there are plenty of interesting projects within many Fortune 500s where you would find great developers who would be great startup employees. You do say that you look for something else that catches your eye... but its hard to know what that may be and is probably a lot of chance. You also state that you want to see "passion" for the technology they have used. I don't really know how to put that in a resume. I have a lot of passion for most of the tech I use- I think that would show within minutes during a conversation or interview. But I'm not confidant my resume really communicates it. Putting "I Love Python!!!" in my resume seems a bit over the top...
• denton-scratch 4y ago
  > The first thing I look for in a resume is a GitHub URL. Wow - that would narrow the field a bit (if the github account is a pre-requisite). For example, I don't interact with Microsoft online properties at all. I don't much care for git. And even if I did use git, I'm not in favour of entrusting important information to online service providers such as Github. Lucky I'm not looking for work, I guess.
• stmw 4y ago
  "The interviews are spent discussing code, and writing code. It's what we programmers do day in, day out. It's the one things that matters." - very true. That's also literally the idea behind interviewing.io and similar platforms that have been making this point for years* - so they get to coding with the candidate as quickly as possible. Maximizes information for both the hiring manager and the candidate on whether they want to work together. * https://blog.interviewing.io/resumes-suck-heres-the-data/ https://blog.interviewing.io/resumes-suck-heres-the-data/
• jeroenhd 4y ago
  The nice thing about this method of hiring is that I probably wouldn't want to work for a company that trusts someone with such silly biases to pick candidates anyway. The code I write and push to my self-hosted Gitlab is none of your concern. If you're going by some trivial standard (github repos, leetcode ranks, whatever the case may be) you're going to be talking to a lot of people who made it a priority to get hired, not to write good code or even work well in a business environment. I'd argue that high-effort resumé stuffing is even worse than the lazy kind, because you might be tempted to give the candidate the benefit of the doubt or skip over some of the validation questions that a resumé-based hiring process might demand. You might even end up hiring bad coders who are better at making stuff up and repeating textbook excerpts than writing or maintaining any real code. The author states that during interviews he talks through the code the interviewee has written and the decisions they have made, but such a process could easily be reversed as well. Grab some company code with known architectural flaws or technical debt and walk through that. Ask what they would've done differently and why. Ask what they would do to improve it. This probably works best with some archived code from stale branches or sunset products so you don't give off the impression that you're doing this for your gain and you won't risk leaking any important company secrets anyway. Better yet, grab some of your company's open source projects (Your company has a public Github as well, right?)
  • inetknght 4y ago
    > The code I write and push to my self-hosted Gitlab is none of your concern. From an intellectual-property standpoint: it actually might be. But I do think intellectual property laws need to change.
    • deleted 4y ago
      [deleted]
  • commandlinefan 4y ago
    > I probably wouldn't want to work for a company that trusts someone with such silly biases to pick candidates anyway The good news is, it's probably not true anyway. Whenever you see these posts, they're almost always written by somebody with a weak resume who spends all of their free time maintaining open source, hoping to convince somebody else to read their github profile.
• jimmydeans 4y ago
• nojito 4y ago
  >The first thing I look for in a resume is a GitHub URL. If I can find that, I stop reading the resume and start reading code. Doing open source is not a be-all and end-all by any means, but it's a good starting point. After five minutes of reading through a candidate's code I have a good handle of their skill level and style, making the interview run much more smoothly. We get well over 500 applicants per role. It’s absolutely unreasonable to ask our hiring teams to go through the applicants githubs
  • keskival 4y ago
    Much fewer than 500 would be left after the initial screening I would hope.
• cryptica 4y ago
  Resumes are not as dangerous as technical tests. 90% of top companies have terrible technical tests which select mediocre candidates and pass up on excellent candidates. Technical tests with time limits are the worst; this is in part because if the candidate doing the test is more skilled than the engineers who designed the test, the candidate might take longer than anticipated to complete the task because they've thought to do some additional sub-tasks which the people who designed the test did not anticipate and which they would not appreciate or understand. For example, extra logic related to error handling and security will take more time to implement but are critical in evaluating a developer's skill level. It's happened to me multiple times that I did a test but could not complete it within the allocated time. Then explaining to the engineers why it took longer to complete just doesn't register because they don't seem to understand how important this error handling logic is or why it's important to reset the state of the system between each test case. I usually don't insist much because if they are like this during the interview process, I can be sure that they will be even worse if I start working there. It's sad because many of these jobs are highly paid and would provide credibility on the resume - At least until the industry figures out that the financial success of a company is usually not correlated with tech talent; certainly not the kinds of companies which solve every problem by throwing 100 engineers at it... That's just brute force; it doesn't require much skill. Another issue with technical tests is that some developers with a background at a famous SV company will expect you to do things a certain, very specific way (based on how the famous company did it) and not realize (due to lack of other industry experience) that there are multiple valid ways to achieve the same (or better) results for the specific use case which is being discussed. They are overfitted to their past role at the famous company.
  • shagie 4y ago
    > ... 90% of top companies have terrible technical tests which select mediocre candidates and pass up on excellent candidates. This is one of the confusing parts of interviews. They are not necessarily designed to select the best candidate, but rather the least risky candidate. It is quite possible to have a technically excellent candidate who would be a very risky hire and the interview process is set up to avoid hiring that candidate.
• code_runner 4y ago
  My biggest takeaway from this article: this is why I deleted all of those projects from github never to be seen again (prior to private repositories).... the projects where I was just having fun for once and learning instead of being stuck in analysis paralysis and trying to think about 85 different OWASP recommendations at once. My biggest takeaway from the comment section: thank god that there are more reasonable people than I first assumed. I have an idea for a hobby/fun webapp I could build that maybe one or two people I know might get use from.... and I'm excited just thinking about it because its going to be low stress and a fun learning experience. Thats what my personal github is. I don't put the link on my resume and I don't really have a desire to either.
• TimPC 4y ago
  Resumes are mostly useless in tech. Juniors have too little of note to put on them and Seniors only need to demonstrate enough experience to get a tech screen given the severe shortage in talent. Filtering out someone because they didn’t put enough time into their resume is silly. It’s even more silly when that resume may be a scrape from LinkedIn and may not even be provided by a first party.
• 0xbadcafebee 4y ago
  I think the best alternative to the Resume is Q&A. I think job applications should include a long list of questions to get specific information from the candidate, which would (for example) show how much they know about coding, about working with peers, about what kind of company values they care about (if any). Of course, filling out the same hundred questions for every job would be terrible. So there should be a website that collects all the questions and lets you resend them to each employer, and lets the employer pick which questions they require and which they don't. The employer could also fill out questions from candidates, because the candidate should have a lot of questions for the employer. Candidate should be able to select the questions they want answers to. If both candidate and employer answer questions, an algorithm should automatically sort for which candidate and employer had the same questions, and (assuming multiple choice and weight/priority) which answers were the same or closest. In this way you could simply fill out questions and immediately find the job that matches you best, and the employers could find the candidates that match them best.
  • Isthatablackgsd 4y ago
    > Of course, filling out the same hundred questions for every job would be terrible. So there should be a website that collects all the questions and lets you resend them to each employer, and lets the employer pick which questions they require and which they don't. This is what I did with Obsidian.md, any questions for the applications will be copied and pasted to Obsidian with my answers. If I come across a different applications that have similar question, I look up in Obsidian and use my answer from there with small modification of my answer to fit their culture or mission statement. It helps a lot because often the company I applied for usually asked for Cover Letter. Obsidian.md have my cover letters for various companies I applied for and it is easy to look back to those and find the one that fits best or create a new entry with a copy of the previous letter and modify it from there.
  • nharada 4y ago
    Would this just create a market for answers to the most common questions found at the large companies?
• nerdjon 4y ago
  "The first thing I look for in a resume is a GitHub URL. If I can find that, I stop reading the resume and start reading code." Many others have commented on this line so just throwing in my opinion. I have long wondered if my lack of having public code on GitHUb has been an issue with getting hired. (Not that I really have issues, but you have to wonder what opportunities you did not get). My lack of any code isn't out of a lack of love of coding (I in fact do, I have a few personal projects I have just never chosen to open source them... largely because I know that I made some questionable decisions since I had no code review). I also struggle with getting into working with other projects, not necessarily out of a lack of desire but it just feels daunting. I do truly understand the desire for this, but if this is something the hiring manager was looking for... I would hope that once they do hire someone they encourage them to open source some of what they are working on or contribute to projects while working.
  • keskival 4y ago
    You don't need to open source your code to publish it on GitHub. You can just put the code there in a public repository, but not put an open source license for it. The code remains your copyright and no one else has a license to use it.
• cosmiccatnap 4y ago
  This explains a lot about the state of the industry and why so many good developers have a hard time finding a job. This article does everything except consider the possibility that maybe, management uses the wrong metrics to determine the usefulness of a candidate and that resumes are flawed to the extent that you can't describe a humans experience on one side of one sheet of paper.
• skeeter2020 4y ago
  Finally the tables turn! Engineers cry "hiring is broken!" not undestanding the game is not optimized for the candidate. The OP: "Resumes are dangerous!" not understanding they're a gate-keeping mechanism that's gamed to get an interview. They were never intended to provide the interviewer with a complete representation & background material. That paper rockstar got an interview; would you have given them one otherwise?
• giantg2 4y ago
  I just assume anything I do will be seen as a negative. Don't list a GitHub - negative. List the Github - they assume that's my top quality code and that it wasn't mostly written 8-10 years ago.
• ChrisMarshallNY 4y ago
  I wouldn't call them "dangerous," per se, but they are mostly done to fool AI screeners, these days, and are nothing more than a few data points and buzzwords. > The first thing I look for in a resume is a GitHub URL. If I can find that, I stop reading the resume and start reading code. Doing open source is not a be-all and end-all by any means, but it's a good starting point. After five minutes of reading through a candidate's code I have a good handle of their skill level and style, making the interview run much more smoothly. My experience, is that interviewers don't look at this stuff at all. It's downright crazy. Instead, they rely on leetcode tests. These are short, academic tests, using algorithms that are seldom seen IRL (I have been coding for over thirty years, and have never seen one single binary tree. I've seen one or two roughly similar structures in some image processing algorithms, but only in a couple of ones that weren't very performant, and we ended up removing these). But they can be practiced, and are quite familiar to folks just barely out of college. I've not bothered to practice these. I can do OK on them (they are usually just common sense exercises), but some kid that has spent most of the last month (of their current employer's time) practicing these, will absolutely kick my ass. It's not worth it. Also, I have noticed that interviewers are looking for rote answers, which also applies to more practical exercises, like take-home tests. They don't like unusual approaches. They are controlling for conformity. That's interesting, as some of the companies doing this, are crowing about "disruption."
• mgas 4y ago
  Too many people here are crowing about the GitHub thing, and not enough about: > Above all, I try to hire people who I'd want to pair with tomorrow. People who are better than me, and people who I can learn from. It seems the only way to get hired period is to have all the experience in the world, at least from the author's perspective. This mentality is far more dangerous since it disallows the idea that someone can get better at a job over time. Also I feel like this conclusion is just a longform version of "we only hire ninjas and rockstars". The author openly disdains applicants who are so "full of themselves" that they send in overly detailed resumes, but conveniently omits the fact (which everyone here knows) that resumes have to be catered to the filters of your HR software to even land on a hiring manager's desk. His conclusion is that stuffed resumes are for losers, and only he, the hiring manager with the Midas touch, can see the true value of an individual by glancing over their code and preparing some pitfall questions. This smacks of self-centered egotism and coder bro mentality. Also as others have pointed out, good coding jobs exist in fintech, government, and 1000s of other industries that this guy sneeringly looks down his nose at.
  • em-bee 4y ago
    well it depends whether you hire a junior or a senior position. the general rule is that if i don't hire juniors, then as a manager i want to hire people who are better developers than me. otherwise if i hire juniors, i obviously expect them to learn, but the paring point is still relevant, and even juniors may bring an interesting perspective to the team, not just their coding skills.
    • mgas 4y ago
      Totally agree on jr vs sr. Another point that is conveniently overlooked in the article so the author can have his holier-than-thou moment. It seems he's hiring seniors, and only wants stars.
  • drewcoo 4y ago
    Not the author, but . . . Better can mean better at learning or teaching, cleaner approaches to problem-solving, interesting combinations of ideas I wouldn't have thought of, more potential, or any number of other things. I firmly believe in only hiring people who are better than I am. That involves looking for ways the candidate is better than I am instead waiting for the candidate to fail the entrance exam.
• motohagiography 4y ago
  > Would I want this person to be my boss? Would I learn a significant amount from him or her? What if this person went to work for our competition? Sincere question I would have is, people who work at companies with intense vetting processes to find just the right person, fire fast, and avoid bad hires at all costs - how is that going? You're in, do you see yourself still there in 3 years?
• travisgriggs 4y ago
  Oh goody. Now I can anticipate an article in a week or so talking about the issues people are having relying too heavily on using GitHub trawling as a hiring signal.
• vmception 4y ago
  2012 with 2012 logic A couple hiring managers and recruiters here still do it, thats cute One things thats changed since 2012 are that private github repos are free
• irrational 4y ago
  >Surely resumes are the only way to deal with the volume of job requests some companies get? This is partly true. It is truly shocking to me how many resumes has spelling and grammatical errors. If there is one single document you will ever write that must be spelling and grammar error free, it is your resume. As soon as I come across a single spelling or grammar error in a resume, it immediately gets trashed. I don't care how good a programmer your are, details matter. If you are going to be sloppy with your resume, you are going to be sloppy with the company's code.
  • miguelrochefort 4y ago
    > I don't care how good a programmer your are, details matter.
    • irrational 4y ago
      How do you know I didn't do that on purpose? ;-) But, I don't care about your spelling and grammar mistakes in emails and slack messages (and hacker news comments) after you are hired. Its just on your resume where it matters.
  • maxk42 4y ago
    > It is truly shocking to me how many resumes has spelling and grammatical errors
  • zem 4y ago
    fortunately i am at a place in my career where i can safely count that as a bullet dodged and move on. for my part i make a particular point of ignoring irrelevant spelling and grammatical errors (especially the latter, because not only does it discriminate against non-native speakers, but even among native speakers "correct grammar" depends strongly on your primary dialect of english, which may not be the same as that of the candidate), as long as the resume itself is clear and unambiguous.
• agentultra 4y ago
  > Then, come the interview, the guy can barely code, much less know the ins and outs of variable scope. It turns out there is very little correlation between how good a resume is, and how the interview actually pans out. Be careful with this assumption. Interviews generally measure how well a person responds to anxiety. This can overwhelmingly dominate and mask any signals about their competency. I can talk about algorithms and data structures all day and have little difficulty solving fairly challenging problems. Stick me in an interview and, depending on a lot of different factors, I can easily come across like this person. Sure I've built open source libraries, written countless articles, and have given talks at open source conferences but at the end of the day I can't handle 5 hours of talking with people and then do even the most basic tasks. Anxiety and exhaustion will over-ride everything at that point.
  • xena 4y ago
    I wonder if that's why I tend to do better at job interviews with a mild bit of entheogens in me.
• jasfi 4y ago
  Resume parsing is something I'm working on, see https://lxagi.com https://lxagi.com, it's in the examples.
• dopamean 4y ago
  I dont understand the point of these blog posts. Is he trying to say this is how everyone should hire? Because if we all only hired based on "would I want this person to be my boss" or "is this person smarter than me" then no one would ever get their first job in the industry. I cant help but feel like this isnt even how this guy actually hires. This feels like a post intended to gain linkedin clout or something. Edit: I feel like it's worth noting that this guy is "Chairman of the Board" at his company and previously "CEO." So his expectation is that everyone he hires who is presumably paid less than him be more talented than him. What does he think this blog post communicates to potential hires?
• deleted 4y ago
  [deleted]
• woeirua 4y ago
  I prefer to ask the applicant to either submit code that they are proud of, or to do a small toy problem if they don't have anything they can readily share. Then we talk through their code during the interview, asking them questions like: what problem were you trying to solve, did you solve it, what problems did you run into along the way, how would you design this code differently, and of course any specific questions if we find glaring technical issues in their code. I've found this approach to have a very high signal-to-noise ratio as it's virtually impossible for someone to talk at depth about their code if they don't know what they're doing. Also, you can't study for this type of interview, so you can't game the system.
  • bern4444 4y ago
    I had an interview where this was the case. I had a bit of code I was very proud of and had fun writing. It wasn't more than 75 or so lines. This was the best interview since it allowed me to share a related interest of mine through the code sample I brought.
• jeffrallen 4y ago
  "Tell me a story of when you solved a difficult bug." "Tell me about a time you found yourself in conflict with your coworkers." These two questions, in the hands of a skillful interviewer and interviewee, will get you all the info you need.
• jameshart 4y ago
  Mostly, resumes I see are just... lifeless. A list of places you have worked, with dates, and names of systems or applications that will mean nothing to me, and the technologies upon which they were built. A resume like that tells me nothing more or less than that you have remained employed as a programmer for X years. I am usually sifting through multiple such resumes, all of which tell me that these candidates are... yup, definitely programmers. They have programmed stuff. Please, when writing your resume, try to add one thing to each of the date-range jobs that you list: Tell me how you grew and developed in that time. Just a couple of sentences highlighting the main things you learned as part of that role. Why do you consider yourself a better, more hireable person now, than you were before you did that job? That is worth so much more to me than exactly which version of .net that particular SaaS billing platform was built in.
  • jjice 4y ago
    As someone who was in college very recently - this is exactly what they tell you to do, at least at my college and with all the new grad resumes I've looked at as well. It's unfortunate.
• throwaway675309 4y ago
  Every time something like this gets posted and even so much as mentions that they look at your GitHub, people come out of the woodwork with their fists clenched an impotent rage. In the time that I've worked as a interviewer for some of the companies that I was employed at, if somebody includes a good hub link I always make sure to check it out. I'm not looking for necessarily best practices or the exact way that you code, but sometimes people put their personal projects on there which to me shows passion for software development, as well as the exploration of new ideas. So sure, if your GitHub is just filled with half finished tutorials and unintentionally miss clicked forks, any interviewer worth their salt is going to notice this and then discard it as a signal. If 90% of the people on hacker news had their way, We would discount any possible means of evaluation and just hire somebody by rolling a D20.