>This is kind off strange for a non US resident to grasp.
I've worked for two non-technical companies as a software developer and one highly technical company, and interviewed at a few Silicon Valley companies.
The difference between the interview processes is staggering; my current job's interview was two hours of conversation, no code tests, just a general assessment of "do you know what you're doing" by the hiring manager and a couple other members of the team. The highly technical company had a code assessment then the in-person interviews had zero coding.
The SV companies must have a good reason for this, but golly the amount of coding in those interviews is nuts. I'm a process over code speed kind of coder, and I've failed every SV-level test because of it; my code comes from talking to non-technical users like medical researchers and study operations managers and tossing something together in Python or a cloud service that makes their lives easier. Needless to say, I don't go over algorithm fundamentals on a regular basis, and I generally fall out after the first or second interview.
It's especially odd that interviews are so intensely focused on those couple hours since I personally don't see any dev or any resource for that matter contributing in any meaningful way in so fast a time, or even within 90 days. I'm not sure how this problem could be solved with the limited time companies can dedicate to interviews, though; maybe rely more on portfolios?
It's quite frustrating, I've submitted my portfolio of open source projects on GitHub for interviews. I specifically told the recruiters, HR personnel, hiring managers and some of the developers that the projects contain a large enough body of work to see examples of my code. These projects are quite comprehensive and not one person looked at them or mentioned them during the interviews.
Unfortunately, people in general rarely try to first understand what the candidate offers. It's more often ONLY about whether candidates uunderstand the exact way the company uses certain technology.
Knowing what good work looks like is a plus, but I wouldn't be convinced by cherry-picked successes. That doesn't tell me how much you struggled with them, how many others you failed, or how much of the work was actually yours.
I think most of your concerns could be answered fairly quickly in a conversation, though. I can look over a Github repo and check out its history and ask specific questions about changes and why they were made or why design decisions were made.
The cherry-picked successes thing is certainly a problem, though, and not just for coding. Maybe it's the candidates I've asked it but when asked "tell me about when you made a mistake in a project" they tend to answer with a strength and try to re-frame it as a weakness. "Oh, I worked too hard on this project and it made me tired" isn't a weakness. "I worked too hard on this project and that made me neglect business requirements since I was too myopic to notice" is a weakness.
Sorry if that's a tangent, it's been a pet peeve of mine since I started interviewing that not many people are humble enough or have thought enough about what their weaknesses actually are, and how that affects the success of their work.
This is also my experience interviewing for embedded systems and (hardware) test automation work at electronics manufacturers. I've never been asked to code anything. (Nor have I been asked to draw any schematics.) Just conversation.
Go start a company. Hire people without doing any sort of coding interviews. Report back in a year.
The reality is that these are extremely desirable positions with a staggering number of applicants who _do not know how to code_. Not as in “I can’t solve a dynamic programming problem without studying up on it”, but as in literally don’t know what a for loop is.
The process is far from perfect and the frustration is understandable, but it works well enough as a filter from these companies’ point of view.
I imagine technical screening is necessary, but in-person coding assessments are nonsensical. It's not like programming is a spectator sport, so why are we tested on it live? I suppose the process is self-selecting, because I personally have given up responding to SV recruiters or interviewing with those companies.
Well it started off with Microsoft in the 90's, then Google in 2000's and then it just became common for every company in SV to conduct these programming interviews.
I've worked for two non-technical companies as a software developer and one highly technical company, and interviewed at a few Silicon Valley companies.
The difference between the interview processes is staggering; my current job's interview was two hours of conversation, no code tests, just a general assessment of "do you know what you're doing" by the hiring manager and a couple other members of the team. The highly technical company had a code assessment then the in-person interviews had zero coding.
The SV companies must have a good reason for this, but golly the amount of coding in those interviews is nuts. I'm a process over code speed kind of coder, and I've failed every SV-level test because of it; my code comes from talking to non-technical users like medical researchers and study operations managers and tossing something together in Python or a cloud service that makes their lives easier. Needless to say, I don't go over algorithm fundamentals on a regular basis, and I generally fall out after the first or second interview.
It's especially odd that interviews are so intensely focused on those couple hours since I personally don't see any dev or any resource for that matter contributing in any meaningful way in so fast a time, or even within 90 days. I'm not sure how this problem could be solved with the limited time companies can dedicate to interviews, though; maybe rely more on portfolios?