No one enjoys whiteboard interviews but it's not clear that these companies have better alternatives. Many of them do take home projects which are time consuming. I'd prefer the employer look at my GitHub profile as there's plenty of code there already. Furthermore, I'm not a fan of "interviews" in general, I find that more information is transmitted by eating lunch with the team and talking like normal people.
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.
Note that upper management is also interviewed in such a fashion, except with night vision cameras and the entire board crammed into a tiny security cupboard near the elevators. Any candidate caught trying to hide the existence of the IKEA dresser entirely is immediately hired once they have successfully gaslighted the interviewer.
Here's the thing though. It's a lot more effort to look through projects on GitHub and evaluate them. And even if you can, you then have to figure out how to cross compare that and set a consistent bar vs people who you interview because they don't have a GitHub presence.
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.
yup. and GitHub's useless for value adds like management, marketing, recruiting, or product skills.
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.
It's so backward to see companies shift to these abstracted whiteboard or homework assignments as some sort of standard, considering standardized testing is now falling out of favor in higher education as it is rarely indicative of actual potential success. It strikes me as lazy, just following a trend unrooted in any empirical data.
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.
There is not that much code I wrote three, four years ago that I’m still proud of. I figured that would get better with age but it’s only by degrees, and at any rate it may indicate that I’m getting soft rather than better.
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.
I think it is also hard to compare different candidates this way, even assuming they both have a similar level of commitment on GitHub. A take home exercise at least allows them to compare the same thing
> I find that more information is transmitted by eating lunch with the team and talking like normal people.
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.
I like whiteboards, if there is an interesting problem.
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.
I'd much rather do a take-home project at my own pace funded by the company, seeing as how my personal GitHub is a barren wasteland (well...it was before I started working for an OSS company).
In the future, when looking at github becomes a standard hiring practice, companies will start going full closed source so that their talent can’t jump ship.
My former employer, a Fortune 500 company, wouldn't let me volunteer for a globally recognized charity because the boilerplate agreement the charity required volunteers sign, stated that IP created as a volunteer belonged to them, and my employer considered that everything within or outside work hours was theirs. Not that I was volunteering as a programmer anyway.
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.
I was under the impression that this kind of interpretation of employment contracts was more or less illegal (or, at the very least, unenforceable) in many states (I'm assuming you're US, programming in Fortune 500, so maybe not applicable?). Sort of fits into the same kind vein as certain non-compete clauses, where companies put them in, but they'd be tossed out pretty quickly in court should things actually reach that point.
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.
My recollection is there was a compulsory agreement saying you would not do anything of a nature related to your work, or if you did, allow the company to decide if they wanted to claim it.
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.
This is how I get over that hump. Not only do I not work on anything related to my day job, I mostly build things in my free time that aren't really useful to anyone but myself. Sure my company may be able to claim ownership of my Sean Connery themed programming language but will they? What on earth do they plan to do with it?
They are happy that you can't leave, because you have nothing to legally show to other interviewers and no other prospective project in your drawer. That's not a good position to be in.
I would love to see a push for more intellectual ownership over the code you contribute to your employer. I should be able to take any snippet I wrote and reuse it with impunity.
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.
Recurse Center has a pretty nice model where they give you a part of a program (small) to bring ahead of time (or you can pick any program you've written) and the interview is going through the code and adding a feature or two.
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.
The Recurse Center is a retreat that you attend with other like-minded programmers. I recommend it if you are interested deepening your experience as a programmer, by working on personal projects as part of a helpful community. There is a selection process as mentioned above, but it isn't onerous.
Well put. The one time i expressed interest but reluctance at leaving my previous job, I was invited on a coffee and chat with a couple lead engineers to help decide. We got along well, talked about technical things, swapped stories about problems solved. Afterwards, i got the impression going through the technical interview would be more of a formality.
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.
Code often doesn't stand alone, there's going to be a commit history, there's often going to be comments and issues on other projects.
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.
I had a former coworker re-write a library we had open sourced as their own. They had used the original version at work so knew it well, knew the internals by asking lots of questions while working for performance reasons. They renamed things and changed pointers around to their preference. They did this right before they left and had it on github as their work. They could meet all of your questions. They didn't really write the code, but it was MIT, what can you do.
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.
One question is, if someone is doing elaborate deceptive work like this, gets hired and has no problems performing the job, does it actually matter? Some people mostly or entirely code at work, so this looks like a legitimate way to get a "good" project in GitHub that he knew well. It sucks that it's deceptive (which could be a major red flag), but it's also clear enough that he understood a large codebase well enough to explain it and modify and/or refactor it, which is honestly the majority of a SWE job. A lot of people are concerned about the "purity" of how someone solves an interview challenge, and outside of potential ethical red flags, people that "cheat" the system are often putting in a lot of work, and are as likely as anyone else to be capable of doing the work.
No if they had no problems performing on the job then no it's not an issue. Maybe they learned and this provided a good reset for them. Maybe they didn't and similar issues will crop up.
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 don't see a solution for this. What you're describing is someone who's clearly good enough to take a project and rewrite it, and still be able to talk in detail about the code.
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.
I don't disagree. You might see some of the issues with this candidate on what they choose to highlight as their career successes, I've definitely caught dishonest people, or people I wouldn't work with via soft questions.
But I'm not sure, I've never interviewed this person.
Have the interviewee submit repos in which they're the only contributor? But, uh, with a take home project, you _really_ don't know that they wrote the code, either...
Do a take-home project but don't make them write from scratch. Give them a mostly working starter application.
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.
This sounds sadistic to me. I've spent a long time on dumb typos, which become a lot harder to spot when you are stressed and on a deadline. Chances are if you are applying for work, you are probably stressed about not having a job.
You've completely missed my point. It's not about being perfect. I want to work with people who leave code better than they found it but I can't expect perfection. I don't care if they can't find all the typos. I'm sure most software has typos.
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?
Which is why the interviewer should ask specific and thoughtful questions about the project, so they can gauge the candidate's level of understanding. This concern could also be addressed by introducing a trial period.
> Why would I leave a stable well paying job
Well, why are you doing that in the first place? Maybe the new opportunity is worth it or the current one is so bad that it's worth it.
At least they’re honest about it. Unless you’ve got some kind of contract in place (or live somewhere where this is prohibited by law) your current employer could fire you in 2 weeks if they didn’t like your performance, too. They could do it this afternoon even.
I have heard of someone trying and pass off repos forked into their github account as their own work. A quick google or even just looking at the commit history in their fork made it obvious it wasnt true.
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.
I would assume the best, then in a week when it is clear that they faked their way in you can just lay them off. If they faked their way in but are a great member of the team going forward and contributing to projects, do you really care as a manager?
I think discussing the projects would be a better solution. The interviewer looks over his projects and asks questions about them, the applicant explains his thought process behind the decisions made.
> but it's not clear that these companies have better alternatives.
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?
Different things work for different people, personally white boarding is my favorite. I think the best would be to offer the candidate options. Let them come in for the culture fit portion of the interview, at the end present them a problem and let them choose if they prefer white boarding, pair programming, or take home and submit by the end of the day.
