Hacker News Reader

Comment by mudrockbestgirl | Hacker News Reader

This will not apply to all companies, but for our hiring decisions certs have an adverse effect. If someone puts many certifications on their resume my expectations are lower and I likely won't consider them for interviews. It's a negative signal in my experience. Your time is better spent working on side projects, contributing to open source, writing a blog, etc. I.e. do real-world stuff instead of wasting time on artificial tests that require memorization and exist largely as a revenue stream for certification providers.

View on HN

Be careful about the bias in single-metric gatekeeping strategies like this. Contributing to open source projects, having side projects, et al are pursuits of leisure. Certificates are possibly the only foot in the door for folks working multiple jobs with kids, etc. and the government often pays the tuition for low income folks. Once you’ve got them, even if you’re more established, it would be crazy to leave them off of your resume, right?

Not only could you be bypassing people passionate enough to work their way into the field through pretty adverse circumstances, you could be inadvertently reducing the diversity of your workforce in doing so. I know it’s tough to have to whittle down a list of candidates on paper, but the closer you are to judging a person’s path rather than their capability, the more likely you’ll be to favor people who mirror your cultural identity and experiences. So if someone looks like they’ve got the requisite skills. It certainly doesn’t mean everybody with a pile of certs is worth considering, but it’s probably not a good immediate disqualifier.

> Once you’ve got them, even if you’re more established, it would be crazy to leave them off of your resume, right?

Not necccesarily. Depending on the cert and field it may make sense to.

The goal of getting the cert should be to learn skills. If you've done that, the piece of paper doesn't matter.

> Not only could you be bypassing people passionate enough to work their way into the field through pretty adverse circumstances, you could be inadvertently reducing the diversity of your workforce in doing so

The people with all the certs still got interviewed where i worked last, it was just a consistent pattern that they bombed the interview, usually very badly on very basic questions.

If you've got a few certs and two jobs under your belt that you got because of those certs, how would anyone imagine that those certs would prevent them from getting jobs? For people with traditional industry on-ramping, it might seem intuitive that someone would want to hide these certs from people for their lack of prestige. To others, hiding your only officially-recognized qualifications seems absolutely ridiculous.

Are you sure those were verified? It used to shock me that people who put on cv “5 years” of programming experience in language X could not write switch statement in it, not anymore. Certifications like CKA can be verified online, cvs should include verification link; CKA/CKAD expires after 3 years, CKS after 2 years so it’s physically impossible to have too many of certificates like this.

> Once you’ve got them, even if you’re more established, it would be crazy to leave them off of your resume, right?

Recruiters and hiring managers go through so many resumes, the last thing you want is to have someone looking for a programmer to read about your basket weaving skills.

My strategy has always been to tailor the bulk of the resume to the job I'm applying for. Bring everything else up during the interview if there's natural time to do so, because that's where they want to see who you are.

We're talking about relevant certs, here.

I agree with you in principle, but it's difficult to draw the line when the hiring process needs to be practical. We can't interview everyone and perfect recall isn't necessary. My experience from dozens of interviews has been that many certifications are a rather strong negative signal, at least for our standard software/data engineering roles. I'm sure there are many exceptions to this, but I'll happily miss out on 1-2 good candidates if that means I can filter out 50 bad ones using the same signal.

Of course it's never a binary decision and the complete picture of the resume matters. For example, if someone got a bunch of certs 20 years ago when they started their career that doesn't have any negative impact. But more often, people try to use certs and MOOCs to pad their resume and hope use them to hide the fact that they lack real work experience.

I hear you and have been in your shoes. Hiring is hard, and the steps to hire people ethically are pretty nebulous, which makes it much harder. Especially when the outcome would be the same in many cases, it does seem awfully impractical.

But that's the problem with bias in general, though— It's always a matter of practicality. It's been some time since most discrimination deliberately stymied people with a background or makeup the dominant culture considered objectionable. These days it hides in the subconscious mechanisms governing the purportedly rational generalizations we rely on when lacking time and resources to properly investigate something.

I don't think it's anybody's fault— it's a bug in our brains and we can't control that. I do think we're ethically obligated to push back when practical requirements compel us to make those generalizations. If we expect police to do it when someone may or may not be pulling a gun out of their pocket, we should certainly expect ourselves to do it when we've got a queue of resumes to process.

