It helps to not take the feedback personally. Everyone has an opinion, and they're usually shit. But flowers grow great in shit. Let it inspire you, not cover you.
Having gotten to know Andrew a bit over the last few months, I can wholeheartedly say that he cares a lot about the open source community. DependencyCI and Libraries.io are labours of love and craftsmanship!
Our analysis of code is algorithmically (hence we created go-git, to analyse every git repository on the web). We're doing some cool things here, everything from feature engineered models based on extracting attributes from code to turning code into vectors using deep learning.
However, when we have a conversation, it is never a bot speaking, always a real developer. This actually helps train our system (we are humble about being wrong) and makes sure that every developer has a good experience working with us.
Hey Toni, Founder of source{d} here. First of all my apologies for the bad experience. This should have not happened. We're a team of developers ourselves (no recruiters) working on making sure that these kind of situations don't happen to any developer (we started this because we were fed up with the bad practices in recruitment). We're definitely not a bot, I can promise you this. Every email gets read by a developer themselves (our team: http://sourced.tech/about) and personally answered. If you send me an email (eiso@sourced.tech) I'll personally figure out what happened here.
I got one saying my experience with Go would "be a good fit" with a company.
My Go codebase at the time, on that account, consisted largely of hacky products, no tests, no web-server stuff, high coupling and complexity, and below average documentation. If that indicates experience with a language, I'm almost afraid to ask what WOULDN'T be a good fit.
That, and their stated "real-time" requirements for said company's product made me laugh.
Hi Gustav! It is, all though these days we're named source{d}. We're working on some very cool visualisations to release later this year that allow you to dig in on all of the insights we've learned from your code. Right now there is no way yet, we're completely emerged on focusing on improving our backend (and doing some very cool stuff around deep learning to analyse your code). I'll keep you posted once we release.
I think HackerRank is a great platform for challenges but I personally believe it only shows a small part of your skill set. I am a developer myself but also have hired a lot of engineers in my career. I believe that looking at existing projects you've done on Github gives a much better overview of your coding style, knowledge and your ability to learn. It also exposes some of the biases I know that we have in our own company (for instance, we know that if you have a functional programming background you'll fit in much better in our code base and team, even though we don't do functional programming).
All of this said, I think HackerRank is a great place to improve your skills in solving interview challenges and algorithmic problems.
Disclosure: I am a co-founder at source{d} where we analyse all git based projects to understand developers through their code.
From experience it's very hard to know how a candidate will perform when hired, irrespective of the hiring process.
A better recruiting model IMO would be to recruit people on short-term contracts (e.g. 6 months) with the contractual agreement that the worker will transition to a permanent job at the end of the 6 months providing their performance is inline with expectation.
I do use code exercises myself, but it's not some n queens problem or something - which tests nothing practical (for the positions in my team anyhow). Rather it's a simple problem, where I look for their ability to test drive code and clean code. The candidate then doesn't get pressured as they might in a live situation. If the code is good we walkthrough it in person.
"A better recruiting model IMO would be to recruit people on short-term contracts (e.g. 6 months) with the contractual agreement that the worker will transition to a permanent job at the end of the 6 months providing their performance is inline with expectation."
That already exists. And it leads to abuse of those contract workers, because they think that if they bust themselves just a little bit more, they'll have that carrot (the job). But they're so burnt out at the end of the contract period, and the employer inevitably says "No", and then brings in a new class of fresh faced hopefuls.
Your solution looks good on paper but if a candidate has two offers one permanent and the other the 6 month to permanent , I am pretty sure most would go for the permanent offer.
Resubmitted because I have no clue why this is being killed. It is a genuine post, I've been a member for over 6 years and want to share and get feedback from the community. Nothing spammy or shady going on here.
I've been a proud member of HN for over 6 years and am happy to get to post a Show HN again (has been 780 days since the last one).
This is the second attempt to post today (the last attempt was marked as duplicate post as a Show HN done on this domain years ago).
We spent the last 5 months building this product from complete scratch, we visited 250 startups across Europe. I would very much appreciate everyone's critical feedback.
For those who are at startup school next Saturday in London, come find the guy in a Tyba tshirt.
