davidbanham

Don't you? Many people aren't great at record keeping, especially as they get older. It can often be difficult to figure out exactly what accounts and investments exist, let alone how to access them to clean them up.

Trawling through browser histories and correspondence is often the only way to get a reliable picture of what's going on.

I might. I think the value for me would hinge on how easy it was to contextualise the information.

Like if it was just a big list of "Stuff people have starred in Slack" I would not use it.

If it was a repository of information categorised by project and subject, maybe with a little blurb of info to give me a summary of it, then under all that a link to the source material if I still needed it, that might be compelling.

I've actually come to regard Slack Archives as a negative feature.

I work with a lot of different companies. They almost universally have Slack instances that get used for discussion. One time I was working with a client who was too tight to actually pay for their Slack instance so it had amnesia.

For a while I was really grouchy about it. Then one day I was thinking along the lines of "Ah this is such a PITA. I've just had this good discussion about these requirements in Slack but because it's not a paid instance it'll vanish in a few days. Grr I'll have to take this information and put it somewhere else. I guess I'll stick it in a design document in the project's wiki. This is such an inconven... wait. Huh. That's vastly better than leaving it floating somewhere in Slack. Oh."

And in that moment, I was enlightened. Paying for Slack actually makes it a worse tool.

I love the idea! I often open up vim to edit some stuff, save it in a temp file, then copy it. I never realised I needed a more streamlined version but after seeing this it hit me like a brick.

I don't think I need that much scaffolding, though. I just knocked this together:

    #!/bin/bash
    vim /tmp/everyvim && cat /tmp/everyvim | xclip -sel clip -i

You're completely right, Jane. I was viewing this pretty myopically from the hiring side as that's where I usually sit. Very true that candidates usually need to play somebody else's game, regardless of whether it's rigged.

Thanks! Webhooks to implement that kind of post-receive functionality are on the TODO list. If you like, get in touch at hello@takehome.io and I'll let you know once they're done.

It definitely _should_ allow you to challenge your own email address without any charge. If you're still having trouble and you'd like to test it out, please drop me a line on hello@takehome.io and we'll figure it out. The trial has worked great for everyone else so it sounds like a juicy bug I'd love to hunt if it's not working for you.

Thanks, that's a great idea. I'll add it to my burndown.

The price is per-candidate to discourage companies from sending out more challenges than they have time to thoughtfully review. The expected use case is that you interview the candidate, then if you are both still interested you issue a takehome challenge, then you have another interview to discuss the challenge submission.

If you're issuing more than 5 challenges per role you fill something somewhere has probably gone awry. $100 per role hired is no more than a rounding error.

Also, the timer starts from the first `git clone` rather than the first push.

Currently no ATS at all. I've specifically kept it focused on doing a single thing well. I appreciate the feedback, though. I'll consider incorporating something along those lines.

I think the main difference is that those sites are geared towards outputting a ranking or score of some time. Takehome is geared at giving you a way to qualitatively assess the skills of each candidate and give you something meaningful to discuss with them in a follow-up interview.

Also, all of the existing sites I've seen have one or more of the following problems:

* Make you use their editor * Make you install their software on your computer * Make you use some specific language * Make you use their set of challenges

Takehome uses nothing but git. Whatever you put in the repository and how you get it there is up to you.

That holds true both for the candidate and the challenger. Takehome encourages challengers to create their own task matching the kind of work/language/framework/etc that's relevant to their team.

Thankyou! Any person using the site to hire candidates can set whatever time limit they like.

When I'm choosing a time I'm actually less worried about the complexity of the exercise than how much of a candidate's time it's reasonable to ask for. If the challenge is too complex to be done in 40 minutes or so, I make it less complex.

I also put language in the intro text like 'If you don't end up with a complete solution in that time, that's fine, just submit it anyway. We don't expect this to be enough time to write "The Most Perfect Thing".'

If you're curious, sign up and take a look at the "Socialite" sample challenge.

What is an interview if not a test? The code challenge portion of an interview process is a test that you've been studying for your entire career.

As for fairness, I'd argue that timing it is the only way to ensure it. This way you know that the playing field is level between you and the other candidates applying for the role.

To fun, I'd say that the least fun thing I can think of in this context is spending days wondering whether I had "done enough yet" in order to make my submission stand out ahead of the other applicants. Much more fun to know that as soon as that clock ticks over, what's done is done and I can get on with my life for better or worse.

Hey, thanks for the feedback.

The idea is that the candidate knows they can do the best they can within the time limit, and then it's done. No agonizing over whether it's good enough or they should spend another few hours. No imagining how many hours and days other candidates for the same role might be putting in, wondering if they're going to stack up.

I've used this approach with around 100 candidates hiring for various roles in my own business and for clients. The response I've gotten from candidates has been overwhelmingly positive.

The problem I have with the traditional "don't spend more than about X time" approach is that it's not a level playing field. The responses to a challenge exist in relative terms, not absolute. It doesn't matter whether your response was great or not. It matters whether your response was in the top 5 of all the other candidates responding. It follows that you probably need to spend at least as much time, if not more, than all the other applicants for the role. How much time the other candidates _might_ be spending is basically unbounded, leading candidates to spend vastly too much time working on a challenge and then lying about it.

If the candidate screws up a timed challenge that's also totally okay. It'll be a great conversation to have in the follow-up interview. "I started down this road, but if I was doing it again I'd do X, Y and Z because of A, B and C."

Incidentally, I'd suggest that half a day is way too long. Especially if that half a day isn't actually enforced. When I'm hiring I usually set challenges of about 40 minutes, an hour and a half max. I'm not looking for a product that's ready to ship to production. I'm after a sense of whether the candidate can actually interpret a problem then string some code together, and something meaningful we can discuss in the next interview.