I think it's an interesting point to make, and it's important to understand that this type of selection is a form of bias. But I think the comparison you are making here with law enforcement using bias towards people of color is not exactly right. There is a difference in signaling by choice (what to put on your resume) vs signaling by nature (skin color). I think we agree that there are some things we cannot change by nature, and a selection bias based on these properties is (in every case?) ethically unjust. I do not agree that it's ethically unjust to have a selection bias on things that are behavioral.

If someone is coming into an interview naked I'm going to reject that candidate. Am I being biased towards unclothed people if I do that? Should I continue the interview and try to find the candidate's fit for the position and disregard that they are choosing not to wear clothes? I think it's no different for a candidate that chooses to list certain things on their resume. Nobody is forced to list all of their certificates on their resume. It is a choice the candidate makes, and what else do I have to judge a candidates fitness than the choices they make in how they represent themselves and their skills?

You can certainly make an argument that listing many certificates is a shallow signal and you should invest more time into getting to know a candidate better before you choose to reject. If someone chooses to use this signal you can make an argument that they will possibly miss a few good candidates. But I don't think you can make an argument that it's ethically unjust to do so.

The whole point is that disadvantaged folks are more likely to use certificates to get a foot in the door and economic hardship in the US is not evenly represented among skin colors— not even close. Folks who don’t natively have the right accent, word usage, cultural reference points and demeanor to seem “credible” and be a “good fit” for internships or jr positions don’t have a lot of options to obtain that credibility. Things like certificates and associates degrees from for-profit colleges might be their only feasible option regardless of how smart or talented they are. Dismissing that entire group out of hand because it saves time is ignoring the economic and cultural realities of who you’re dismissing by doing so. You can separate the cultural implications of nearly any subconscious bias if your analysis is shallow enough.

This seems circuitous. You pre-suppose that the 50 ones you reject are "bad" because of this signal, then support the use of this signal because you rejected them. And then go further to assume the ratio of good:bad of people with this signal is 1-2:50.

I mean, you do you, but it seems that if you were actually interested in the truth you'd have a blind-interview strategy where you interview and judge based solely on the actual interview not knowing about their certificate status a priori.

Note: I don't have a lot of certs (I don't even know that the couple I do have are even up to date, nor on my resume), but this kind of response I see quite often and it feels quite smug.

I find the process of going through the effort to get a cert quite valuable, as it exposes me to aspects of <subject> that I probably would have not hit just "spending my free time on work-type projects", which is another red flag for me as an interviewee. I've been a dev my whole career spanning 30+ years, so I get the desire for "fire" and "passion" for the craft, but as soon as someone asks about what I do OUTSIDE of work that could be brought to bear for work stuff, I'm out. I can see what kind of company they are representing.

She wrote:

> My experience from dozens of interviews

That's not pre-supposing, instead, sounds to me like learning from one's job?

> blind-interview strategy

I liked that -- how does one make it scale though?

All overgeneralizations start out as conclusions based on observation. Having certificates could not possibly decrease someone’s ability to do a job. Assuming that everybody with certificates is a certain type of person and those types of people make bad workers is clearly not based on rational analysis. Might it generally indicate a some kinds of shortcomings? Maybe. If that merely leads one to investigate, that’s one thing. If that turns into a check in the con column for that candidate, that’s the very definition of bias.

Consider a certificate that, let's say, is pretty useless, just meant learning some software terms by heart for a short while and then forgetting.

If a candidate includes it on his/her CV, this can give the impression that s/he might not have realized that it's useless. Which can make a slightly bad impression

I suppose it depends a bit randomly on who happens to interpret the CV

You can't just bolt on other theoretical negative factors to change the usefulness of the analysis itself. This conversation is not about bad or irrelevant certificates— it's about certificates in general.

The candidate included them on their resume for you to evaluate, so evaluate them. Nobody's arguing that candidates with only free LinkedIn certs and nothing else should be given equal consideration to those with formal education.

The question is whether or not people with any certificates can ethically be dismissed out-of-hand because they list certificates on their resume. The answer is still no.

