For people like this, though, I’ve seen many use it as an opportunity to work on something they’ve been wanting to for a while and never had the time! A Hello World in a new language, merging in PRs on an old repo, writing a script to automate something or even a take home coding exam for another company.
One that we tend to do a lot is creating an image gallery using Flickr or Unsplashed's API. It's vague enough that people can take it in whatever direction they want, and simple enough that you can get pretty far in an hour.
I ask people to send me code they've written via email or links to projects and go through that.
I have a gigantic open-source portfolio[0]. I also go to great lengths to make sure that I’m a “known quantity” (like posting frequent exposition on fora like this one). I don’t feel that I have anything to hide. Everyone that has worked with me has found the experience enormously fulfilling.
It’s been quite jarring to see this ignored and treated with disbelief. That’s pretty much exactly the opposite reaction from the one that I would have, but I guess I’m out of touch with the way things are done, these days. I even talked to someone who told me about a friend that had invented some kind of machine learning candidate evaluation system, and relied on that, as opposed to human vetting.
One of my goals is to discourage people that wouldn’t want to work with me. I was a hiring manager for a fairly high-functioning, high-stakes team, and am quite aware of the value of making good hiring choices, which go well beyond simple expertise. Team dynamics are also very important.
I feel that getting a job as a result of misrepresentation is a big mistake, and a recipe for misery. So I don't hide my age, don’t pad my résumé, and make every effort to be as open as possible. If you don't want to work with me; fine. Let's not waste each others' time.
I have always sought to make it easy for people to figure me out. Since I live a fairly good life, and know my way around the playground, I feel that I'm a pretty good bet, but I have no problems if others think otherwise.
One of my favorite Twain quotes is "Let us so live that when we come to die, even the undertaker will be sorry."
I think I just threw up in my mouth a little.
Literally everyone? Ok :)
As such, I won't post stuff like you just did. It's uncouth and unprofessional. I consider this a professional environment. If you choose to look at it as a personal entertainment medium, then knock yourself out.
I'm a reformed troll. I used to be a right bastard. A great deal of my approach, these days, is an act of atonement. In fact, a great deal of my personal philosophy is based upon becoming a much more productive member of society, than I have been in the past.
I'm every bit as cynical as the next chap; more so, I'll bet. I regularly deal with some truly scary people, in my personal work on NPO stuff. I doubt there's a thing that you could say that would shock me.
It's also quite possible for very good people to exist in this world. I try to be one, myself. I know of many, many others. They are my heroes, and my models.
Please don't make the error of mistaking optimism, kindness, or politeness for weakness or stupidity. It's my experience that this can lead to...costly mistakes.
My post had nothing to do with any of this.
All I was pointing out was that being excessively boastful and claiming that everyone, without exception, finds working with you "enormously fulfilling" is just unbecoming. I feel like many will find that distasteful and you should leave other people to rate their interactions with you. I doubt there's a single person in the world who has a 100% success rate with regards to positive social/professional experiences with others...
I could have definitely worded it more politely and honestly if this account was tied to my personal name I probably would have worded it more politely, so you've got me there :)
I posted incorrectly. It is not 100% universal, but I'll bet it's a lot more than you might think. I've spent the last 40 years, getting along with some of the most difficult people on Earth. In fact, many of them are ones with a history of violence, and it's always a good idea to be polite in that kind of company.
Geeks are easy, after that.
That said, I suspect that many companies have been exploring this. It's pretty obvious that many places are already using AS (Artificial Stupidity) systems to triage applicants.
My guess is most people are covered by some sort of IP clause for their main work, and the most visible OSS projects are still not run by very many people, so most devs are not gonna be able to show you much.
Rather, the engineers on the team are usually building something new, and figuring out how to accomplish it is their responsibility. This way of interviewing mimics that a lot closer.
If someone can't explain to me a project they're working on, then they probably won't be able to do the same while we're working together. And that's just as important of a skill as writing code.
If I'm expecting interviewees (who are nervous!) to learn and understand my codebase/problem, why can't I do the same for theirs?
Or they tune out. Or they dismiss any variation as "wrong" rather than giving it a chance.
What happens in practice is the interviewer compares candidates answers to each other, not to his/her own way of solving it. It doesn't matter what whether the solution is "obvious" to the interviewer. If I hired someone who only did OK on this question and they ended up being a great engineer (and that happened multiple times) that lowers the bar for the test (or tells me it's not a very good test etc)
Whether it works out to be a harder or easier interview over time because of these changes probably depends on the individual interviewer.
I think that's _ideally_ what happens in practice. But as sibling comments mention, is that what happens in practice?
Interview fatigue is very real. Many interviewers are not positively incentivized to put in the substantial amount of effort to conduct a quality interview. It's something that is simply thrown on top of their usual workload. Come promotion time, there's no reward for doing it well. But, there is punishment for noticeably "screwing it up". Often, that means that interviewers put in the bare minimum effort with interviewing (as with other tasks) to not get punished.
I've seen competent leaders avoid this in the past by emphasizing that interviewing is the most highly leveraged thing you can do for your organization and your own career, because you are step-function increasing the effectiveness and capability of your own team if you do it right. But in order for that to happen, there needs to be a real culture of working as a team and not just a disembodied group of ICs: a culture which rewards increasing the effectiveness of the team (instead of merely focusing on ones own tasks) and doesn't just pay lip service to it. It's tricky. But I think the subthread GP's approach is a clever and creative kind of a lateral thinking that shows how to do just that.
do you (or others on team) ever make suggestions on how the code should be written? I think this would be an interesting way to pre-teach the hire on how you like things structured.
on edit - I guess since you ask them questions that implies making suggestions as well, but just wondering how it works.
We sometimes might make suggestions, but rarely for the sake of code quality. We'll once in a while ask for something unique just to get them out of a rut, and see if they can improvise. Otherwise, we're here to learn and listen, not teach :)
I signal a lot of things like testing by asking them. It gives room for the candidate to ask those sorts of questions back about how we do things.
Imagine you’re taking a class on a topic you don’t know. You can tell pretty quickly from how the instructor talks and explains something if they know what they’re talking about. It’s very similar! I’ve certainly interviewed people much more skilled than me in languages I’ve never used, and still got a pretty great sense of their expertise.
It’s an advantage we have as a small company! We can rate people based on whatever criteria gives them the best chance, and we can find a ton of great candidates that maybe wouldn’t make it through a traditional hiring interview at a larger company.
Like YC said, "Do things that don't scale."
If you asked me to work on something, it would be a toy project. Because I can't contribute to open source and if I build anything substantial it will be taken from me.
You shouldn't punish people in this situation. It's extremely common, maybe even the majority of coders outside California.
That being said, I've interviewed hundreds of candidates over the past 5 years, and not a single one has cited IP assignment as a hesitation.
of course they do, you're a knowledge worker for them. they need to own what you create.
a standard phrasing includes "related to the employer's business". see for yourself: https://www.lawinsider.com/clause/intellectual-property-assi...
"during the period of his employment relating to the business of the Company". If your contract doesn't have the words "relating to the business of the Company" then add those words in yourself, signing and dating the change and telling the company of your change.
you're not their slave you know. they don't get stuff you make in your free time. however, not replicating the company's business is a fair requirement, since they might share enough information with you to do just that. I think it's fair for them to get everything related to their business.
It's a great proxy for empathy and understanding. If you're curious, it means you want to learn the why behind why other people do things.
"Less certainty, more inquiry." --Erik Seidel
If we sense they're doing something they've rehearsed a bit too much, we might push them to do it a bit differently. "What if you tried to do this by _____", just to make sure they can think on their feet.
Honestly, though, the best candidates for us are the ones who wouldn't try to game it. They hear the prompt, and are just so excited to show and talk about a project they're building that it's not a problem!
By letting the interviewee pick, we're letting them decide which of their "superpowers" to show off. If they can explain why they chose to do something the way they're doing it, and show they understand the tradeoffs, that's good enough for me.
It sounds like you're putting that system of bias under the rug.
It could be adding a feature to a side project, starting something new, or contributing to open source. (Or, we have some stock ideas if people need inspiration.) Rather than asking them to solve a problem they had never heard of before or use a codebase they're not familiar with, I get so much more out of watching them work in their own environment.
I can ask them questions about why they're doing something, and they tend to have much more detailed answers because they've been thinking about it for weeks. They're solving a problem they care about in a codebase they know, which mimics how working with them will be a few months in.
We can talk about tradeoffs and design decision, and I get a real sense for how they think. Plus, I've found most people are so much more comfortable and excited.
(If you're interested, I wrote a blog post about all the ways I've designed how we interview, to give everyone the chance to show off the best version of themselves: https://blog.readme.com/designing-a-candidate-focused-interv... And of course, I'm hiring!)