We place the candidate in a room with a large whiteboard for 15 minutes alone with the lights off. I then walk in with a 6 piece dresser [1] from IKEA (obviously keeping the lights out). I explain to the prospect that this particular dresser is missing one piece - BUT we need the dresser assembled then disassembled and placed back into the box [without anyone seeing]. More than HALF the candidates become violent and demand to see my github account - some even suggest I have a mental issue. I am often able to calm the candidate down - this way we can get into the REAL debate: KOPPANG vs MALMs. Any candidate caught assembling the IKEA dresser is quickly dismissed out of spite. This technique is from Boz at facebook - it is how all* senior principle engineers are screened at FB and the reason everyone codes PHP (but swears they do not).
HR has complained that my techinques are "ridiculous" or borderline illegal - but so far my successful candidates perform, tend to have a solid grasp of typescript and quickly move into senior management.
https://www.ikea.com/us/en/p/koppang-6-drawer-dresser-black-...
People want hiring processes to be somewhat consistent, and in that world it's really kind of a non-starter to replace tech screens with GitHub profile reviews.
for that matter, GitHub is useless if the projects you contribute to are on BitBucket or GitLab. that contributions graph has a lot of assumptions baked in.
Maybe the solution is for companies to hire more thorough managers who are capable of vetting a github profile to see if the candidates skills are relevant to the position, not turn the interview process into a performance.
So anything on github that I might want you to look at? I’d have to be on a three year replacement cycle, permanently, which is a hell of a lot more work than you might estimate that a reasonable github presence would entail.
As an introverted and generally very socially anxious developer, this sounds like a dream compared to a standard interview, which has always felt to me more like an interrogation and generally very aggressive and hostile. I'm confident in my skills and I can communicate well in other situations, but the typical interview environment is cripplingly stressful to me. I would love to just get through a talkative lunch instead.
Going through my GitHub account however isn't good. It's full of quick one shot things, experiments and so on, very little production ready code and not representative of anything.
My current employer doesn't have explicit rules that I'm aware of, but early on, I asked our HR person if I could work on open source outside work and they said something along the lines of "what's open source?" Which, I mean, on the one hand what do you expect from HR, but on the other hand, the entire agency is concerned with operating, maintaining, and developing a software system.
If it's not on employer-owned equipment during core working hours, then I believe it's pretty difficult for an employer to enforce that kind of thing. I don't know how important to you working at that charity was or participating in open-source now is to you, but if you're willing to take a harder line of telling rather than asking, you might find that when push comes to shove, there might not be much they can do without drastically escalating the situation (not always an organization's favorite thing to do, even if they can technically win, which they might not be able to).
Obvious disclaimer about being a non-expert on this sort of thing, but really just wanted to point out that the first answer in this situation may not actually be the final one.
Also, running side businesses was not allowed.
Of course, the normal thing to do was just ignore the rules, because most likely nobody would notice or care. I explicitly asked for permission because I wanted to see what would happen.
And its not really the "employment contract" in Anglo Saxon legal systems its pretty much assumed.
This might require engineers unionizing, but it would be a boon to the field. Patterns buried in closed source vaults would be disseminated and innovation would surge. It might usher in a golden age of software if everyone were able to freely share their intellectual ideas with their peers and not have to worry about risking their health insurance and home in the process.
That kind of interview mitigates the amount of trivia and preparation-gaming while also ensuring that the applicant can solve problems as a team and is a competent programmer. It is cheatable in that one can memorize implementations of some features, though it seems somewhat difficult and not more cheatable than just memorizing a bunch of CS trivia.
I think part of the problem is not everyone is good at giving interviews. But most software engineers can talk about their work once you get them going.
FWIW, I think white boarding interviews are pretty fun.
Ask questions about the code:
- why did you write this in this way
- explain how this works
- if you needed to add X into this, how would you do it
- are there other ways to achieve what you did here, what are the pros/cons of this?
- what would you do differently if you were to re-write this?
- are there any bugs or common issues, how do you go about diagnosing and debugging them? Could you write the code differently to be more resiliant to those issues?
Anyone who wrote that code (assuming it was relatively recently) is going to be able to talk about it sensibly, and be able to dig into the code and show how certain things are done.
It was very obviously there as bait for people like you and it was removed as soon as they took a new job. It was never used in production in its "released" form.
I had no problem with the person's abilities to code, but for reasons like this I probably wouldn't work with them again, or hire them as a eng lead or higher.
I put the anecdote up as a real-world example of one way the GGP's github reference can be faked.
You would have to dig really hard into their knowledge of the system to catch them, which you wouldn't have time to do.
For instance, I believe the issues would show up in a benchmark.
I'd bet they could also pass a whiteboard, pair-programming or take-home test too.
That they are willing to lie about it and pass off other's work as their own isn't something that you're going to identify in your typical code interview. Using interrogation tactics to try and weed out the frauds is going to be counter-productive, by driving off all the good candidates.
But I'm not sure, I've never interviewed this person.
Sprinkle in some bugs. Start with easy spelling errors and go all the way to concurrency problems.
Ask them to add a few simple features and fix any bugs they find. Bonus points if they find bugs you didn't add intentionally. Good unit tests are also a bonus.
Give them a couple days or something. Don't count off if they don't get everything done. It's better to do a few things correctly that fix everything with hacks.
Invite them to email questions/suggestions to the hiring team. This person might be on your team so it's nice to find out early if they have good ideas or they hound you with stack overflow questions all day.
I've never had this kind of interview but it sounds nice to me. It's more realistic to real daily work. You can cheat by having someone else do the work but that's always a possibility.
Whiteboardimg a solution to n=np or building full applications is crazy and not realistic. Most interviews do that yet most work is fixing bugs and adding mundane features. Why can't interviews focus on the actual skills needed?
What’s your threat model here? People making up elaborate lies about code they’ve written?
Likely people making up elaborate lies about code they didn't write. It's trivial to push code of which you are not the author.
Why would I leave a stable well paying job for a job that basically says they don't trust me enough to not fire me in two weeks?
Manipulating one or more git repos to claim it as yours then ensuring your lie is not uncovered by googling would be technically challenging enough that those who could do probably don't need to.
Without looking at the commit history, given enough time this is a challenge. I often don't recognize code I wrote myself 6 months ago.
It obviously depends on your definition of "better". And it's yet to be seen whether whiteboarding is "better" than pulling candidates out of a hat. You'll note that lots of companies that do strict whiteboard-style interviews are also extremely comfortable firing employees. Would you be "better" just hiring anyone whose resume seemed applicable, that could talk like a normal person, and then firing them if it didn't work out?