I wasn't writing about me -- I personally I wouldn't dismiss anyone because of certs, in fact I don't care that much about people's resumes at all.

However if I was looking for a job, I'd be a bit careful with including what to me seemed like "unimportant" certs, for the reason I mentioned

> The question is whether or not people with any certificates can ethically be dismissed

To me, the question was rather if there's in practice a risk that it happens, (un)ethical or not

I think how many certs and how up-center in your cv you put them matters.

E.g. if I'm hiring for a junior dev and get some self-taught person having done a couple of relevant online courses and so far managed to get a tech support role looking to become a programmer I'm often interested in talking to them.

On the other hand, I have seen cv's from senior enterprise/government engineers, 10 pages long, plastered all over with certs, titles, abbreviations, version numbers, iso standards, etc. and I have absolutely no idea what they actually did or achieved in their prior jobs even when googling a dozen terms. They might be great in the context they are working in, but they are from experience not a great fit for the context I'm hiring for.

The problem you describe is a resume design problem rather than a cert problem. Would you know what they could do if they merely left the certs off of the resume? I’d guess not.

It sounds like you were looking at a federal resume which are differently structured and much, much longer than private sector resumes. Candidates appreciate feedback letting them know: “Thanks for applying but I can’t suss out what you can actually do based on what you sent. Feel free to reapply with a more concise, descriptive resume.”

If they’ve worked in the federal government that long, they might just not realize how inappropriate their resume is for private sector jobs even if they’re qualified. If they can’t course correct and describe their skills in common business language, that’s a good enough indicator of their ability to adapt to the position, I’d say.

Completley agree with you. My reply was way too harsh/emotional. There are many companies that offer skill based pre-interview tests, tossing out resumes based on qualifications is not just silly but a liability and a sign of incompetence. The worst hiring managers are reductionists that act on instincts and prejudice.

> Contributing to open source projects, having side projects, et al are pursuits of leisure.

This is an old anti-pattern: tests that sound like they're about competence, but they're actually about "culture fit."

Example: Speaking at conferences. This sounds like social proof you know something about the industry, and have communication skills to boot. In many cases it actually means you are good at networking, have leisure time available to attend conferences, and get invited back to speak at more conferences because you're likeable and contribute to the conference's social scene.

In my own case, I have spoken and even keynoted multiple conferences. But I don't think speaking at conferences means much when hiring, unless I'm hiring an evangelist or community manager. If I'm hiring a programmer, I want to know whether they can program, nit whether they can talk about programming.

Anyways, I support your thesis that some (or even many) single-metric gatekeeping strategies that don't measure the actual skill required by the job are bad, and I suggest that many of them test for culture, not competence.

Yes. I do think it’s important to point out that folks using these “in my experience, people like this tend to be bad” type of hiring metrics probably aren’t deliberately discriminating and often change their approach after realizing it’s problematic. Obviously grown adults are accountable for their own actions, but not training, supporting, or monitoring folks making hiring decisions is more of an institutional failure than a personal failure.

> Once you’ve got them, even if you’re more established, it would be crazy to leave them off of your resume, right?

For sure include them if they are relevant to the role or show real commitment to a topic. If you see a string of disperate certs though it's easy to assume the applicant doesn't know what they want to do.

Not saying I would discount someone on this alone but it would raise questions for the interview if they were otherwise qualified.

And that's totally fine. We all have our own heuristics for determining what we like in a candidate, but we need to be very, very critical of those measures and make sure they aren't masking other less justifiable gut instinct decisions. Bias is generally subconscious— If it really was as cut-and-dried as we like to think, then it wouldn't be a gut feeling metric at all— we'd be able to back up our reasoning with hard facts. As rational as they might seem, 'gut feeling' criteria almost universally favor people we're comfortable with rather than the most qualified candidate. That's a real problem for folks who aren't part of the dominant culture of the industry: Millenial to Gen-X straight white and asian guys.

If a qualified candidate only having certificate credentials merely prompts further investigation, then great. However, it's quite often the tipping point between round-filing a good candidate and calling another one in for an interview. While it might seem innocuous on a micro level, on a macro level this affects big swaths of the population.

