> if I'm hiring someone to solve problems, I'd like to see how they solve a problem; and certainly your github is a record of you solving some problems.
Is this to do with your comfort level in understanding their approach?
> need to invest considerable time understanding the codebase you are working on and the problems your changes are solving before I can even begin to properly think about your changesets
Completely fair.
> during We Just Got New Budget So Let's Recruit All The People month.
Lol
> One might then go look at github repositories as well as scheduling longer meet-and-greets for the most interesting people to make the final selection.
I see, so using the activity and portfolio _after_ the fact as a means to gauge additional signal once the baseline has been met
> Moreover, many publishers don't accept direct applications, or only accept them during specific, brief, time periods - by requiring the author to get an agent to agree to represent them, they are effectively outsourcing that initial screening step)
> Is this to do with your comfort level in understanding their approach?
No, this is to do with knowing that they can, when asked to solve a problem, actually solve the problem. Just like Spolsky's fizzbuzz test. A surprising proportion cannot.
As part of a live interview, it also tests a bunch of other things that help me work out whether we would be happy collaborating on things: what's this person like to explain things to? What are they like at explaining what they're thinking or why they're doing what they're doing? Are they the sort of person that actually listens, or the sort that pattern-matches and ends up answering a different question to the one I asked? And so on. But a quick show-me-you-can-problem-solve-at-all, laugh and move on is the main goal.
> For most of the hiring funnel you want to evaluate everyone the same way so that you can compare each candidate apples-to-apples and so the hiring team builds expertise in the interview process
That is a great point! Similar to admissions tests to a college I suppose.
> Their activity might be mostly in a natural language you don't understand, and how could you evaluate that fairly?
Good point as well.
> That said if a candidate provides their GitHub or other portfolio then I think you should consider it just like any other part of their resume, not to replace the coding challenges but as part of the chat about past experience.
I think I understand. Would it be fair to say that, you consider the the "score" of the coding exercises as weighted higher than potentially significant contributions and maintenance of open source projects _because_ they are normalized?
I don't think anything can substitute for actually passing at least a small test. In https://www.youtube.com/watch?v=PUP7U5vTMM0 Gordon Ramsey says he asks new cooks to make scrambled eggs, and if they can make a good scrambled egg, he knows they can cook. It's like that, anyone can talk a big game but at the end of the day you can either make good eggs on demand or you can't. You can either write the function that produces the specified output or you can't.
A surprising proportion of applicants, with plausible-looking CVs, cannot write code to calculate the mean of a bunch of numbers. They spend most of the interview on what is meant to be a 30-seconds-long relax, have a laugh and move on question. Many apply through agencies, and the agents know I ask this question and I know they give the candidates a preparation pack and this does not help.
I've been lucky enough not to have seen that happen, though I have seen at least one candidate tragically fall apart on a more complex question, and that can be painful for everyone.
Why do you keep using these agencies that send you unqualified candidates?
Also, I think the better way to structure coding challenges is as a series of increasingly difficult problems that build on each other. If the candidate gets stuck on the easier problems, you can just quietly ignore the later ones. It feels very risky to start an interview with something like "Okay, hah, here's a real simple one to get us started," because if they fall apart there because of nerves or something, they will not recover in time. What do you think?
> Why do you keep using these agencies that send you unqualified candidates?
Corporate politics.
> as a series of increasingly difficult problems that build on each other.
...I mean, that's exactly how I structure these. When a candidate is stuck on the very first one of the series, though, and spends the entire interview on it... I think that's a fail. What do you think?
Asking someone to calculate the mean of a group of numbers is so basic that it's admitting that your prescreening process to that point is broken. I hope we're talking about Zoom interviews and you're not actually bringing people into a physical location before asking that question.
Assuming your process isn't broken, there's a psychological risk to asking a qualified person a question that is excruciatingly basic. If they know it's a question only a fool or liar would get wrong, then a momentary blank can lead to an anxiety spiral. I think even the first question should be plausibly challenging.
I also don't understand why you're letting someone spin out for an entire interview on a simple question. Are we talking like half an hour or more? Maybe just let them try for a couple minutes and then pull back, give them a breather if they look stressed, and gently confirm that they've done actual hands-on programming in the past. Maybe their bootcamp misled them, or their previous job was a project manager sort of thing. Bad fit, sorry we didn't catch this earlier, best of luck to you.
At the end the deliverable is a working product. A hiring manager can't determine ability to work as part of a team to deliver a commercially successful product just by looking at open source code.
Also note that in the real world, many of the best developers have nothing to show on GitHub. All of their code is proprietary closed source.
> But at the end the deliverable is a combination of documentation, code and software is it not?
No. At the end the deliverable is built based on communication between individuals on a team. If that doesn't work, it doesn't matter how good the code produced by your individuals is; it's going to be a mess.
My only counter consideration might be that one's resume which states:
"I built XYZ at $COMPANY and resulted in $Xm in revenue growth" and one could simply show the person the product or area under which professional worked.
Per your point regarding candidate pool to evaluate, would you consider it fair to say that you see the purpose of the live problems and technical projects as a means of normalizing the ground of analysis (i.e. comparing apples to apples versus apples to oranges)?
"I built XYZ at $COMPANY and resulted in $Xm in revenue growth"
What did you, specifically, do? Did you lead a team of problem-solvers, did you glue together someone else's black-box solutions, did you personally invent something radically new? I've seen people across that entire spectrum make statements such as this, and they are best suited for very very different positions.
This is absolutely a great thing to chat about during the background and past experience part of the live interview, but if I'm hiring for a hands-on position, I'd still like to see how you solve problems.
I find it funny how every year there is another "Is Rails being relevant in $YEAR" article or two posted. I love Rails and still think it's a great framework, piece of technology for building companies (but you don't need to take my word for it: https://stackshare.io/rails). However, I also worked professionally and in a hobby cadpacity with Rails and been bitten by it too.
I can say from experience Ruby is not for everyone.
Rails is a tool, and it depends on _what_ you need to do with that tool. If today I needed to build a basic web app quickly and wanted minimal cognitive overhead with a plethora of "solved problems as libraries", I'd strongly consider Rails. It's fun to work with and gives great development speed, and it's manageable architecturally for a solo development team (MVC, Service Objects, API Clients, et cetera). I think it's a useful thing to have in your back pocket if you need to get an MVP up ASAP. That being said, with regards to building a prototype ASAP the fastest track is probably going to be the stack you are most familiar.
If I were building a company, choosing Rails would be an important question to consider. Programmers who know the framework and language well can ship things quickly. So if you're a solo or main technical co-founder you can go FAST. However, building a company is more than just technology considerations. For example, with each hire you will need to consider the cost-benefit of hiring or training for familiarity with tech stack. For example, Ruby is ranked #16 on most popular technology ~6% of respondents, and split 50/50 for loved versus dreaded on the Stack Overflow Dev Survey 2022. This could present a real challenge to the business in terms of sourcing and hiring qualified folks.
If you wanted something dynamic like Rails but with a higher potential talent base, using Python, Flask and Django might work.
I’m writing one right now on building a mini trading bot platform.
It would be great to hear what you like/dislike in these types of books.
I don’t have any marketing website up at the moment but I created this mailing list if you’re interested in following the developments http://bit.ly/tradingbotplatformbook
