So, when I hire, I do so through through connections. I ask friends "Do you know anyone who can actually code who is looking for a job?"
And if it's just me, that's the end of it, but... let's say I'm hiring for a venture-backed firm, or for a department in a bank or something. In that case, I have a fiduciary duty to put a job ad out there, and I have to be able to show that I received a lot of resumes and "looked them over." By which I mean unceremoniously threw away. Who has the time to look over 1,000 resumes, most of which are complete bullshit?
I was going to hire my friend's friend anyway, but I had to solicit your resume along with many others to provide some cover. I threw your resume away without glancing past the education section (if you had gone to an Ivy I might have looked twice.) Capisce?
To quote from Wiki (I know): "[t]he distinguishing or overriding duty of a fiduciary is the obligation of undivided loyalty" and I'd argue that taking on capital imposes just such an obligation, such that trying to hire the people most likely to maximize your investors return is indeed a fiduciary duty, one that implies other duties.
As usual, the night before the interview I printed out his resume and the resume was about 5 pages long. I was not too happy about long resume, especially I spotted inconsistent formatting issue there. That's sloppy. Later my manager said this could have been a mod version from the talent recruitment agency. I got on the E train and I kept shaking my head during my whole ride. This resume looked suspiciously fake and bad. 90% of the technology this candidate claimed to have experience with show up in pretty much all of his prior roles. How can Cassandra appear in a role in 2003? Facebook wasn't even a thing. That was just of the several lies I caught immediately.
But I am a fair interviewer. I wanted to discount this resume and I wanted to see his real time performance. I always ask my candidate at least one system design problem because system design question usually can tell me the depth of knowledge the candidate has. I don't know my algorithms very well, but I know a lot about how to piece systems together. I know how to draw diagrams and show people my thoughts. I want people who can talk, especially in an architect role; I don't want just a code monkey. I like to spend more time with candidates even if my manager thinks we are done I usually request extra time so I can squeeze every bit of his/her knowledge.
So I asked him the same question I was asked to answer during my interview with our SVP. This candidate went speechless despite my multiple attempts to rephrase the questions and multiple hints. The question is as simple as given a SQL database and multiple data files (of some format which we don't care), we want to prevent duplicate record. This question is awesome because you can load the files in single-threaded program, in multi-threaded, or distributed. Design a system which can satisfy all three conditions are common (it's essentially evolution of a system - you start with the most basic single process single machine processing all files sequentially, and then perhaps going fully distributed like launching EMR or multiple worker nodes, or using S3 events and lambda function if we move the files to S3). If queue wasn't available, we can do checksum and lock file. Not perfect solution; we can trade time with integrity and accuracy.
Anyway, he failed the interview. I never bothered to check on his credentials but if he did graduate with a PhD, I am disappointed.
My 2 cents to all the juniors looking for job: please do not lie on your resume. Be concise and list what you actually know. If you did some C programming but you do not use C or no longer familiar with C, please do not put C on the resume. Rate your familiarity with tools, only list the ones you have good grip on. If you don't really know how to answer a question (e.g. do you know what content security policy is?) you can say "I don't know" and then ask the interview if he/she can give you a brief overview of what CSP is, and see if you can bring up related web security topics. But if you are just unsure or can't remember everything about CSP, start with "I don't quite remember, but I learned about CSP when I blah blah blah and I remember blah blah" that sort of response will get you somewhere, at least you are talking. Talk. Don't sit there and remain speechless.