In the 2005 Study Are Emily and Greg More Employable than Lakisha and Jamal (https://www.nber.org/system/files/working_papers/w9873/w9873...), they responded to 1300 job ads with 5000 equally-weighted resumes with randomly assigned names which were either stereotypically white, like Emily Walsh or Greg Baker, or stereotypically black, like Lakisha Washington or Jamal Jones. Resumes with white sounding names were 50% more likely to receive a callback. Fifty percent! The likelihood of 1300 randomly chosen job ads being run by the KKK is pretty low. Most, if not all of them were probably letting "gut instinct" criteria swing their judgement.

If you had a video game where the sole task was getting a job, one race having a built-in buff where the callback was 50% greater without being balanced somewhere else would be insanely unfair. Not only is it not balanced, but we're literally only talking about these folks names— never mind their appearance, manner of speaking, cultural references, etc.

We all like to think of ourselves as good people but that's not enough to stop this. We need to deliberately interrogate our MO, here.

I wouldn't dismiss certs that fast as from my experience hiring for technical roles, it's a wash. I've had people with more certs than braincells, and people with certs that I loved and wanted on my team immediately.

It at least gave me something to talk about more directly because I can have some expectation on tech they've worked with.

I personally don't chase certs for myself because I don't see the point, but I find them as fairly okay talking points on a CV. And it's hard to argue any interview unfairness since the cert should imply certain levels of familiarity with a technology.

Edit: I do need to add that the cert concern was a real thing in our company but after some analysis, we sadly found some biases from the interviewers as they only considered certs for certain candidates to be a negative signal. I put a stop to that fast reminding people of candidates from more western countries with gobs of certs, and they legit didn't know their ass from their head, much less how to do anything besides press the button the manual said to press.

To this point, occasionally you'll come across candidates who have obtained certs in part because that is the way they were trained to learn in their specific personal & cultural context - but the reason why they chose to learn so much in the first place? It might be indicative of a true, passionate, focus-seeking curiosity that would make them a fantastic team member. And perhaps they hadn't had the opportunity to work in a place that treats learning and growth as a holistic part of the job. These people can become culture carriers in a tremendously positive way.

It's part of the reason I try to make "cover paragraphs" (not necessarily full cover letters) an important part of every application - it's important to give people the opportunity to let their passion shine through at the earliest parts of a process.

I get what you're saying and I think this is true for a lot of people, but hear me out.

I actually rarely read too deeply into the CV except as a source for some talking points. I have a phenomenal recruitment team so I rarely need to "guess" on a candidate from a CV (truly, they are exceptional and they really get what my team is looking for and our candidates love them also cause the recruiters took a lot of time to learn enough to talk competently about our tech scope) If my recruiters pass me a candidate, the candidate is at least good enough to bullshit fairly competently.

We structure our interviews to be very conversational -- the same points are always hit and we have a loose grading structure, but mostly the goal is to get the candidates to talk about problems and explain their thoughts really well. I do feel bad, because I can tell some put a ton of effort into their CV, but I rarely pay that much attention to it besides ctrl+f for some subjects I want to talk about or looking for a few keywords outside of our core competencies just to see how they talk about these edge cases.

Passion is good, but for me, passion shines through during the interview and the conversation and how they love to talk about what they work on. Even with the most nervous candidates, we've taken a lot of time to practice just being approachable and interested, which helps even the shyest candidates really open up. I know I had one candidate pretty recently where they were quite shy (and also interviewing in a second language, not their primary so lots of stress there). It took a little bit, but by the end of the interview, they were blushing red with pride and smiling uncontrollably with how proud of themselves they were for answering really tough questions and scenarios we had for them. (and they knocked it out of the park for a DevOps position, I don't think I've been so happy with a candidate in awhile)

I wish we got this for every candidate; their passion gets tapped and just suddenly I see someone gushing about their favorite topic.

> Your time is better spent working on side projects, contributing to open source, writing a blog, etc. I.e. do real-world stuff

Just FYI that at some companies, collecting certificates is indeed real world stuff. Some companies use it for marketing (“we have the most certifications in the industry”) and some need to to satisfy vendor partner requirements (“AWS Premier Partners are required to have X number of certificates”). It doesn’t seem fair to penalize a candidate just because they did what their company asked for.

Sure, but my question would be, are you, as the resume writer, more proud of the cert you got via your work or of the work you did at work? I've done cert stuff before as part of my job, but it never rose to the level of being relevant to put on my resume over other things I did.

My rule is always to only put something on my resume if I could talk for 2-3 minutes about it in a way that makes me look good/useful. Most of my certs, the only real thing I could say is "I spent 10-30 hours watching videos and then took a test well." I wouldn't really want to work for a company that valued those skills vs. me explaining how I applied the things I learned from the cert.

I have also seen this. A large number of certs on a resume (more than 4) is the most consistent negative signal i have seen.

I assume part of the reason is that certs are expensive and not well respected, so the only reason you would get them is if you had no other options.

Is this recent? I held every cert under the sun in the 2000s and companies GOBBLED ME UP. In the early 2010s I could walk into companies by simply having a VCP cert. I'm sure if I held a K8s or some hashicorp cert, or AWS or Azure certs I would be pulled into any org hiring today. And I put all of my certs on my resume (that I can fit with most recent first).

I should also clarify, I only put certs that matter (why put an Azure cert on a resume submission to an AWS shop) and certs that are recent (I have 20 years on my resume, why would i put my CCNA on there). I think a large number of irrelevant certs would be a negative signal. I think a large number of relevant certs AND job history to back them up would be a super strong signal.

Idk, i haven't been in the industry long enough to compare. Also, i work in security (in north america and not gov), maybe other areas are more pro-cert.

I also disagree with your first comment. Large amounts of difficult certs have never been a negative signal and I’ve been doing this for like 20 years. Especially in cyber security where a wide breadth of various knowledge is needed, certs can really help show who has the ”full-stack” so to speak.

That being said, 20+ CompTIA cents isn’t going to move the needle for me.

I say all that to say “it depends on the cert”

I think that's fair. I more saw it as the 20+ comptia certs.

Actually cyber security is one area where a lot of certs are a strong negative signal. They basically broadcast course-taking and cert-chasing over real world experience. If you have an OSCP cert I will treat that as a potentially good signal, but if your CV includes CISSP I will walk in to an interview with low expectations and if it has CEH or similar wastes of time the recruiting lead would have known to filter the CV out so that I do not even see it. This if for FAANG environments though, so maybe if you are aiming for a corporate cube farm in a smaller market other certs will be useful. Just not with me.

OSCP vs CISSP is a ridiculous line to draw, they cover very different job types.

I don’t know what jobs you’re hiring for, if any, I simply don’t see how more data is a negative signal.

I think that’s silly.

I disagree with the entirety of your reply, except for the CEH zinger ;)

