kero,

Is that 3 full days of interviews?

The perspective I have is that unless you are going to be paying someone 30-40%+ more than they are currently making, you should plan your interview process in a way that the candidates can be doing it with 3-4 other companies simultaneously.

Even then I don't think I'd do it. It's a sign of a severely diseased company

Or like, if they already have a job. I mean christ, if they pay me I still have to take 3 vacation days.

Yea I mean I think hiring is super broken, and eventually I want to start a company to connect the world with jobs that are rewarding, enjoyable, and help make the world a more efficient place, so its something I'm super passionate about.

But what really strikes me is how completely absurd these requirements on time are. I think companies should ideally be trying to hire passive and semi-passive candidates, because those are typically going to be the best ones.

If your hiring process can only accommodate people who have unlimited free time, then you are doing it very wrong.

Great employees should be throwing up all kinds of warning signs to their employer by the time they are with you for the 3rd day, and if they decide to not join, they just signaled to their current employer they are on the way out.

With an eye to the future and how diseased the hiring process is, and with how little I enjoyed programming for a job, I think I'm moving on from this as a possible career choice.

There's a security boot camp in the area that I've been looking at. Requires programming and network knowledge, both of which I have. And it's a topic I've been interested in forever, whereas I could never find much motivation to do actual coding, so I feel like that'll help out a lot. Will still get to code but won't be the main focus, which I think I'll like. I enjoy coding, but I don't enjoy doing nothing but coding.

Three days of interviews is "better" (if I'm the candidate) than a three-day project...it's more of a commitment on the part of the interviewing company (since they are assigning people to talk or listen to you). There's almost no circumstance where doing three days of work for someone makes sense. But three full days is a lot no matter what :-)

Two full days doesn't seem that unusual though it might be broken up into parts. Often some of that time is after both sides expect there to be an offer and there's some calibration going on--for both sides to show some additional value to get better compensation or to help close the deal on recruitment.

But the job hunt process is pretty costly/time-consuming. I understand why great people are attracted to work with former colleagues: their value (maybe hard to establish in an interview) is already known, and they have more flexibility with the interview timeline.

Small sample size. Didn't you take a ****ty code monkey job that everybody warned you would be terrible? And daveT is a freak and very weird dude, so his job-hunting lolz aren't really relevant.

Sample size? I've been reading horror stories of code interviews for like two years.

I didn't expect the job to be great, but I can ignore the parts that I don't think are relevant to other jobs.

I've definitely thought this before but I'm not sure I've ever posted it.

Noodle it's pretty clear you don't have a clue what you want to be doing. You appear to be bouncing endlessly from one thing to the next. Pick something, stick with it long enough to get to something better and eventually you'll be where you want to be.

Your code monkey job sucks as we all knew it would. Use it to get a better job not just abandon the experience entirely and try something else.

For most people, being interviewed is only around 0.1-0.5% of their career. Probably more interesting to think about whether you enjoy the 99+%.

This.

Presumably you wouldn't be tasked with interviewing junior level candidates?

Super duper this. You should use your first experience to help you ask the right questions in a future job interview. For example, you've identified that your current employer does a, b, and c terribly and can objectively say what terribly means. At future job interviews, you can reflect on this experience to find out how that company handles a, b, and c and know based on their answers if its going to be another ****storm or paradise.

Does anyone use git hooks? Was just reading about those today and they sound freaking awesome. Seems like a great way to enforce coding guidelines that your team talks about and agrees to but nobody embraces it. More specifically, pre-commit git hooks.

The other thing is when people talk about a full-day interview, typically it's more like 4-5 hours, which is considerably shorter than an actual full day of work. And if you have three rounds of in-person interviews, it's usually the case that at least one or two of them are no more than an hour or so. A three-day project here sounds like actual 3 physical days, which is likely more than 3 normal days of work.

Junior candidates is a thing? I don't see it posted. Most companies hire people who can jump in and do things, finish tickets, etc, without too much ramp up. AFAIK no one hires to train people in things any more.

But people misunderstand the reason why it's that way. It's simple - there are very few formal barriers, it pays pretty well and performance isn't immediately quantifiable so there are always too many applicants and it's very easy for there to be disagreement on what should be the hiring criteria. If you want to avoid this, you need to find a career path that pays less and/or there are agreed-upon performance standards or qualifications for the job.

This would be a terrible recruiting strategy unless you're talking about something like JavaScript or C - not knowing JavaScript probably means you haven't done any web front-end work and not knowing C probably means you haven't done any low-level programming. But even in that case, it's not the language that's the deal-breaker, but what it implies about the candidate's experience. For most other languages like Java, Python, Ruby, C#, PHP, etc, unless you have specific needs for a technology specialist, the language itself is just not that important. Unless your tech stack is extremely standard and you don't have much of a code base, almost all the real work in coming up to speed is going to involve understanding internal technologies, code bases, architecture, product, that kind of stuff.

We do, but devops takes care of all that for us.

To qualify this, I guess I'm really just talking about software product companies for whom it's much more about building products - it probably makes way more sense or dev shops and consulting companies to hire for technical expertise in specific technologies.

Amazon, Google, Microsoft. Big companies like those hire new grads who most likely don't know anything about what stack they will be jumping in. They test on algorithms and if you are good enough on that they will train you on the rest. Pretty standard.

Not just big companies either - lots and lots of small companies also hire and train new grads.

Btw I think junior vs senior and no ramp-up vs requiring significant ramp up before being productive aren't strongly related. Once your hiring standards are high enough that junior developers are required to have a strong background, all they really need to learn is internal proprietary tech stack before they can become productive. Which is the same learning curve as senior devs, but the nature of the work they will be doing often requires that they spend more time learning before they can be productive.

I've used them, mostly for running pep8 checking and stuff like that. They're OK if a little annoying.

I have probably had at least 10 real full day, 8+ hour interviews. They are draining. They were not that common in my experience until about 2005 or so. Prior to that it was often like 2 hours, maybe 3 at most. I've had interviews that were under an hour (back in 1999-2000, but that's sort of another story).

Many places that are hiring a senior person would hire a junior person if they found one. I was talking to my boss the other day and he said that basically no one ever applies for jobs via the website, almost all of it comes from word of mouth and recruiters. I wonder if maybe more senior people are more likely to go straight to recruiters?

When I worked at mapmyfitness/underarmour, we hired a lot of junior people. Some of them were really great too. At the job before that we did a lot of (paid) intern-to-junior dev stuff.

Didn't know about git hooks before. After reading about them they seem good.

We use github integrations to do the stuff you're talking about. Upon opening a pull request a few things happen:

Code climate runs to make sure quality is increasing or staying at the same level

Hound runs to enforce the style guide

And circleci runs out test suite

Seems like this PR flow is better than git hooks but git hooks would definitely be better than nothing

You posted something along those lines.

The book "So Good They Can't Ignore You" which I've mentioned before would be good for Noodle.

We use them heavily.