
Why GitHub Won't Help with Hiring - benfrederickson
https://www.benfrederickson.com/github-wont-help-with-hiring/
======
ryanf323
I look at GitHub profiles to help filter / disqualify candidates. Just last
weekend, I had a marketing candidate who had stolen three Wordpress projects
from their current employer and post them as public repos on their personal
GitHub account. In addition to the flagrant intellectual property theft, the
repos contained the wp-config.php file with exposed database “root”
credentials to live, client sites.

~~~
letientai299
Perhaps I misunderstood. But isn't Github help you filter out such candidates,
is it? They have some big projects, but their contribution calandar should be
almost empty, cuz all the code is pushed into Github at once.

~~~
derimagia
No one should look at the contribution calendar and hire based on it without
looking more in depth. To answer your question it's based on commit time, but
because of that you have things like:
[https://github.com/gelstudios/gitfiti](https://github.com/gelstudios/gitfiti)

------
fecak
GitHub profiles are incredibly useful for college grads, bootcampers, and
self-taught devs that typically can't speak of professional accomplishments.

As your professional accomplishments increase, the value of GitHub profiles
(for most) as a marketing tool diminishes dramatically, but can still be
helpful.

For developers at any level, repos are a good conversation piece for
interviews. The interviewer can ask why choices were made, what the candidate
might do differently now (shows growth), and start interesting technical
debates.

I always ask my clients (I'm a resume writer and career consultant) if they
have a GitHub profile if I don't see one listed, but I don't always include it
on the resume. New entrants to the industry are not exactly punished for not
having one, but it's becoming an expectation. This is different than expecting
an older adult that may have life responsibilities that prevent (or simply no
interest in) coding outside work.

~~~
bphogan
They are also great in demonstrating knowledge in a new field. For example, if
you do C# at your day job but you want to move into Go. Showcasing side
projects can demonstrate some experience. This helps sidestep the "well, I
don't have Go experience" issue.

~~~
mdip
This -- exactly. I know of at least one person who's done this and a few
others who were able to move into areas of their preferred language (i.e.
going from a job that was mainly web/C#/MVC to mainly REST/C#/Angular or
React) by doing this.

Even _within_ a larger organization it's possible to use side-project examples
as a demonstration that you're ready to move from a team that uses one
discipline/language to an unrelated team. While a large organization might be
willing to move a senior developer who's a less-perfect-fit from a different
department if they've demonstrated that they can be trained/learn what they
need to know, it's a _lot_ easier if they can demonstrate that they're a lot
more than a "less-than-perfect fit"

------
onebot
What should be the Dribbble equivalent for software engineers then? All I hear
these days is, whiteboards for hiring is bad, asking to do a sample project
for hiring is bad, now GitHub is bad. I don't know when software engineers
became such "I don't want to show my work" industry.

Having a portfolio to show what your capable of is a great way to set yourself
apart. I don't think anyone is expecting you to have developed Linux from
scratch. But something is better than nothing. Which do you think is more
likely to get an interview, someone with several source GitHub projects or
someone that says "all my work was closed sourced" and has nothing to show.

Having founded three startups now (2x acquired), most of the best engineers I
have ever worked with have a noticeably more active Github/Bitbucket/Gitlab
portfolio than the average. In my experience, great engineers have public
proof (open source, a self produced product, book, etc) of their craft vs
nothing at all.

Now to be clear, just because someone has an active Github, or a book, or
whatever doesn't mean you should hire on the spot. But should be someone you'd
prioritize over someone that is seemingly too lazy to do any related extra
circular activity.

~~~
scarface74
I do plenty of extra curricular activity.They don't involve coding.

I’ve also hired developers. I have a simplified version of a real world
project that we are working on. The methods are skeletons with no code and a
bunch of failing unit tests. Part 1 they have to get the unit test passing.
Then I give them a harder set of requirements with unit tests. They have to
make the second set pass without breaking the first set.

It tells you a lot about how someone thinks.

~~~
onebot
I do the same as well, I think it is a great approach. It is just a paring
exercise, the language of their choice, their equipment, full internet access.
We just build something like a calculator or pig latin translator. Something
that you build up in layers. I usually read off the test cases one step at a
time, in hopes that they write their own tests along the way.

But hiring good people is very time consuming. The reason GitHub as a
portfolio makes sense, is that it helps compare potential candidates--that I
know nothing about--faster. Biased or not, I have had the best experience with
people that are very active publicly. From Battlebots competitors, book
authors, to startup founders, etc.

Ivy League Colleges, VCs, even Y-Combinator works very much the same way--
trying to make an assessment based on past accomplishments. The more visible,
the better. With the caveat being a strong direct reference.

I am sure we all have extra circular activities besides coding, but depending
on how strong your experience or professional network is, really depends on
how much you need in a portfolio. I have been coding since I was nine and have
decades of experience, I still have stuff I hack on that is public, from
SlackBots that control GPIO pins to Sonos controllers, etc. I would think the
more experience you have, the better chances you would have more stuff you can
add to your GitHub (portfolio).

At the end of the day, as a someone hiring, I am going to gravitate to
engineers that have more and better examples of their work ability and output
vs where they worked on their Resume. Not to say that we should ignore anyone
that doesn't have public projects--but they are certainly at a disadvantage
against someone that has.

~~~
scarface74
I had two positions open recently. The recruiter gave me 15 resumes, I
narrowed that down to 6, spent one day doing phone screens, narrowed that down
to three, invited both for the same day then I had them do the coding
interview I mentioned above.

I narrowed that down to two and made offers the same day.

~~~
onebot
You're about a 13% hire rate. Google is about 0.2%, Apple 2%, and Harvard is
7%.

~~~
scarface74
And not everyone wants to work for Google or Apple and not every company needs
a Google level employee. Most developers are doing boring line of business
apps....

------
lucasgonze
I am just tabbing over from looking at a github profile of a potential hire.
It was somewhat useful as a way of understanding this person's technology
style.

I saw PHP, game dev, JSON. I saw that he does do OSS stuff, though not much. I
saw that he can write a decent readme.

That's the kind of thing a hiring manager gets from a github profile. It's not
a one-dimensional test like how many checkins does the dev have.

~~~
kelnos
> _I saw that he does do OSS stuff, though not much._

GitHub will not even remotely tell you that, though. There are _tons_ of open
source projects that are not hosted on GitHub. If you, say, contribute to the
Linux kernel, or to Firefox, or perhaps Xfce, nothing will show up on your
GitHub profile to give you "credit" for that.

I agree with another poster that GH can be useful to disqualify candidates
(say if they've posted something they've plagiarized as their own), and you
might find interesting things on a candidate's profile that increases your
impression of them, but it's absolutely useless for _comparing_ candidates or
getting a full picture of what they've worked on in public.

~~~
ghthor
If you contribute to any of those large projects then you should have that on
your resume/cv with a link to the instructions for pulling down a list of the
commits related to your work. Easy Peasy.

------
stevemk14ebr
I wouldn't have been hired for the jobs i've had if it wasn't for my Github. I
don't think false-negatives should lead you to disregard the ability to find
that perfect developer. Is it not your responsibility as a developer to keep
an accurate portfolio of your skill set?

~~~
toomuchtodo
> Is it not your responsibility as a developer to keep an accurate portfolio
> of your skill set?

It is not. If an employer can't ascertain your skill level through the
interview process, their hiring is broken. It is a slippery slope where we
allow employers to dictate uncompensated signaling necessary for a role.

Observe how it worked out for everyone who got a degree because employers
won't hire without one, and then they don't get hired regardless of that
degree. So we'll all toil on public Github projects in hopes that'll be what
convinces an employer to hire? Will we all need to intern for several months
for free next?

@always_good: Hiring is hard. If you succeed in hiring the right people, it
won't be because they jumped through your hoops, but because they were
passionate, had some of the skills and could grow fast, and a huge helping of
luck.

~~~
Benjamin_Dobell
_> If an employer can't ascertain your skill level through the interview
process, their hiring is broken._

That's just outright factually inaccurate. Are you expecting employers to hire
on blind faith? If employers are hiring without _evidence_ to support your
skill-set, then their hiring process is broken.

 _> Observe how it worked out for everyone who got a degree because employers
won't hire without one, and then they don't get hired regardless of that
degree._

I don't have a degree, I got my first job because I walked into the interview
with a portfolio; more specifically a fully functional completed piece of
software that I live demonstrated. This wasn't an open-source project, but I
sent them the code to be reviewed nonetheless (I own the IP).

The reason some people with degrees don't get jobs is because people with
portfolio's (irrespective of degrees) can demonstrate their skill-set, where
as waving around a piece of paper and having no demonstrable skills makes it
extremely difficult for a potential employer to evaluate you.

 _> It is a slippery slope where we allow employers to dictate uncompensated
signaling necessary for a role._

I do somewhat agree with this. However, your portfolio need not be open-source
work, it's just common as there's _some_ proof (version control, although not
tamper-proof) indicating you did the work you're claiming you've done.

~~~
scarface74
_That 's just outright factually inaccurate. Are you expecting employers to
hire on blind faith? If employers are hiring without evidence to support your
skill-set, then their hiring process is broken._

I haven't had any publicly accessible work to show off since I posted a
HyperCard stack on AOL and freeware FTP sites while I was in college in 1995.
I've been working as a professional developer since 1996, have never been
asked to show code and have a pretty good track record for getting jobs based
on solely my interview skills and knowledge.

At this point in my career, few companies waste time even asking me about
technical trivia. I talk about the projects of the teams I've been on and led.
I've gotten jobs over the past 10 years where I didn't meet half of the
requirements going in.

~~~
always_good
Surely the argument isn't that a portfolio is a _necessary_ positive signal,
but rather that it's just a positive signal.

In other words, would you take the stance that having some quality work on
Github can never work in your favor?

What about other positive-but-not-guaranteed signals like having a quality
blog where you cover technical topics? Can that ever work in your favor? Or is
it pure noise that can never demonstrate value?

~~~
scarface74
I have to admit my own bias against actually doing side projects. While I will
read technical books dealing with high level concepts, I've never done a side
project outside of work.

I'd rather try to champion technology at my job and do a proof of concept or
if that isn't possible, change jobs.

I've been able to find jobs where what I am good at is a "requirement" and
where what I want to learn is a "nice to have" and learn the nice to have.

I find it carries a lot more weight to be able to talk about how you have used
technology at work than a side project unless the side project was a really
popular open source project.

Then again, I never work for companies with a large development team where I
can't have a large, resume building impact.

------
hnarayanan
While much of this article hits upon the right points, I’d like to add a few
things.

\- GitHub also allows you to display your activity on private projects (as
long as their development also happens on GitHub, of course). \- It’s not a
great indicator, but it’s an indicator of what kind of programming people do
for fun (or alternatively, that their employment/life circumstances don’t
allow them to be active on GitHub).

I don’t think not having anything on there is a bad thing, but I’d like to
talk to the candidate about why. Sometimes you’ll learn that people have the
most fun non-programming hobbies or the most responsibly-filled lives.

------
minimaxir
The argument that "GitHub isn't a useful indicator of skill" has the
logically-following argument "we won't look at GitHubs at all because they're
a waste of time." Which is a loss of helpful information for hiring a
candidate, and _ignoring_ relevant information seems inefficient.

~~~
cwyers
Nobody actually wants to make the most informed decision, what they really
want is to make the right decision. There's all kinds of places where
additional information leads to worse decisions:

[https://ignoranceanduncertainty.wordpress.com/2011/01/31/whe...](https://ignoranceanduncertainty.wordpress.com/2011/01/31/when-
can-more-information-lead-to-worse-decisions/)

So you may in fact want to ignore relevant information _to be more efficient._

------
crabasa
Most people realize that "Github isn't your resume" unless you are paid to
work on open source. Forking repos, submitting the occasional pull request or
a random side project don't provide much signal compared the code you've
written and the people you've worked with at past companies.

I am currently working on building a tool [1] that helps developers build
profiles that articulate very clearly both what they bring to a team and what
they are looking for in a next job. We're approaching this as a data problem,
but unlike many dark recruiting tools, we think it's important for the
developer to be completely in control of the information that makes it into
their profile.

[1]: [https://www.fizbuz.com](https://www.fizbuz.com)

~~~
craftyguy
You need to provide a privacy policy for this service.

~~~
crabasa
Thank you for the reminder! A privacy policy has been added to the website.

------
callmeed
I find this stuff fascinating, partly because I work in the industry and
partly because I love sports statistics.

One crazy idea I have it to experiment with some kind of "Sabermetrics for
software engineers"–think "WAR for developers" [0]. Using GitHub would be an
obvious data-source (how to use it and if its a good idea is an entirely
different discussion).

While I think this article makes some good points, he seems to only touch the
most simple approaches. There's a lot of things you can do with a GitHub
profile. To me, they'd never be deciding factors, but you can definitely
extract some pluses out of a person's profile.

[0]
[https://www.fangraphs.com/library/misc/war/](https://www.fangraphs.com/library/misc/war/)

------
austincheney
According to the article I am clearly in the identified top 1% of GitHub users
by commit quantity. While prospective employers may not dissect the code in my
various GitHub repositories this certainly hasn't hurt when looking for jobs.

In fact, contributing to public open source has been the proven tipping point
that shifts hiring decisions in my favor if the hiring manager is on the
fence. In all other cases the combination of a frequent open source
contributions and a strong interview have allowed me to nail senior positions
as the top candidate.

Whether or not any of this makes me a rockstar is completely subjective, but
beating out all other candidates (several dozen) hands down on multiple
occasions really increases my self-esteem.

------
knieveltech
Nonsense. The last two full time jobs and several gigs I've landed in the last
five years I provided the hiring manager with a link to my public profile on
github in lieu of a resume.

~~~
Choco31415
The author addresses that point in the introduction:

“As an example in the latest Hacker News' Who is Hiring thread, there are a
bunch of different job ads asking for a Github profile as part of the job
application.

...

While both of those posts give excellent reasons to reconsider asking for open
source contributions when hiring, my take here isn't about why it is ethically
dubious to require open source contributions or why GitHub isn't great for
showcasing your projects.

Instead, this post is about why GitHub profiles just aren't all that useful
when looking to hire developers.“

------
madrox
What I think a lot of the comments are missing is that, sure, a strong GitHub
profile can be a positive signal for hiring, but an inactive GitHub profile is
not a negative signal.

So no one should be "filtering out" inactive or boring profiles.

The exception I'll claim is for junior engineers. At that stage in someone's
career, having a portfolio matters, and should be actively cultivating some
kind of public code presence.

------
yogthos
I very much check GitHub profiles when hiring. Even if a person has a simple
project on there it shows they have interest in coding, and I can see their
style of coding. That's enough to swing my judgement when I'm deciding between
two candidates that are close. GitHub alone won't get you the job, but it
certainly will play a positive role in your profile.

------
cpt1138
If we are being interviewed like carpenters, a carpenter's work may be a lot
of effort to create and then none and it still remains created. Why is the age
or spontaneity of the commits a factor? Yes I am working in a professional
capacity and can't show any of that. Why not look at the table I created 2
years ago?

------
miguelmota
> "Interviewers Don't Check GitHub Profiles"

This generalized statement is false; some do, some don't.

Been at multiple startups and the best candidates hired have great open source
projects on github that indicates they're qualified for the role more than
someone with nothing to show.

------
wjwoodson
The only question I can answer with GitHub is "can you use git." If I'm
reviewing a candidate who says they are familiar with git based workflow and
they provide a link to their GitHub with > 0 commits, check. If not, consider
exploring in an interview.

------
brooklyn_ashey
So of the 7.4% of users who pushed more than 10 times in the last year, how
many are bootcamp students? (after you remove the big,open source projects
like all the big companies have up there) I just think these students should
know this.

------
galkk
I think that "having github will help you" is the same kind of advice as
"prefer to provide resume in pdf over doc".

There are people who believe in it, it seems reasonable, but in reality nobody
cares. Just another cargo cult.

------
tmaly
When I am hiring, I tend to use a github account with an active project as a
positive signal.

It shows me they can code, perhaps in the languages I am hiring for. It also
shows me they know how to use version control.

------
twblalock
I rarely look at candidate's GitHub profiles anymore. I used to do it, but I
didn't get much value from it, and I didn't notice any correlation to job
performance.

------
convery
One thing that have always annoyed me about Github is the lack of (free)
private repos which makes the activity history patchy. So you show that you're
active for months on end, then then radio-silence for a month. Or when you
delete/move a repo and suddenly months of activity disappears. Just makes it
look like you've lost interest in what you were working on =(

~~~
tomc1985
Please don't do this -- GitHub does not register activity or hobbies outside
of GitHub. You are arbitrarily ruling out people on BitBucket, Gitlab, and
elsewhere, in addition to the legions of programmers that cannot post their
work publicly and do not want to produce stuff on their own, unpaid, time.

~~~
to3m
Even if you do work on GitHub, when a repo is deleted, your activity on that
repo is also deleted.

------
mdip
Having personally used GitHub to aid in hiring developers, I find it to be a
_very_ valuable resource ... provided it's used correctly. The author makes a
few points that I would have considered somewhat obvious (i.e. social
networking is not a metric that indicates a successful developer) and he's
correctly pointing out that using it superficially as a sort-of "metrics
engine" for developer candidate quality is going to yield poor results.

Case in point, the candidates I interviewed -- if they had any public Github
projects: (1) had maybe one or two projects of their own that were public. (2)
They were personal projects of varying levels of "quality", i.e. not their day
job. (3) They were the only developer/committer and new commits were somewhat
rare. For the most part, just the existence of a profile with some projects
was a plus. Most candidates didn't give me a way to _see_ that they could
actually _write software_ (fizz/buzz?) -- though there are ways to solve that
without resorting to white-board or in-interview programming.

I started using GitHub and "external work" as an interview technique after an
experience with one of my best hires. This was a candidate not unlike others
that had a pretty dead profile, but there was _one_ project that showed code
quality and thought that far exceeded "the typical". It was clearly "That One
Project(tm)"; his baby. The code quality was quite good, it had documentation
and it had thought put to its design[0]. It had zero stars or forks, but it
was obvious this was a tool he wrote for himself and _really_ cared about. His
interview started out very badly because he was nervous, but the project saved
him. Mainly because I started wondering if he actually _wrote_ the code in
that project (because he failed to answer some pretty basic code design
questions), I pulled up his project and started asking him specific questions
about _his_ code. He went from nervous to excited[1] and was suddenly able to
explain things that he had a difficult time with when they were presented
simply as abstract concepts.

I used to facilitate _many_ technical interviews, but it's been a little while
since I've done one due to a new job/different company, however, I think the
method I use is still the one I'd go to. The technique I used after this
gentleman was to call the candidate a week in advance of the interview and ask
if they have anything public, code wise (blog posts,
SO/Github/Gitlab/Bitbucket profiles), that they can point me at or if they
could provide some samples[2]. I always explicitly state "This doesn't need to
be your best work, or even terribly great code, it just gives me a starting
point to discuss development practices" and I recommend they pick something
they've done recently since "any code we've written more than 6-months ago
might as well have been written by someone else" The technical interviews
would then, generally, be that candidate explaining their code, the choices
they made, why they made them and what they think improvements would be in
order of priority. That has worked _really_ well for me and beats the
daylights out of any paper/pencil, whiteboard or even "code this on this
laptop while I look over your shoulder"[3]. Assuming you successfully disarm
the candidate with the "we're not judging your code (!)" preamble, I've found
that people are _far_ more comfortable (and most legitimately _enjoy_ )
talking about things they've written -- even critiquing them[4].

[0] In this case, a unit tests covering the right parts of code,
documentation, build instructions, logical layout/design -- he cared about
this code and it gave a really good insight into

[1] Given his performance in the interview, I would have expected this person
to be introverted and not a terribly motivated programmer... goes to show how
terrible interviews are at judging people -- this guy ended up being the guy
everyone else on the team looks to -- he was passionate in a job that,
frankly, wasn't the sexiest programming job.

[2] This last point, to be clear, I expect to _never_ receive proprietary
samples. It _did_ happen, once, and I didn't think this was something I had to
actually state, but I wouldn't have hired someone who would share code they
had agreed to protect since they'd be agreeing to the same thing working on
the team they'd be going to.

[3] The difference between a great developer and a great developer who gets
anxious during interviews is that the latter might be a little introverted/not
good at interviewing -- a personality trait that I've found to be common and
for every job I've done interviews for -- not a negative (and can just as much
be a positive) for the work I was assisting in hiring for. One of the hardest
working people I know -- a guy I'd work with on _literally anything_ because
he'll make up for any deficiencies with sheer will and hard work -- has such
anxiety in interviews that he _actually forgot his middle name_ in an
interview (not completely, he just spaced -- hard -- my boss hired him anyway
on my _strong_ recommendation).

[4] A small tip: Complimenting the work is an easy way to get things started
smoothly -- it doesn't need to be phony; there's usually _some_ way to point
out a few positive things about the work. Start there, ask questions in a
manner that simply states a desire to understand the code more, and let things
roll from there.

~~~
jadavies
Interesting, thanks. Do you specifically ask the candidates if the code in
their repository is all their own work? One small thing that worries me about
relying on GitHub is that I can't be 100% sure that the author actually wrote
all of it.

~~~
mdip
Yes. But mainly only to direct my questions. Whether or not they were the
primary author was mostly only important in knowing how well they knew the
code in question. If it was written entirely by someone else but they fully
understood the code, that worked for me, too.

It was more important to me that a candidate could reason about the code in
question -- even (perhaps especially) if it was an implementation they pulled
directly from an SO post. There were occasions where I'd see unique
implementations of common tasks (i.e. pulling a value out of a URI string that
carried an unusual formatting pattern where simply using the URI parser in
.NET wouldn't have worked directly). Having worked with a few different
frameworks that use unusual URI formatting, I might ask why a regular
expression was used over writing a custom parser tied to the Uri type (or
vice-versa) and I was more interested in hearing the argument and reasoning
behind it as well as whether or not the candidate could come up with pros/cons
for both methods. Sometimes it'd be a custom implementation for something that
could be done directly with features available in the framework -- and often
the answer was obvious[0].

And a little humility doesn't hurt, either. I remember asking why someone used
a regular expression to do some rather involved data extraction from an HTML
source versus using something like Angle# and I recall the response was
something along the liens of "Well, it started with pulling just URLs for a
limited case and exploded into getting some metadata around the link, but it
was for something at home and I put a total of ten seconds into thinking about
how to do it right and if it stopped working completely, it didn't affect me
all that much". Good enough; a lot of developers would go off into tall weeds
defending bad code rather than just saying "sometimes the tolerance for error
greatly exceeds the availability of time" or "I just didn't care enough" \--
especially in an interview where you are hyper-sensitive about looking bad --
and we all have a bunch of very dirty scripts that "work ... mostly". Provided
it's not a theme of ambivalence throughout the interview, a little honesty at
a time when it's tempting to fluff gave me confidence that when that developer
made a mistake, he might actually own up to it.

[0] It's either "I didn't know it could be done that way" or the most common
"I wrote it before that method/call existed" \-- since I was hiring for .NET
positions at a time shortly after Framework 2/3.5, this was a _really_ common
situation due to many new ways of doing things arriving with Generics/LINQ.
And both were acceptable answers since it took some time for a lot of .NET
folks to grok generics/LINQ and understand them well enough to realize the
appropriate place for them (outside of just "oh, I can make a List of anything
without having to use ArrayList of object types")

------
codefreakxff
Why are we reading this post?

"I've only had one job interview in the last decade or so, but as far as I
could tell none of the people interviewing me checked out my GitHub profile
before the interview"

So that makes this guy an expert?

~~~
dang
That's really not a charitable representation of the article. When the HN
guidelines say: "please respond to the strongest plausible interpretation of
what someone says, not a weaker one that's easier to criticize", it applies to
authors as well as commenters.

[https://news.ycombinator.com/newsguidelines.html](https://news.ycombinator.com/newsguidelines.html)

~~~
codefreakxff
Well, it is an honest question. And I don't think it is uncharitable at all.
The premise of the article is that github does not help with interviews but it
doesn't really provide facts to back that up.

~~~
akkartik
It provides plenty of facts and data, but few anecdotes. That seems like a
desirable situation.

~~~
codefreakxff
I don't want to get into a comment war here. Let's just say I respectfully
disagree that there is plenty of facts and data, and that what facts and data
are there area really more of an opinion with thin data that seems to violate
the new guidelines that are being brought up to say that my comment is out of
place. In my opinion the author has gone out of his way to cherry pick data to
support his claim and has not put effort into finding data that would prove
him wrong.

~~~
akkartik
You are welcome to your opinion about the quality of data provided by the
author. But your original comment was attacking the lack of personal
experience/anecdotes. That wouldn't improve things much, one way or another.

------
always_good
Github projects don't need to be impressive or have substantial technical
depth to provide a positive signal.

For example, a good README can communicate someone's abilities in
documentation, thoughtfulness, and design.

------
imron
Stitchpunk needs to :set expandtab

------
welder
Even when combined with your WakaTime profile to account for code written at
work?

For ex: [https://wakatime.com/@alan](https://wakatime.com/@alan)