SANS certs? CCIE? GSE? OSEE?

SANS certs are great

As a Red Team manager with both the OSCP and CISSP, in my opinion neither is worthless but they are oversold and they aren't really comparable.

The CISSP is a risk management cert that's sometimes oversold as an infosec cert. It's been quite useful to me in dealing with the (Fortune 1000 mostly) bureaucracies that take Red Team and pen test findings and turn them into remediations or risk acceptances.

The OSCP is a technical cert that's oversold in a different way: because the test is fairly difficult, lots of people assume it's an advanced cert. It's a beginner cert (and Offensive Security has several more you can take after it). What it does prove is that you probably have the right mindset to be a penetration tester (which is not necessarily the same mindset you need for Red Teaming, i.e., unannounced adversarial simulation).

tl;dr: I don't think any cert is bad as long as everybody understands what it's for. But I'm one of those people who collects them (at employer expense) as a way to structure my learning, and then never renews them.

I remember many years ago, Google internally knew that one of the only signals obtainable from CVs was the negative signal from number of certs. I don't think this knowledge was actually used for anything, it was just a correlation, but yeah it's sort of an open secret in the business that the sort of people who get lots of certifications do very badly when asked to demonstrate actual technical skills.

It's a response to large number of people who know very little and want to compensate with memorizing stuff and passing certificates without deeper understanding of what they're doing.

It's kind of a stupid response, especially considering that the same people would most likely view 10+ certs on your CV as a positive if your name is western-sounding...

