> I hated the idea that schmoozing outperforms merit, but it's absolutely true

Try thinking about it quantitatively. Someone who spends the time to schmooze (read: invest time in developing a human relationship) has essentially posted that time as collateral. They added chips to the figurative pot, and if they were a fraud or recklessly destroyed that relationship, they forfeit that collateral (lose the relationship, lose the honor and respect they earned). So that's why it's convincing to invest in people who are willing to post collateral. Now certainly, there are people who have no shame and will pull cons. So this method isn't infallible. But they can only get so far before they get exposed, especially in our industry.

> time to schmooze (read: invest time in developing a human relationship)

There's a reason why engineers are looked upon as aliens. "developing a human relationship" is the basic thing all people do, not some annoying side requirement

Refusing take-homes is a reasonable stance but refusing to whiteboard strikes me as overly critical. It's a pretty standard thing to do in an interview... while whiteboarding may be a little silly, walking out of an interview after someone's already blocked time for you because you think whiteboarding is silly is even more silly than whiteboarding is. If I were the interviewer I'd be concerned that you can't be even a little bit flexible with things that you personally don't like.

> It's a pretty standard thing to do in an interview...

I'm not interested at working for standard companies. :) But everyone is different. If whiteboarding is someone's thing, the more power to them.

> walking out of an interview after someone's already blocked time for you because you think whiteboarding is silly is even more silly than whiteboarding is

If there was a misunderstanding where they blocked out time in an interview for whiteboarding, I wouldn't be rude and refuse in person.

What I do is ask in the phone screening or the first engineering interview about whether the technical interview would involve whiteboarding or brain teasers. If the answer is yes, I politely end the interview process. That way their time is wasted minimally.

However, I have no qualms about walking out of an interview that involves brain teasers.

> If I were the interviewer I'd be concerned that you can't be even a little bit flexible with things that you personally don't like.

Interviewing is a two-way street. How about you be a little bit flexible and not make me do something that you personally like? No? Yeah, I didn't think so. I'll just work for companies that don't do whiteboarding in interviews, which are a dime a dozen.

Yes, that was a bit crass, but it amazes me how people in the position of interviewing believe that interviewers should care about whether they're concerned over something.

As a hiring manager I would take a refusal to whiteboard or participate in an in-person coding problem as a sign that the candidate knew they were not qualified to write code and therefore declined so as not to waste anyone's time.

I'm sure that doesn't matter to you as you don't want to work at standard companies anyway, but I have seen plenty of people fail to solve fizz buzz who had the nerve to show up for a Senior Dev role and therefore I will always ask my candidates to write code in front of me. Anyone can copy and paste their way into an active looking github profile, much fewer can talk me through their thought process as they solve a real problem that I have given them to solve.

If all I had to do was a problem like fizz buzz, I'd probably go ahead and do it. In my experience, most coding challenges that are in-person or take-home are more involved than that Fizz buzz, taking an hour or more. I can't think of a single coding challenge I did in the last 6 months that didn't involve either building a full application or something with complicated or game-like logic. The closest thing to fizz buzz level of simplicity might have been the custom file/directory system I had to work on, but even that was more involved and nuanced than writing fizz buzz.

Hey, interviewing is a two-way street. I'd love it if the candidates that know they don't want the job halfway through told me so and gave me my time back.

I am under no obligation to continue wasting your time. Who cares what the interviewer thinks here? You already (at least mentally) rejected them, so why should I care whether they would've said yes or no?

I wouldn't personally walk out for this reason, but things don't change when there are no consequences.

White-boarding is not silly and it's why the best companies in the world do it.

Define "best". Not everyone wants to work for Google, Facebook, Microsoft, etc.

Amen brother. Networking is absolutely the way to go. As employees or grunts and not a part of the ownership/capitalist class, our network is our biggest asset beyond our skills. Some suggestions: 1) Try to socialize with fellow engineers at work. Coffee, lunch, grab a beer. Host or attend a dinner party occasionally. Put yourself out there.

2) Don't work at any single employer for more than 3 years unless you have very compelling reasons. Stock options or you have excellent opportunities staying put. Changing employers allows you to grow your network and your skill and experience.

3) Attend meetups and networking events.

Whiteboard interviews can work well if they're not going to try to pick you apart over extremely complex topics and overly high expectations.

Interviews are good about getting a general feeling about a person.

This is ridiculous.

There's nothing wrong with on-site coding challenges, white boarding, and a good chunk of brain teasers.

Having people code a small problem might be by far the best way to understand how they can do the job.

"If having years of experience and a GitHub don't demonstrate to you that I can write code, "

Your Github code does not demonstrate what people are looking for.

> There's nothing wrong with on-site coding challenges, white boarding, and a good chunk of brain teasers.

If a company is looking for the kind of candidate that can and wants to work through those problems, then by all means they should do it. I personally don't recommend those kinds of companies because I'm unconvinced that on-side coding challenges and white boarding do much more than to weed out the really unqualified people and humiliate nervous but talented engineers.

Brain teasers don't measure anything other than that the candidate memorized the answers to common brain teasers, or as I've witnesses on more than one occasion, their ability to remember the answer given to them by a third party recruiter.

Maybe brain teasers are for you, and you can go work for companies that think brain teasers measure something. I'll go work for the majority of companies that don't fall for that idea.

> Having people code a small problem might be by far the best way to understand how they can do the job.

That can be, especially for junior engineers. If a company still wants to run aptitude tests on mid-level and senior engineers with years of experience, good references, and personnel projects, then they're being lazy. The fact that I don't want to burn myself out doing unpaid work at this point in my career isn't my problem.

Companies are free to not hire me. LOL

> Your Github code does not demonstrate what people are looking for.

And yet I've been explicitly hired because I had coded something relevant on my GitHub profile and could talk about it in detail in person. It sounds like you believe that a significant number of people with personal projects are really just bullshitters, and that making them write more code is going to tell you whether you want to work with that person.

No personal offense, but what you are suggesting represents exactly the type of company I want to avoid for good reason: Companies that think they can conveniently measure a candidate's aptitude through unproven metrics like brain teasers.