For experienced developer I don't see the point of doing simple take home test in interview. The test is too small and can't cover many things, why don't the hiring manager look at my github and believe I can deliver the simple test and pass it without doing it? Screw crud test that's for junior.

I think company want to hook you and make you spend time and prevent you to interview other companies to avoid competition. That's the only reason I can think of from their side.

What do you think?

I never do coding tasks, neither live nor something other than that. I just say "no". Good programmers are a scarce resource, there is always other company that offers more and doesn't ask stupid questions.

If my github alone isn't enough for them to understand my level of expertise, they're idiots and not worth my time. Their idiocy will expand way, way beyond giving a test task — they will override your decisions, make you accountable for what you had no power to change, delay payments... The list goes on.

tldr seek other company

Ahh duck.... those are like most boring part of the process. Complete waste of developer time and kick in the face. If I got GitHub why not look into it. Just say no and move on unless you really need the job.

looking at someone’s github is not a fair test as it varies vastly among candidates. Some elite level coderd kust have ugly hacks on their github which they dont’t want to be used as assessments. Some newbs have copy-pasted code.

But mostly: github projects vary greatly so you cannot compare a random project from candidateA with a random project from candidateB

The reason you’re given a tiny test is to give you something which doesn’t take much time from you or the people evaluating your code

It’s not to prove your level of greatness - just to prove you pass the bar of a decent developer.

Supposedly many experienced devs cannot pass simple tests. This process is just designed to filter out those - not to judge if you’re a 4/5 or 5/5

@jiraTicket The problem is each companies should be creative in hiring candidates. Some could look at github, some could look at doing live tests.

Why the need for collective consensus in a world of so many different ideas and business?

@jassole There is no (intentional) collective consensus on how to hire people.

My company does not ask some recruiter or some other company ”how do you usually test candidates?”
We do whatever we want when it comes to hiring. (Apart from the initial step of finding people to interview which is done by 3rd party recruiters)

But it often boils down to the fact that us devs at the company are very busy and have a very limited amount of time to judge candidates so we’re looking for methods which are simple and fast and fair.

Continuing my previous post:

Quite often we do look at some candidate’s github: but as it usually is with an unfamiliar codebase - it takes a while to get into them.

If we’re given a short time to assess a codebase it really does help if it’s a super simple and well known problem.

Also I’m personally unable to compare two candidates where one has a recent game on github and the other one has an old helloworld. It becomes very hard to compare.

PS: I agree I don’t see the point in doing tests like this for experienced devs.

We usually only do tests for juniors.
For experienced devs we mostly just talk.

@jiraTicket "Also I’m personally unable to compare two candidates where one has a recent game on github and the other one has an old helloworld. It becomes very hard to compare."

Isn't it obvious who to hire at that moment and save everyone time? And just be honest with someone that failed?

@jiraTicket experience for you is years of working experience? How many years?

@jassole: Nah, some devs are active on github, some aren't.
It's very common for a dev to have a few old projects on github and as they grew older, started a family etc - they stopped being active on github (but continued to grow in skills).

Sure - if we had two devs who both said their github projects are awesome it would be a different matter.
But then we still would have a hard time comparing a large complex project with decent code to a tiny simple project with perfect code.

@simpledev Generally I consider most with <2 years of work experience as juniors.
But I don't strictly go by numbers.
We usually ask candidates what they did previously and how comfortable they are with programming.

if they had a short education and never programmed before their education, and admit to feeling green I consider them a junior.

If a candidate was a dev lead a their previous place I would consider them as a senior.

If they made legit projects and programmed before their official experience I would take that into account.

Lastly it depends on the job position: if it's a frontend dev who wants to try a backend role we look for longer work experience. If the role is a React and mongodb and they done that for 2 years we assume they are better at that than someone who's done dotnet and SQL for 4 years.