I'm interested in an informed discussion of a comparison of the merits of the differing tech certs, not so much talking about scuba, finance, or truck driving.

How does the quality and value of, say, CompTIA, Cisco, AWS, OSCP, K8s, Linux+ and other certs compare with each other?

I'm enough of a domain expert in certain niches that I've participated in creating certification exams. The reason it can develop into a negative signal: the question banks are rapidly exhausted by the exam dump industry, and for even some esoteric exams 90%+ of the question bank with exactly correct answers are generated within a year of the exam's introduction.

With the popular exams, it is mind-numbingly fast. Think days to weeks. Crowdsourcing / MTurking the question banks is depressingly effective if you sweated over nearly a thousand question bank items for a few months with a few other expensive experts.

Labs in the exams are a way to blunt this, but I think the exam dump industry has probably come up with a way to defeat labs as well by now, because the labs run a fixed set of scenarios with variations in parameters but not the general gist. It's better, but still hackable.

What I've come up with requires discipline by a team documenting the issues they've fixed in the past, but it is so far 100% foolproof. Pick a random relatively self-contained issue your team fixed in the past; this is the most critical step governing the quality of this technique's results. Reproduce the issue in a scratch environment.

Sit down the candidate in front of a workstation set up to their preferences you gathered in advance, with all the tooling they prefer, simplifying your superfluous environment specifics where possible (like logging them into various accounts ahead of time). Set their expectations ahead of time that they will be team / pair troubleshooting for half an hour, that you aren't evaluating whether they find the root cause or not, you're evaluating how well they work with others troubleshooting an issue in some system/language/etc. they claim they are a domain expert in. Dive in.

Without fail, the ones who exam dumped their way to a certification will thrash about. Hard. Most common is they will not know where to even start, deer-in-the-headlights. Even telling the candidate straight out where to start, by using your 20/20 hindsight and artificially picking a starting point 1-2 steps away from the root cause still does not unlock them; jumping to a known good starting point is useful for the experienced candidates who freeze under interview pressure, as they usually unfreeze when given such a big head start from your IRL issue that you ran into for the first time.

You can often get a good gauge of how much and how deeply the candidate worked with the stack they claim competency in by how they navigate around, ask questions, probe for error messages, etc.

> do real-world stuff instead of wasting time on artificial tests that require memorization

Interesting, since the majority of tech interviews (from what I’ve gathered) rely on artificial tests that require memorization.

I’m not disagreeing, I also think real world experience is infinitely more valuable. But it seems like certs could actually be an indicator that a candidate would perform quite well in LC style interviews.

It's a bit glib to say that even the most leetcode interviews "require memorization". It's certainly possible to do most of them from "memorized" first principles of how various bits of CS components work instead of brute-force memorizing, and in general even when I do code problems on interviews, I mostly try to use them to either demonstrate that or determine that the candidate actually understands WHY you would do things that way.

Certs on the other hand are often just pure memorization. There's not really any way to "infer" which AWS service name matches to which service function. You either know the name of the API call or you don't. It doesn't provide much signal that you actually know how to apply that information to anything practical.

Even at their worst, most crappy whiteboard code interviews are still literally testing if you can literally write functional code, which is closer to what you do on the job than memorizing the Cisco books.

I don't see how writing a blog post is superior to a CCNA/CCNP lab test but okay (ACTUALLY NO, IT'S NOT OKAY).

>Your time is better spent working on side projects

This seems like a shaky assumption. Keep in mind that many companies, like mine, sponsor or even mandate the certification process. Meaning the justification, time, and costs didn't come from the candidate you're dismissing.

as someone in Devops/SRE I hold the same thinking as you. Whenever I see an interview come in loaded with certs, I automatically think they just know how to take tests and study for them.

It's almost 100% that they fail the interview because they don't know how to put the learning into real world solutions.

Perhaps they get enough interviews where the cert is accepted that it isn't worth their time to review these technologies ahead of interviews.

I find this take funny.

My past company had a huge pile of credits for certs because they valued them and I figured “I’ve been working with AWS; why not?” I didn’t study or prepare at all and went in using only the hands-on knowledge I picked up over my career.

I came out with all the associate certs, the AWS solutions architect pro, and their network specialty.