Thanks for the feedback! I appreciate your perspective on time limits.

I don't have that feature, because I would argue that a problem you attack in three 1 hour stints across a span of 72 hours is a 72 hour problem.

Writing software is so much more than just typing. I tend to do my best coding in the shower or driving, nowhere near a computer. As soon as the challenge has been loaded into your brain, the work starts and the timer starts. How much of that time you spend in front of the keyboard is up to you.

Incidentally, I also think that a time limit of longer than an hour is probably too long. Uninterrupted multi-hour blocks are pretty hard to come by. Even if the time limit given isn't enough time for you to complete a perfect, working solution to the problem, it should be enough time for you to do enough work that we've got something meaty to talk about in the next interview.

That fits exactly with my method and thus the ethos of https://takehome.io

I don't mean to shill, but I think it'll be a great fit for you.

Thank-you!

My contention is that it doesn't matter if the time limit is unrealistic (within reason) so long as it's consistent.

ie: the challenge is not "Show me the best solution to this problem" but rather "Show me the best solution to this problem that you can achieve within an hour".

As long as everyone is under the same conditions, the playing field is level.

It's part of a holistic approach, too. The coding challenge is not the only part of the interview process. I suggest that there be an initial interview to assess experience, fit, explain the job, etc. Then if everyone is still interested, the coding challenge. The candidate's response to the challenge then forms the basis for a discussion in another, technically focused interview.

It's not about saying "You gave the wrong answer" but "Talk me through why you solved it this way" and "If this criteria in the challenge changed, tell me about how that might change your response"

The Codility and Hackerrank style problems are okay, but I don't like how constrained they are. I also think it's pointless having someone outside your organisation grade the results. What matters is not having a candidate who is "the best hacker" but having someone who fits what you need. If your team values robustness and debuggability above all else, you _don't_ want someone who can punch out 3 kinda-right prototypes before lunch. If you're an ideation agency, the inverse is true.

That's why takehome encourages companies to create and administer their own challenges rather than the samples. They should fit the kinds of problems your organisation faces, not contrived ones.

That inherently biases the interview process away from people that have additional commitments in life. You're going to end up preferentially treating those that are currently unemployed versus people that have jobs, for example.

Also, you're likely to be homogenizing your applicant base. Expect to see many more young people and recent grads versus people with kids.

I completely agree with your criticism but I disagree with your conclusion.

The fact that some applicants will spend ridiculous amounts of time on a challenge is a critical flaw. It doesn't mean that take-home challenges are worthless, though. It just means they need a functional mechanism to enforce time limits equally on all candidates.

Challenges administered via pair programming can be useful if your team/company operates predominantly in that mode. If most of your actual day-to-day work is done individually, though, I think your challenge should mirror that reality.

Interviewing all candidates in a pair programming setting risks weeding out all the people who are great at the job, but get anxious in a paired interview scenario.

A job interview is already pretty stressful and anxiety inducing. Adding somebody looking over your shoulder while you type into that mix can be really rough on some people.

I think the only humane way to administer a take-home coding challenge is with an enforced time limit. That way everyone is on a level playing field and you're not advantaging those candidates that happen to have oodles of free time.

The author raises that point:

https://www.fullstackinterviewing.com/2018/02/02/the-ultimat...

But takes the wrong view on it in my opinion. The answer simply can't be "Just spend as long as it takes".

That point is the thing that led me to build a tool that enforces time limits on challenges via a custom git server. I used it to interview around 100 candidates at a company I was running at the time and it was an excellent approach.

I've since productised it as https://takehome.io/

If you want the benefits that take-home coding challenges can bring to your hiring process, but are concerned about treating your candidates humanely, I urge you to check it out.

In my experience, documentation stored in source control alongside the code gets updated and maintained. Documentation stored in a wiki is left to rot.

It would destroy the issuing company in a similar way that Tether refusing to pay out would destroy them. The analogy holds.

I left the industry because of the entitled behaviour of the community.

It's different (better?) in that it doesn't rely on you remembering to actually burn that data, then store it safely. It comes with an app you can run on your phone to upload all your photos immediately, for instance. It has importers to archive all your tweets automatically, for example. It allows you to outsource the task of "Keep this blu-ray safe" to a cloud provider (or a friend) while encrypting your data to keep it private.

As much as possible the design attempts to be agnostic about where the stuff is actually stored. Usually you want to be storing your stuff in multiple different places. Among others, Perkeep lets you choose one or more (or all) of the following:

Your own hard drive local to the Perkeep instance Your own hard drive local to another Perkeep instance you run Your friend's hard drive local to another Perkeep instance _they_ run with encryption to ensure privacy A removable hard drive you can periodically sync to and from A cloud service like S3, etc

Just saying to yourself "I save all my stuff on two drives" is a system. It's just kind of a crappy one that's really prone to failure.

The video demo on the front page is a great place to get an overview of what it's all about.

https://www.youtube.com/watch?v=8Dk2iVlc67M

Looks like there's been some nice progress since I last looked at Camlistore! The importers from cloud services like Twitter look really interesting.

The way in which the issue was handled seems important to me. He didn't make a scene in front of the whole team, which could have been humiliating to the person who reported the intimidation. He dealt with it privately, and then returned later to notify the reporter that it had been done and what the outcome was. Thus preserving dignity for all involved while hopefully making a meaningful impact on the culture/behavior.

As a man witnessing harassment I have felt paralysed by not knowing whether calling the behaviour out in the moment would make things worse. Whether my intervention would be appreciated or looked on by the woman as bullshit white-knighting. I think this anecdote lays out a more useful path that can be emulated.