[yoelhacks]

At companies I've been at (mostly earlier phase startups, YMMV) there has always been an effort to do some sort of technical vetting.

Designers need to present designs / their portfolio.

Sales people need to do a demo.

Product people need to put together a mock roadmap or pitch a feature.

And so on.

[cableshaft]

> Designers need to present designs / their portfolio.

As someone married to a designer, this is soooo much easier than the hoops programmers have to go through.

Might take a little more work upfront (or just printing out work from previous jobs if allowed), but then you just flip through an existing portfolio the night before, and bring the same portfolio to every interview, no extra prep required.

Meanwhile, a programmer has to perform intense 1-8 hour tests every single time they apply anywhere, and make sure they remember the answers to gotcha questions in about 30 different subjects they could be asked about.

My wife always goes to way more interviews and talks to way more recruiters than I ever have (probably 5x more), because all she needs to do is read through her portfolio and practice some questions for 30 minutes the night before. And her interviews are usually just one or two hours long.

Meanwhile I always have to spend weeks brushing up on Leetcode before making a big new job push to make sure I don't have too many surprises, and I avoid going on interviews because it'll be long grind that I usually have to take half a day off work for.

I still had to do the stupid technical tests for a mobile app job where I could tell them to go to the app store and download a game of mine, with my name on the title screen, and they could play it, and they were really impressed with the game (the Xbox 360 version of it won a game design award in a contest hosted by Microsoft, and it looked and played identically).

Like... come on.

[hn_throwaway_99]

FWIW, I've often given interviewees one of 3 options:

1. Do an in-interview programming test. We try to make this as "real world" as possible with limited time, i.e. we give the candidate some existing code (which is similar but "slimmed down" compared to our actual code) and tell them to enhance it by adding some feature, then in some cases we had another piece of code with some bugs and asked them to fix them and write test cases.

2. Do a take home programming problem. I like to give people the option because some folks just do really poorly under the pressure of an in-interview test. When it's finished and they come back, we review it together and talk about their choices, etc.

3. If the programmer has lots of publicly reviewable code, I ask them to just share it with me so then I can review it and discuss it when they come in.

I basically just need to understand "Can this person write code?", and, related, "Can this person take a request in English and translate it to code quickly and efficiently?" And despite giving these choices, when I've posted a description of this on HN in the past I was still flooded by responses about how I shouldn't expect any of this: "I have a real life, I don't have time to do your take-home problems", or "I've been working in industry for years and coding for a job, all that code is proprietary and I can't show it."

All that may be well and good, but then my interview process is working - I don't want to hire you, and I can find people I do want to hire that are willing to do one of those 3 things, and it's not my job to make you understand that. Honestly, for all of the bitching about technical interviews, I feel a huge part of it is that:

1. People just can't accept that there are other people that are better than them that do do well on technical interviews and excel on the job.

2. Yes, there are outliers, and you might be one of them, but it's hard to craft an interview process around outliers. I also agree with Joel Spolsky's mindset of "It's better to pass on someone who might be OK, but you're not sure, than take the risk of a bad hire." I feel like every time I've made a bad hire there were definitely yellow flags during the interview that I tried to explain away, but I always ended up regretting the hire later and I've become more hardline on "if you can't prove your skills in the interview, I'm going to pass".

[funemployd]

Have you considered that that's a function of startups and not any intrinsic necessity of those positions?