As a hiring manager I find certs to be a neutral indicator: you at least have to know the material to get them, but plenty of people learn the material hands-on, not from books.

Also, sometimes companies will force employees to get certified for many reasons. My own company was recently looking to renew their Gold Partnership with Microsoft and so they were looking for victims to get Microsoft certified, because, apparently, that's the requirement for partnership.

As for why companies need such partnership: it speaks well to managerial types, therefore helps win contracts.

This is also my experience. However, I would say something like Amazon's certifications may be useful if your company has gone all-in on AWS. Amazon (and GCP and Azure) have such a huge variety of offerings, and it's something that Amazon is asserting this person is at least familiar with what these things are and how they fit together, and the trade-offs. On-the-job study is, in general, not going to be good enough to get a comprehensive understanding like that, and a cert course makes a lot of sense.

I suppose if there was a reasonably trusted organization that could give the same cert for "front-end javascript", that would be good too, since there would be great value in surveying at least the major features of the current js landscape. (Probably not practical given the breadth and depth and dynamism of the space, plus the ambiguity of selection. And also, not sure what org would or could do this!)

then you should specify this in your job requirements so that people can remove them from their resume when applying.

the candidate should not be penalised for trying to tick boxes that other people have set up.

I got rejected from positions because I had a masters in computer science instead of an ECDL certificate. So I swallowed my pride and went and got one. Now, I'd agree with you that as an actual computer scientist, mentioning ECDL on my resume is embarrasing. But there you go, some HR departments have weird automated checklists, so I leave it in. I'd hate to then apply to someone like you who'd reject me because I had the nerve to list my ECDL certificate on my resume. It's a lose lose situation for everyone involved.

That's funny, because I've always felt the opposite when evaluating candidates. If a candidate comes in saying certs are "trash" and "pointless" it usually looks less favorable. It signals an unwilling to learn and/or strive for continuous improvement. Certs are not the end all/be all but they help round our your knowledge and open your eyes to things you never knew.

As far as side-projects and open source contributions, this is a two way street. When I look at side projects, I look for how well you are utilizing best practices in your code. If it's a sloppy, poorly documented mess it doesn't look favorably for you. If you use your side projects as a marketing tool they should be well-polished.

> If a candidate comes in saying certs are "trash" and "pointless" it usually looks less favorable. It signals an unwilling to learn and/or strive for continuous improvement.

Or it signals that the candidate would rather learn hands-on than take useless multiple choice tests.

I consider side projects to be absolutely meaningless predictors of anything. A cert is a poor substitute for experience but it's a signal of someone willing to learn and grow through diligence. Side projects are usually just arbitrary in value. In the very rare case that someone has a real blockbuster side project with a lot of users I'd be concerned about how much time they'd spend on it. Getting a PR approved on a mainstream project would be impressive though.

Nice try, manager ;)

We work on side projects because we __like__ it. Seeing side projects through the lense of "value" is naive in my opinion. Yes, obviously if the side project has actual users than that's a plus. But companies like seeing side projects because it __does__ show that the candidate really likes what they do for a living. Now whether the company is purposefully using that to expect people to work 60 hours a week is a different discussion. And while I'll probably ruffle some feathers by saying this, I'll say it; software is a sport. Very much like a sport, if you stop doing it then you'll get fat and lose your touch. People that work on side projects are constantly honing their craft and because of that they tend to be the best athletes.

If I owned a baseball team, I sure as hell want the best. And in my humble opinion, the best are usually __always__ working on getting better at the game. AKA working on side projects ;)

EDIT:Just want to clarify; it is WRONG of a company to expect people to work 60 hours a week. Just so we are in the same page. I am NOT condoning that.

Value doesn't need to be monetary. Just having fun is something valuable. I'm saying that 99% of the "side projects" I see are junior devs who think they can't apply for a job without a bunch of things on GitHub.

Just to clarify myself also, I don't expect people to dedicate their personal hours to work. We have a standard work week of 35 hours at my company and we generally stick to that. I'm talking about people I have worked with that had successfully side projects that were earning them money and that they most definitely worked on during business hours and were basically just double-dipping.

Reply on news.ycombinator.com