I've even offered to show them my current projects in lieu of work samples, and no go. Baffling.
I'd be much more interested in finding out if we would have a cultural fit. You can teach certain skills, but if your personality doesn't fit the culture it's going to be a bad experience for everybody.
I mean knowing the theory is a nice to have but I don't remember last time I used it on my daily job, especially after 10 years of experience.
Them: "We have to be fair to all candidates, so you need to implement the interview project like everyone else."
I've never had an employer short-circuit an interview process (as in skip some/all of the BS tech screening) based on having actual, real work samples available for review.
https://hashrocket.com/ had a pretty extreme interview where they flew me out to Florida to pair-program with them for a week. It was a really pleasant experience. Every day I would pair-program with someone new on production code. By the end of the week I knew exactly if it was the job I was looking for. (Great group of people though and wish I'd known how to keep in contact with people professionally in my early 20s)
So unless everyone can afford to do that, you have to extrapolate from far more limited data.
I wish I could add more to my anecdote, like how I solved this problem, but I avoided it entirely by taking a job offer from a different company the next day.
Oh, that's really no problem at all! Not everyone can just be at home in front of a computer all day, both at home and work, coding all day. What kind of a society would that lead to, haha. Anyway thanks for coming in, we'll be in touch.
Funnily enough, nobody has asked to see it yet. They all want you to have side projects, but they don't actually want you to drone on about them for an hour. All this time I could have just been saying "Yes, let's talk about the intricacies of accounting for an hour, it'll be great" and passing that part of the interview through sheer aversive stimulus.
Whether they directly used my solution or gave that problem to several interviewees and picked the implementation they liked best I couldn't know. But I certainly felt used. There's a certain popular piece of software I refuse to use to this day because of my experience interviewing with them (fortunately, they have competition now).
Eventually you get to a point where your gut will tell you whether an 'interview project' is a toy problem or something that might actually be useful.
That said, do be sure it's your code... pretty much by definition, if you accomplished it during an interview, they could accomplish it in the same or less time themselves freshly and legally... for all you know, they'd already written it, just hadn't deployed it yet, and were using it as an interview question precisely because they had just written it themselves and it was fresh on their minds. Given the prevalence of NIH syndrome, this would even strike me as the most likely explanation unless you have some sort of really solid proof it's your code... generally, even when a programmer should take somebody else's two or three hour work they'd rather do it themselves!
What I prefer to do is ask them to show me some example code they think is "good" (ideally their own, but perhaps from an open source project), and some that is "bad" (ditto), and write a paragraph or two on _why_.
Colleagues prefer to ask people to do coding exercises, and that's fine, I won't criticise, I've done it before, but I hate the fact we are asking people to do toy problems that don't represent real World problems.
My favourite process that I don't get to do much now (I have to conform to somebody else's policies these days), is just to sit and talk through a candidate's favourite project or problem.
Why did they choose that problem? What tools did they use? Did they consider alternatives? If it was a personal project did they write tests, and why/why not? If it was something they were paid to do, how did they input vs other people, etc.? Get a sense of them, try and build some empathy for what makes them excited.
Get somebody in a room with a coffee and just listen to what makes them not shut up about some code they worked on. It can't be the be-all and end-all, but it's better than asking for another todo list app.
And then I also like to do an architectural thinking exercise. "Let's pretend we're building [well known piece of software] from scratch. What do we need to build, what do we need to think about?". Go through it, you draw their idea on the whiteboard, not them. Ask which technologies they know about for each piece. Find the edge of their comfort zone.
All more useful to me and my assessment of somebody than asking them why manhole covers are the shape they are, how many windows there are in a nearby city or asking them to build a scaffold generated app that nobody would ever use.
> Get somebody in a room with a coffee and just listen to what makes them not shut up about some code they worked on. It can't be the be-all and end-all, but it's better than asking for another todo list app.
> And then I also like to do an architectural thinking exercise. "Let's pretend we're building [well known piece of software] from scratch. What do we need to build, what do we need to think about?". Go through it, you draw their idea on the whiteboard, not them. Ask which technologies they know about for each piece. Find the edge of their comfort zone.
I've seen your interviewing approach in action and it works brilliantly. This is pretty much a step-by-step of the way my last hiring manager interviewed and he never failed to build very strong dev teams.
If a company asks cookie-cutter questions and gives out cookie-cutter exercises to complete, then they shouldn't be surprised when they also make a number of bad hires that were just developers that knew how to pass these "tests".
On the other hand, as you say, if you sit down, ask them to talk about their experience, and shut up and listen, you're going to learn really quick if they are a BS artist or actually know what they're doing.
I also really like your idea of working through problems with the interviewer. I imagine it gives the interviewer some pretty important insight into how well the person breaks down a complex task into some semblance of an architecture, as well as how good they are at keeping such an architecture clean and simple.
For lower levels such work should be compensated, the best solution there is to do some actual work, get paid for it and then the company can make up its collective mind if they want to hire the candidate or not.
I'd rather do it at home.
The part I have the major problem with is the average length. Peak was 8 hours, I just chuckled and said thanks but no thanks.
2 hours? Sure. No problem. Even 3 hours is fine.
Very few would be willing to commit internal time to 100 onsite interviews of 8 hours each.
So the latter sends a signal to the potential employee that their time is at least as valuable to the company as the time of the interviewer(s)
There's no substitute for actually working with someone.
A 5 hour homework assignment costs the company nearly nothing, but it still costs me 5 hours. This means the company has no incentive not to waste my time.
I wouldnt do this for the same reason i worked at a gas station over taking an unpaid internship:
If the company isnt willing to make some investment in you, they arnt worth investing your time into.
Would you prefer Phone Screen +:
A) FANG/Valley style interviews multiple rounds of leetcode algorithm/data structure style questions and some whiteboard design/architecture.
B) Pair Programming. A few rounds of pairing on a problems to see actual code. Maybe some lightweight whiteboard design/architecture.
C) Take home challenge/assignment that you work on/add features to/add tests/talk about during your onsite.
*excuse my language, but it is the most accurate description I could come up with.
i would definitely be looking for employment elsewhere if i my co-workers were so unpleasant that i thought they'd turn every pairing session into a pissing contest (and i say that as someone who generally prefers solo programming as far as immediate enjoyment goes, but who finds that pairing is often useful and/or necessary).
Cheaper than a bad hire, stops you missing out on good hires who think "fuck that".
Also there is usually more than one person sitting with the interviewee when they come in, so the company time spent is multiplied at that stage.
Does it? If I have a developer job then I'm paid well and don't really care about the money which I have enough of, I care about the time which I have very little of.
If you're in the top 0.01% of companies to work for (and the applicant knows that) then it's probably a worthwhile time investment, but for the other 99.99% it's a waste.
These tests are typically a pre-interview step and they don't really work well for much apart from that. So at this point I'm not interviewing with the company and all I know is that they have an interesting job ad. Considering how far from reality job ads can be I'm not going to waste hours based on one.
we also ask for a presentation on prior work or a prior project, we do some architecture whiteboarding, and we have talkier personnel type parts. but currently, the hour and change pairing exercise is the only programming exercise, and we were happy enough with the results last summer that we're doing it again for an upcoming round of interviews. our setup was a PM, a tech lead, and a "driver" (the person at the keyboard, which is what i was in the exercise). interviewee is the "navigator" (and by not having to type, we get rid of some of the stage fright for syntax errors and such, and just get to see their thought process since it's a pretty compressed timeframe). best microcosm of real work i've seen. one important thing is to give the same exercise each time (one possible risk in our case was that we gave the candidate 3 possible things to choose from, but settling on what we thought was the best choice was part of the test, and all the candidates ended up passing that part, so we never had to compare WIP from two different coding exercises).
apologies for rambling or repetition, dashing this off before i go to bed. but i'm a big fan of this interview approach, and i think it's probably the best thing we've hit on so far in this field, for positions where that would be a reasonable microcosm of what day-to-day work is like. i think it's much better than making someone code on a whiteboard, or giving them a take home or solo exercise, because you get so much more info about other things besides how well they can bang out a single well spec'ed piece of code.
The idea of using a whiteboard to do software engineering is like asking a cellist to use writing to play Bach.
In one instance, I submitted an "exercise", which I spent ~six hours on, one week ago and haven't heard _anything_ back -- not even a confirmation that the submission was successful. I had been on the fence about following up, but fuck that, I'm going to do it right now. Thanks for the nudge. ;)
It's almost as if they were trying to get me to build a whole feature for them for free, as it involved a complex UI that I knew they wanted to add into the Android app.
Maybe companies that want that level of work done in their code "tests" could offer a small amount of compensation. I had already been screened on the phone, so they knew I wasn't a time waster.