Don’t do interviews, do discussions
thinkingthrough.substack.com
thinkingthrough.substack.com
Honestly how many times do I need to rehearse these dumbass algos (blah blah blah, so I'll optimize for space with blah blah blah) okay already. I would much rather show you real world code that I've built, or passion projects I spend my free time on. I want to bring me to your company/projects, so get to know what I'm about holistically as an engineer. I think you can best understand that by looking at actual work done and judging whether or not the person is capable of contributing to your needs.
Whenever we face challenges, we learn from them. At scale, we learn everyday. So just hire people who are passionate about facing challenges and learning from them. Not someone who can spend 8 hours a day like a college student playing leet code instead of building something useful. It really isn't that hard to memorize a dozen essential data structures and algorithms. But then what? So cringe.
If all your career experience so far has been at the NSA, yeah, you might want to do a side project before looking for work.
So I can't say what the code specifically does or who it's for, but I can talk about how I worked on a c++ engine wrapped in a Java server that was responsible for coordinating a large group of non-homogeneous assets, as well as various architectural details (what libraries did we use, database, messaging setup, etc). So it's not like I have nothing to talk about in an interview, plus the fact that I can't get too specific adds mystique. It's kinda fun, because in my experience there's an assumption most engineers/engineering managers make about what I've worked on from that first statement, particularly if they know where I work, and it's actually not that. :)
if you have been through a CS program you have worked on probably at least 10 projects. and then there are your personal projects. if you have any experience you can talk about at least some of these apart from the stuff under NDA.
so, this approach is much better than timed coding interviews and is a much more fair system as it rewards and takes into account experience.
That's fine for a new graduate, but many of us are decades out of college. What we did then has almost zero relevance to jobs we might seek today.
Here's a basic straw man rails controller. There are a few things wrong with it. Apply suggestions. It was nice.
Maybe I started a new compiler or something at my company but didn't have the chops for it and the project flamed out. If I lie and said that all my goals were achieved and all the hard technical challenges were overcome, how can you tell?
Or maybe the project did succeed but someone else came up with the idea and led the efforts. I was there for the technical discussions and grilled the lead on why he made the choices he did, so now I can answer your questions and sound like I know what I'm talking about.
Software engineers can make a lot of money, the incentives to game the interview process are high and people attempt it often...
Everyone you talk with, has probably one or two anecdotal stories of such. "Yeah I worked with this CS grad that couldn't even write FizzBuzz" - yet we ignore the hundreds of other that do their work just fine.
And this is fought with setting up ridiculous 8-part technical interviews where you'll have to whiteboard some leetcode questions ("Given a problem, show us a working O(Log N), or preferably O(1) solution. You have 45 minutes") or design questions ("Show us how you would design slack / discord / zoom / etc.") that drags over 6 months.
For someone to be truly incompetent, or even not good enough to meet the company standards, the current system is overkill.
I asked him to explain how to do it in 2. And he was like, “what? It’s easy!” Then another person on the team who over heard it also asked.
Eventually the whole team was there, asking him to prove it, and he spent over an half an hour trying to explain it, and none of us were getting it. The consensus from everyone (except the manager) that it was an unfair question that relied on a a very subtle assumption about the data that wasn’t obvious at all, and that 3 passes was the minimum required Without the that assumption.
Of course the manager said everyone was stupid and it was a good question.
That manager remains my counter example of what a good manager is.
A friend of mine at a FAANG recently dealt with a bad hire. Their guess was that in the 6 months the bad hire was there they cost the company maybe ~5 million between wasted engineer time and delayed release schedules after people kept having to put out their fires. On the other end of companies, I've heard of seniors corrupting the database and its backup and ending an entire startup.
This is not a defense of whiteboard interviews per se, just an observation on why companies desperately want to avoid bad hires.
If you interview for an R&D position at (e.g.,) a biotech company, in academia, or one of the National Labs, you're usually asked to prepare a 30-45 minute presentation about your past work. New grads usually use their MS/PhD thesis defense slides; other folks often have a conference talk they can expand. Some places also do "chalk talks" where you describe how you'd approach a new problem of your or their choosing.
This presentation is the jumping-off point for the rest of your interviews. If you talked about building a compiler, someone is going to ask for details about the lexer, maybe have you do implement a very simple tokenizer on a white board. Another person will ask how you measured its correctness/performance. Yet another may dig into how you organized the team doing the work, etc.
Maybe, as you propose, someone else helped with parts of the work. This wouldn't necessarily weed that out. Nevertheless, I'd argue that being able to justify the decisions that were made--and cogently explain when/why they might be different--isn't actually BS; it's understanding.
The point is to have a conversation about a project that the candidate understands well and is passionate about rather than asking them a bunch of questions that we already know the answers to.
Before the interview we review the code base and try to understand what it’s doing by the documentation provided in the readme. During the interview we get the candidate to demo the project and any questions that came up in our code review we ask at the stage of execution in the project demo. The interview lasts for 2 hours and we’ve had several rounds of candidates put through this process.
Both we as interviewers and the feedback from candidates has been very positive. The interview ends up being a day-to-day normal experience within the team and this really helps us to gauge the team fit. I think this helps to hire people that compliment and expand our skill set rather than hire people who are basically ourselves.
Contrast it to giving a candidate some slightly broken code in a framework related to the role and then asking them to a)fix it and b)implement a new feature of their choosing and document it.
The advantages of the latter approach:
* The interviewer doesn't need to prep beforehand as they already know both the problem and the codebase. This means they can ask much more interesting questions and don't have to invest significant time in reviewing a project that might be in a field in which they have no experience. This in turn leads to better discussions which in turn leads to better interviews.
* The candidate is given a much tighter problem definition and isn't required to come up with something a)novel, b)not covered by their current employer's NDAs.
* The candidate's time is respected because they can be told how long it should take them up front.
* Each candidate gets a standardised problem and so it's easier to compare between them.
When I give take-home assignments, I'm just looking to quickly confirm that someone has a working home dev environment (i.e. they don't just code inside environments that other people give to them) and that they can understand a small codebase and write clean code and document it. Everything beyond that I can find out by talking to them during the interview.
When I actually used this technique in interviews it was interesting to see how many supposed senior engineers would reply with things like "I'm getting a %JAVA_HOME NOT FOUND error, please can you fix the repo and let me know when it's ready for me to work on?".
The test is intentionally designed to filter out candidates who cannot meet or do not want to meet the technical requirements.
Yeah, no, nobody is or should be giving you their own personal work. It's offensive and probably illegal that you'd even ask.
> The novelty and creativity of your submission
Yeah, no.
"Passion projects" in my "spare time"... maybe once the kids have grown up and flown the nest...
Leetcode is easy... I memorise a bunch of stuff, do the dance and pass the interview. If i'm lucky I get a problem i've not seen before and actually have to use my brain during the interview.
I've found this technique to be extremely successful. It's possible I may have had some false negatives, but I've never had a false positive. Everyone I've recommended for hiring has been successful.
It's possible you're good at spotting good people, and rejecting bad people, but it's also possible that hiring is just easier than you think it is, and most people are capable of doing the jobs you hire for. You have no way to tell if you'd have the same result just hiring people by picking random resumes. Maybe negatives are just rare.
This is the impossible problem with hiring. Every interviewer wants to minimize false positives (they're expensive!), but every interviewee thinks they're a false negative.
The fear of BSers seems to be what holds people back from this approach though, and I can see that it wouldn't work for certain non technical fields.
That's just survivorship bias waiting to explode. Also, they're successful by some arbitrary metric that is applicable only to your company.
I've been on the hiring team for every employer I've had for the last 15 years and have hired dozens of people.
I also just generally do not think that most people can even put together a 2-3 hour presentation of their past work that goes over well. Most of the time people can't really talk more than 30 minutes about past projects. That requires a whole different set of skills, which there are certain contexts where I'd value that more highly. But my initial impression is that if we set up our interviews this way, we'd also end up filtering out a lot of people who'd be great, since not picking the perfect project to demo basically dooms the entire interview to be a flop. With multiple interview types, you increase the chance that there's an interview they really shine in.
My experience has been that a lot of candidates can't even fill 45 minutes. I ask "what was the most interesting part?", "what was most technically complex?", "what would you do differently if you did it again?", and they just don't have nontrivial answers.
Yeah, because you can have a career where you're just gluing stuff together to make business apps for, usually, simple business problems. You're looking for craftsmen but you're interviewing plumbers.
Most people look up the local business listings, pick anyone advertised as "plumber", and call to make a service appointment. Or they use a general contractor that already has a list of approved subs. Master plumbers don't have to answer little trick questions about brazing copper or about finding lead pipes in an old building. People somehow trust them to know what their job is, and do it.
Rarely, one might encounter an unreliable plumber. They might not get paid, and any other plumber is usually able to fix their botched jobs without hurting the budget much. Review sites exist to track building-trades business reputations.
But the analogy breaks, because no one trusts software and IT folks to do their jobs competently. The default assumption is that we are all know-nothing hacks who could destroy the company with one keystroke. All our knowledge is assumed to be tightly siloed, and does not transfer between similar technologies. C++ people can't do Rust or Go. Java people can't do C#. Desktop people can't do the cloud. Back-end people can't do UI. CMMI people can't be Agile.
It's madness.
There are a million reasons why this approach doesn't work. Maybe they just don't like talking that much. Maybe they don't like the technology you're discussing. Maybe they just don't care enough to have an opinion on it.
None of the above are good reasons to pass on a candidate.
Not really. If someone can present solid reasoning and argue their point well, they don't have to think like me. Three's more than one way to skin a cat.
> Maybe they don't like the technology you're discussing. Maybe they just don't care enough to have an opinion on it.
You mean the technology they are being hired for? Yeah, hating, not caring about it is probably not a good motivator to go for the job then, wouldn't you agree?
> None of the above are good reasons to pass on a candidate.
Beats the whiteboarding. I was hired like that in my last 3 jobs and I have used the same approach myself with rather consistently good results.
I've learned the hard way to be very reserved when giving opinions about technology X because interviewers sometimes get really defensive about the thing they like about technology X.
Also, putting the emphasis on the interviewer understanding the candidates code instead of the other way around is never going to be popular ;-)
It's also hard to scale it, make it objective, and keep the efficiency high (most developers prefer not spending their time on either side of the interview table)
There is another advantage to the "algos". If you can learn algorithms then perhaps you can learn other things as well.
Every new job I've had involved quite a lot of learning in a very short period of time.
Learning whatever language, and whatever standard library is almost always trivial. They're usually not all that different, well documented, some with textbooks even.
Learning to navigate and reason about the huge number of undocumented, often arbitrary, system architecture decisions, design decisions, code layout, etc. etc. that make up real code bases.
That's hard. Really hard.
Show me something you've done that you're proud of. Take me through it in depth. Answer some questions on it.
Doesn't have to be a free-time project. If you don't have a free-time project and you're too NDA'd to discuss previous work, then present some language feature or something.
Even though this advice sounds awesome, I will be cautious of putting it into practice without thinking through the bias problem.
I do remember reading multiple research papers on this, but unable to find them at the moment. From anecdote - In the last company I worked in London, only one team (DevOps) did not follow scripted interviews. It was the least diverse team, not just in terms of representation, but in terms of diversity of thought. Most of it was comprised of "tech-bros".
Scripted interviews do not mean you ask through a basket of questions. It just means that you stay within the guardrails of a set of topics and you go through all the topics. With in a topic, you have fair amount of flexibility. For example if you are hiring for a mid level Java programmer your topics may include - Java 8, Testing pyramid, Functional programming, type safety, developer safety(CI/CD/Rollbacks/Code reviews/Pair programming etc), some domain specific knowledge and so on.
Did this result in poorer job performance for the DevOps team, or any other negative business results that were specific to that team? If not, who’s to say which interviewing method was better or worse?
As an interviewer I’ve always felt very constrained by scripted interviews and “approved question lists”. I always struggle to really evaluate a candidate when I’m asking pre-selected questions without knowing why I’m asking those questions.
It did. And even if it had not in this particular case, it will hurt the company in the long run. There is not even a shred of doubt in my mind that diversity (of thought) is the best investment that leads to success.
I have been using scripted interviews, the same method I mentioned in original comment, for more than 5 years now, hiring more than 200 engineers in three continent and I am super happy with my results.
Honestly, having been on plenty of interview panels for a decade now for DevOps and SRE roles, I'm not sure structured interviews, no matter how awesome they are, can solve the recruitment diversity problem. The war was already lost the moment the job description was published, IMO.
And the process I follow is based on having an exhaustive list of questions covering all areas of the role but during the interview if something else comes up, I don’t mind pursuing that and going unscripted. It often helps me add more questions to my list so my list of questions keeps improving.
I’ve been following this process for last couple of years and the structured process has helped me hire some of the best people I had the privilege of working with. Also, I feel more confident that I’m hiring the right candidate. But of course, there could be an element of bias in there.
Side point - I’ve just finished a SEO hiring guide that covers my whole process of hiring an SEO person (both junior and senior roles). Will be publishing that in the next 4-5 days. If anyone is interested in purchasing a copy, my email is in the bio.
FYI, there's plenty of nuance in the research that people like to gloss over. My understanding is that diversity of background / experience improves team performance. But having a diversity of values amongst your team decreases performance.
For example, if you form a diverse team where some people care about profits above all else, and other people care more about doing good in the world, the team will become less effective. Its really hard to use this research when hiring because a lot of values questions (like "who did you vote for?") are somewhere between creepy and illegal to ask.
Source: I used to work with someone who had a PhD in psychometric assessment. People saying "diversity=good" was one of her bug bears. I haven't read the research myself.
Seems like a bit of a sacred cow - how much better? Better enough to sacrifice, say, experience, contacts, or unique business knowledge for? How much, exactly?
When I train interviewers my advice is: have a script, but be happy to go off it. If interviewers keep an authentically engaged conversation, the questions will blend into the background.
Scripts helps in several fronts. They help to reduce bias, standardise calibration and practices between teams, and provide a fallback to get the interview on track. However good interviewers should keep a living conversation with candidates, and take interesting cues off script.
On the other hand someone answers in a way that you have decided before hand is just the misguided answers of a particular tribe can be lack of diversity of thought, because you happen to be right about the preconceived ideas of said tribe, but pretty hard not to see that as the result of bias.
If on the other hand someone says some things you don't understand, espouses ideas completely alien - insane!
on edit: clarification
> Having unscripted conversations is one of the best way to be swayed by unconscious bias in interviews.
Yet, lack of diversity of thought is “easy to spot”. Without being swayed by unconscious biases?
That’s too bad, because the obvious followup question is whether those papers survived the replication crisis.
I treat the interview as my chance to help the candidate pass the interview. This bent of thought may seem subtle, but makes all the difference in meeting the candidate in their terrain, and seeing the world from their point of view. Consequently, the case studies given explicitly state that if the candidate finds something else that intrigues them, I am happy to take that as a case study instead - gives them something to flaunt and for me to learn about.
Some candidates are shy to open up, or just not comfortable conversing with strangers, or misread the power asymmetry in the interview and get anxious - I spend a fair bit of time just conversing human to human.
For the really uncommunicative candidates, I make a slight of what they built (fake slight) and this gets the conversation going like a star. The good candidates exhibit a great amount of "Builder's Pride" and defend what they built. They really good ones admit to the possibility that there were other better ways to have built, or explain to me the constraints under which they made the choices they did.
Yes! This is exactly how I treat interviews as well (as the interviewer) and would make a good addition to this already solid article. It really opens candidates up when you treat them like you're in an actual scenario at work. Let them ask for help, google for ideas, ask about different solutions, and ask them what they think of your own solutions. How they deal with these things are the real markers of what they'll be like to work with, not how quickly they can remember how to reverse an array while you sit there staring at them.
Does anyone just clam up because you are making slights about something where you don't know the constraints and make inferences about you from that? Most of us have dealt with utterly terrible, opinionated, under-skilled, supercilious and rude interviewers. How do you avoid coming off at least a little bit like that? Generally speaking there's zero point picking fights with an interviewer no matter how wrong they are.
Hopefully, the first part where the human<>human chat happens, the candidate is able to see that the intent is to have a genuine conversation, albeit with a more senior person (aka older) person on the other side.
Where I differ from you is the zero-payoff framing. There have been cases where the candidate put me in my place, rightfully so, and ended up getting hired.
This is subjective territory, but I actually prefer a candidate that spars. It gives me a chance to explain my position as well as hear his/hers.
This site is almost as bad as Reddit, go with the status quo and polish each others ego or you're downvoted or flagged.
Recently I have been looking for another team internally to my company. An interesting fit is that I went through 3 interviews. I'm an engineering manager. Two interviews were focused on system design, one was coding. The only non coding question I received was around how I coach people. The three persons who interviewed me I asked: "what does the team need to do better", and they all answered a variation of "it takes a while to get stuff to prod once it's built. We need someone who can help get better at that". Yet not a single question for that. I guess the lesson learnt is that if you are looking for a particular skilk, maybe focus on that as well.
If they knew enough about the problem and its solutions for it to filter down to people doing interviews, they wouldn't need to hire someone to teach them how to do it, right?
- Can you tell me about a time when you had an issue delivering things to production quickly? What did you do to optimize? How did you know there was an issue? What alternatives did you consider? - Can you tell me about what you have done in the past to optimize they lead time to production? What strategies did you employ? How did you
While you won't be able to tell if what they did was optimal, that can at least tell you if the person in front of you has some concrete experience in the topic, and some depth in their understanding. While that's not perfect, it's certainly better than flying blind
Paradoxically, I think I interview a lot better. I can steer conversation towards stuff I care about, and if they insist on being annoying, just thank them for their time and leave. Though this might just be a result of being pickier about who I interview with.
If nothing else, it's _amazing_ for negotiating. "honestly I'm really happy where I am, but every man has his price, what can you offer?" does wonders.
I experience this too as I not just as I progressed in my career, but even within one batch of interviewing. I've always tried to batch as many interviews as I can. By the third interview I am feeling much less anxious and just perform much better and by the fourth or fifth I am nailing them to the wall - performance seems to be inversely proportional to how much I am worried about doing well in this particular interview.
When I'm interviewing people, I work very hard to put them at their ease and discount interview anxiety when I see it. Too many interview processes are tuned for confidence, not actual skill.
No, conscientiousness doesn't correlate that much with neuroticism. You can care about the results without getting cripplingly anxious, the anxiety isn't a good thing.
Many people with social anxiety are excellent writers and I make sure we always have a written portion of our evaluation to give them.
Is the written portion the way to offset this in your experience? In addition to being hard to squeeze into typical 45 minute interview chunks, I’m not sure that would calm my anxiety personally. But I’m certainly willing to try.
This strategy served me well on many fronts: confidence in my skills and my options, familiarity with evolving interview trends, and networking opportunities with team leaders in a tight knit industry. It also allowed me to chase roles/positions which I wasn't immediately qualified for without feeling stress and anxiety, and was immensely helpful later on as an engineer turned startup CEO to know what product/project management interviews should feel like.
You can keep this shape up to some extent by doing a lot of interviewing of candidates at your current job. It really helps you understand what interviewers are looking for, what they expect, how a good interview should feel and flow.
But there are just some things you don't practice until your own interviews. So you'll want to have your answers to questions, and stories, and narratives all planned out. And make sure you practice them out loud, multiple times, until it's flowing naturally and easily.
And I just accept ahead of time that I'll fail 60% of the interviews that I apply for that I'd be perfect for. Sometimes things click and sometimes things don't. So make sure you've got warm leads and schedule your first rounds at an appropriate number of companies.
Hard pass.
Just like I wouldn’t want to be written off for a place for being nervous I wouldn’t write off a place for doing the standard tech interview day-of-45-min-white boarded-questions.
Younger me would have been very surprised how much i actually enjoy these conversations with manager types. In my experience, _most_ of the VP GM and CEO types are much broader and more interesting than most engineers tend to believe, at least younger me.
This is definitely surprising to younger ICs in the industry - who seem to want to become engineering managers any way they can.
The ceiling of genius you can possibly spike to as an engineer is far higher. I’ve seen single engineers at smaller startups perform the work of entire teams at big companies. And these folks get paid maybe 3x-4x the standard engineer salary. Huge savings. But hard to hire these folks.
I like this approach. Stops you from being painted into a corner, and if you are, you can still leave with your dignity. Some interviewers can be on such a power trip, which can make things feel pretty horrible for the interviewee.
Talk about wasting time. You are bothering to do the interview because for one reason or another you're interested in the job.
It's weird to feel good leaving the interview where you somehow saved face for yourself by not answering any of the questions. You just guaranteed that you neither get the job nor learn anything useful for your next set of interviews.
Wasting their time would be to continue the interview process and answer questions you think are pointless for the position at hand. It's something you can do when you already have other offers or your current position is good enough (meaning it is better than what the interviewers can offer).
When you know you won't take the job, it's okay to cut the interview short.
I'm interested in learning how other companies do things, what technologies people are looking for in the industry, what sorts of questions are being asked in interviews, and what kind of problems people feel are in the domain of a particular job title. I'm also interested in compensation trends in the industry.
I can get all that information from a decent interview even if I walk away. Politely, of course! It's a matter of respect for each others' time.
Though I was often asked "So why are you leaving?". Who said I was leaving?
But interviewing every now and then has other benefits:
- it has actually helped me become better at interviewing candidates
- a competing offer helped me get a better salary at a job I liked, so I didn't have to leave
- it kept my interview skills sharp for the next time I decided to interview
It didn't have anything to do with my career though. It was early, I had an okay position and just encountered something really interesting and exciting.
So perhaps the learning is more about how and when you choose to go explore something that excited you rather than other reasons to find a new job.
I've interviewed people who have resched this point. It makes for a chill interview. In some cases, the interviewee is overly "chill" and is bored with the challenges described in the job. I prefer to hire people who are EXCITED about the challenges they will face in the job.
When you have 20+ career, filled with success and failures, from which you can learn how to see and seek BALANCE, the last thing on your mind is excitement. You tend to see the world with realistic and moderate lens. And this is not only good for companies, this is a golden opportunity.
Sadly, more and more I look at the startups as a kindergarten party with serious consequences. Some VC's are playing the game and some lucky kids are taking this as a validation for knowledge and expertise. Selecting teams with "cultural fit" and "excitement" to fulfill a hollow visions of "changing the world".
P.S. I don't feel excitement. I consider myself a craftsman with a passion and deep love for my work. And your way of thinking is positioning you in the group of "thank you for your time" crowd. Automatically.
I also think that excitement =/= passion. For example, if you look at the top chess player - Magnus Carlsen - he always looks bored talking about chess, and yet that's what he does all the time and is the best at it.
In this case your pipeline is optimized for hiring great actors.
If I might ask, what do you do to excite your candidates about the challenges involved?
Anybody who looks excited about things they they have no stake in is just pretending and is likely a ace imposter.
I'd be very vary of hiring such a person.
I would be very surprised if you say literally this and get results. No self-respecting company or manager is going to invest in talking to you if you describe yourself so overtly mercenary.
Obviously, when you're happy where you are, money is part of the equation to get you to move, but making it seem like the only motivator is super gauche and culture-centric companies (which are the good ones) would hang up on this answer.
So curious - are you actually literally saying this and people aren't hanging up on you?
I tell every recruiter my price right off the bat and get plenty of interview offers. Unconditional devotion is reserved for my wife, who actually deserves it.
I wouldn't respect a company that expects me to stick around at below-market pay for "the culture". Tech companies already appropriate your labor on the cheap and keep the (enormous) difference. No culture makes up for that. They should at least pay market rate. I'm not a dupe.
Mature managers and owners are well aware that hiring is a commercial act and that commercial acts are about money. Signaling that you’re willing to walk from the negotiation is key to getting good compensation. Strategically, you wait until they’ve already invested thousands of dollars in labor costs interviewing you first.
And if it is below what I am seeking, I say "Thank you for making me aware of this opportunity. At the compensation range you stated it is a hard pass from me. If you can come back with a realistic number I might be open to a discussion. Good luck in your continuing candidate search."
Or if they ask me what I want, I say: "I'm currently making $230k base. Can you come up with a number higher than that which would convince me to move from a job I am happy with?"
It quickly removes the time wasters and the starry eyed dreamers and the cheap skates, and the people who are serious, then we have a conversation and see where it leads. And I have plenty of conversations every month. Yes, it's effective. It's a business negotiation, and the person on the other side of the conversation either understands that inherently or is trying to convince me that my labour is worth less.
If you're comfortable in your existing job then you are ALWAYS in the commanding seat during negotiations. If they want you then they will need to make an offer good enough. Otherwise you walk straight out and nothing changes.
Also, this isn't something you'd say on the phone. It's what you'd say during the interview, when they can't just hang up on you. You've done the interview, they ask "So, what sort of compensation are you looking for?", then you hit them with that.
If you show a weakness (a job you are actively trying to leave) then you will get lowballed. Showing that you have nothing to lose is a wall they have to scale and puts you in the best position possible for negotiations.
A mercenary working for another mercenary can be a very educational experience, and I have found that it is far easier to work with other mercenaries because they can be focused and aligned quicker than people that need to be inspired.
Honestly, if I was a hiring manager, then I'd try to only hire mercenaries keeping things professional.
This depends on what you are looking for.
that depends entirely on how badly they need you
I'm in a similar job and haven't interviewed for years but want to start and not sure how to go about it.
One surprising thing I learned from the initial interviews with my lower priority targets was that my prioritization was wrong, in terms of challenges, interests and compensation.
Also I'd like to work on something related to tackling climate breakdown, so I'll almost always chat to companies in that space. Sadly I need to pay off some debt before I can take a paycut to work on these problems (or risk a startup).
My cynical self is thinking whether this is (one of) the reason why young people are preferred in our industry.
Young = Less experience in negotiating = lower wage
Your compensation formula is completely void of the value someone can bring to the table. Young = less experienced, period. In negotiation, sure, but also in the on-the-job skills/experience/maturity. So of course they make less.
If you're a kid out of college competing with thousands of equally green kids, what would be your negotiating leverage? If you are someone 20 years in the industry with unique and proven experience, you can negotiate because you have something to negotiate with - there isn't another you.
The only difference is that I would drill into specifics in certain areas, but keeping it conversation-style so that it doesn't feel like a pointed question. Usually I found it to be pretty easy to see a persons level of knowledge because they tend to hit a certain depth where they aren't able to keep the conversation flowing, so you have to pull back up into their more familiar territory.
The only drawback with this approach is that I have to be really mindful about potentially being biased. Pointed questions aren't as much fun but they're easier to approach from an objective viewpoint.
I like your phrasing. I'm not in tech and don't interview folks for tech jobs, but do interview plenty of people for technical roles in financial services (for me: insurance industry). There are lots of ways to dig into their technical skills - white-boarding, take-homes, etc. but I am often digging instead for fit.
By fit I don't mean whether a candidate has the skills. I ask questions about interests. What does the person do with their free time? Is there something they are obsessed with? What would their friends tell me they talk about way too much? What topics eat at their brains at all hours regardless of time of day. What do they do to feed their interests?
Have had the most success with candidates who come alive (or more alive) answering those types of questions. They show their drive and passion with their hand motions, facial expressions, tone, and more. It's awesome, but importantly, it IS a discussion. It's no longer Q&A to me.
And if those folks fit my other needs (e.g. tech skills, requirements for job), I hire them.
You can absolutely get a good sense of their tech skills from just chatting and you can also get a decent feel for how they communicate in general which IMO is more important than tech skills once you reach a certain point.
He's so passionate about the subject that he created a Youtube channel. It's aimed at both interviewers who want to do a better job and interviewees who want to influence their chances of success. https://www.youtube.com/playlist?list=PLhCnsRMXhadbiHsTcxMCg...
How can ANYONE confidently proclaim that they're great at interviewing without some way of measuring the people they reject?
But I agree, I interviewed some at Google and we can see the stuff that happened in every other interview. And I was really surprised many times, ultimately I realized that I can't really make good judgements based on an hours worth of data and stopped caring.
Real programming is very little like they teach in school and even less like coding competition. Being good at programming is great, and mandatory, but if you can't also have a conversation then you can't actually do most jobs.
If they have a whole arsenal of project managers, architects, product managers, engineering managers, business/product analysts and still give this kind of lousy excuse, I'd probably stay away. Chances are they don't have any real expertise in the domain they are working in.
And btw, requirement gathering and writing technical specifications are taught in school.
If I'm hiring for a high-output FANG job, you bet your ass we're going to the whiteboard. Sure, I hate it too(on either side of the table), but it's not too much to ask to prove that you can think on your feet and solve hard problems if that's what the job is.
I generally tend to have discussions because I'm not very confrontational and also because I hate the modern coding interview. After moving to a FANG though, I now understand why the process is so hard. I also get that a lot of folks are frustrated because they've been told their whole career that they're smart, and they probably are, but for some roles the bar is just set higher. My 30 year old self, who thought he was hot shit because of all the praise I got for doing basic work(shake and bake linux embedded work, deep dive bugfixing, mostly writing glue code), was in no way qualified to exist in the world I (barely manage to) work in now.
More likely that you've drank the kool aid that you are somehow special and smarter for working at a FANG...
OP might be smarter than me, who knows. I don't really care, I feel pretty good about my intelligence level even though I know there are plenty of folks smarter than me out there.
What I am is annoyed at the elitism that OP shows. I work at a FANG, have worked at a couple SV unicorns too. There is plenty of work happening here that is not as challenging as OP makes it out to be. I've seen a lot of people with the attitude OP has and I think it makes for a toxic and unwelcoming environment.
As someone who has used complex algorithms research in my work, I agree white boarding has some carryover to some FANG work. But my experience is that there is vastly more boring CRUD work to do and you must generally fight with others to get the interesting/challenging algorithmics work. No need to filter out a ton of qualified people because they can't perform a tiny fraction of the work happening here.
1. Is upset
2. Interpreted the parent comment as being smarter than OP
Serious question: where did you infer these things from?
Because the most common say to day issue is needing to think of an algorithm on the spot...
You hate it because you know that's not true. Yet you're using it.
-Depth first search
-Binary Search
-Topological Sort
-Dynamic programming in a graph context
-Union Find
-Merkle Trees
-Fenwick (binary indexed) trees
Maybe I'm in an unusually technical area but it doesn't feel that way talking to my colleagues.
But out of all those algorithms how many could you regurgitate onto a whiteboard given 5 minutes to do so?
Knowing the use of each algorithm is good enough. You don't need to know the implementation until you want to use it. And nowhere in your day to day work is this going to be with no internet access or reference.
So why do interviewers suggest this is the case? Why aren't they just happy with you describing how a Merkle Tree can solve a particular issue. Why do you need to write that down?
Is your view of programming that good programmers spend the majority of their time writing boilerplate code or doing grunt work?
My view isn't that good programmers spend the majority of their time writing boilerplate code. But my view also isn't that the average programmer _isn't_ doing that.
I'd expect way more demonstrated knowledge for an interview in a higher level role than an mid level developer role. But the higher you go the less you actually need to demonstrate that. Why?
Are you trolling? Everything that you do as an engineer is coming up with an algorithm.
Algorithm is how you solve a problem, how you think about constraints and requirements.
There's plenty of algorithms I know and I can see relevant business contexts to use them in. Do I know all of their implementations off the top of my head to regurgitate onto a whiteboard? No, because I don't need to. When the time comes I will just look that up. The easy part is the implementation. This isn't a school exam testing your memory.
That's a big IF.
My experience with FAANGS is that their bar is universal. Even if you're going to a team which somehow won't require solving hard problems collaboratively under pressure, ability to do so is the bar for working at the company.
As the person you're replying to says, they use the interview style that gives them signal about this. And in general, unless one work at a FAANG and understands the roles, how does one think they have the correct perspective on how FAANG ought to be hiring for their roles?
From an efficiency standpoint, it is probably a lot cheaper to hire smarter users of those libraries than to ensure all new libraries can be used by less smart engineers. Especially since many smart engineers who can write great libraries doesn't necessarily have the ability to document those libraries well, so by removing the need for great documentation they can get a ton of such engineers that other companies with lots of mediocre engineers cannot find a good use for.
That said, I understand that in the interest of fairness and allowing equitable access to the highly lucrative RSUs, it's important to give interviews equally rigorous to candidates for the AdWords team as those who end up pushing protobufs all day.
We don't have a lot of glue code because we don't glue things together. We write the things other people glue together. That's why this is fundamentally different than 90% of anything I've ever done.
I also don't mean to say that all FANG work is like this. I could see some roles at, say, Google working on Android where it very much would be the kind of gluey work I've done before.
Previous to this job I laughed at the goofy CS questions asked in interviews. "I've been doing this 30 years and never needed A* or a graph algorithm." I have to retract that statement now. Not that the modern coding interview isn't a little overdone, but there is a point to it.
There's also the question of dedication. When you work on a very driven team you have to show a similar level of drive or you're just going to get burnt. I'm not saying the level of work/life balance is fair or the way it should be, but it's the way it is and it has taken me quite a bit to get used to. It's a toxic environment on many levels. That said, it's by far the most impactful job I've ever had. I'm immensely grateful for the opportunity to contribute 0.0000000001 pct to some amazing work.
I'm very close to 30 now, and have been burnt out enough times that it's a struggle to imagine how I could care about tech enough to attempt to re-transition into almost only caring about sort of climbing that ladder.
But, just focusing on the algorithms part of it, I never could answer how exactly a specific algorithm worked, but I've had to use many algorithms in my "normal" job. I just know "oh this needs a modified DFS, or A*, with custom heuristics, or a priority based permutations generator". I cannot answer how any of this works in detail on the fly, but I know where to look. Isn't that sufficient? I certainly would fail a FANG interview, but have gone toe to toe or even better when pow-wowing on some real problems with googlers. Wouldn't consider myself any inferior because I don't know how a specific algorithm works in the interview. Just my two cents
I use the term conversation or dialogue often to do away from discussion's root of 'breaking' or 'stomping'. I offer to make them coffee. We talk about pretty much everything. I ask questions. They ask questions.
We try to quickly get rid of the interview vibe by making them feel comfortable. We've refined this over the years.
Some of my best interviewing experiences have been when as part of the interview I ended up having a discussion about something. But the interview didn't explicitly start with that format in mind.
Some of the worst interviewing interviewing experiences that I've had is when they say that it will be a discussion, and it is, up to the point when they spring an algorithm question out of the blue... it feels so scummy and fake. Ask me about the algorithm if you want, but mixing your question into 40 minutes of discussing other things and pretending that you aren't examining me is a farce.
The intention seems to be to make the experience more authentic and it often ends up having the exact opposite effect.
If your criteria for hiring boil down to "did I like talking to this person", you're probably not hiring well and you're allowing all kinds of biases to influence your decision. If your criteria are specific but you're hiding them behind the pretense of "discussion", you're doing everyone involved a disservice.
I’ve had interviews which start very casually, “we just want to have a high-level conversation, no crazy whiteboard coding or anything”, then, absolutely randomly in the middle of said “high-level” discussion, I get
> “well we did prepare a question to test your quantitative reasoning skills; so assume we have a bug that is detected by an analyzer with a false-negative rate of 0.3% and the probability of a bug existing at all is 7% and <sea of numbers> what’s the probability that a given test will report blah blah blah”
Of course this is communicated purely verbally.
> “This looks like a typical Bayes rule problem. Is that what you want me to calculate?”
> “Maybe, maybe not. That could be an approach. We just want the final percentage. Feel free to pull out your phone and use the calculator.”
Then of course, on the spot, I’m fumbling around with whether you divide by P(A) or P(B) or … to find P(B|A), and mucking around on a 4-function calculator like a dweeb.
So much for the “high-level discussion.”
I talk with them about their previous work, stuff they're proud of, their hobbies and other things. I've recruited teams that excelled compared to their peers, and were certainly more fun than others.
“Hiking, trips to the beach” those are the answers. Any behavioral interview training will say the same
Everyone is lying (or actually boring and unambitious)
By the way, I do think whiteboard/leetcode is important, just not that important.
The reasons they're used are simpler. First, these companies need MANY programmers, so they're mostly hiring generalists without a regard for the specific work they'll be doing. Second, they need to conduct many thousands of interviews per week. These two fairly unusual conditions make for a situation where you want a controlled, quantifiable, and simple approach. A leetcode-style interview hits those marks much more easily than other styles. Plus, you can teach someone how to do it in an hour or two (not how to interview well, but how to ask a leetcode problem while not making any headaches for legal in the process).
While I agree that this is probably at least slightly biased against more senior devs, I think senior developers actually get an advantage here. In my experience, as you apply for loftier positions, the technical questions become much more of a conversation.
A couple years ago we were hiring data scientists, and started with a chat with the hiring manager, and then at some point a technical evaluation. We attracted business grads and others for the position (in addition to cs folks), and a lot of them talked a good game but couldn't do basic data science stuff. So we ended up switching the process to have some kind of table stakes technical evaluation up front, and then do the interviews.
I don't think it's ideal, but the filter has to be somewhere, and companies want to optimize hiring to cut people as quickly as possible rather than do a bunch of interviews and drop them later.
This is a good point that I overlooked and definitely agree is also present. The same thing is happening with other types of interviews - I have seen companies hiring now where the candidate is asked to record video answers to prompted question, that from what I remember are evaluated by some kind of machine learning. They can open up the funnel without having to do anything (except forgo candidates that either have some self respect or are not desperate for work)
lmao software houses in Eastern EU jump straight into day-to-day stuff, 99% of the stuff was normal development, that 1% was just for lulz, to check whether you heard about stuff.
0 algo questions.
We all grow up with the false, ingrained assumption that it's some sort of one-way privilege for you, the employee, to rent your time/body/mind to the employer.
For those who have done well in tech and don’t need to take the next job offered to pay for the next months food bill, because they have the savings, because they have 2 or 3 offers already, we may have the luxury of interviewing the company.
Most people aren’t in that situation, especially early in the career
One of the best times this happened is when I was being interviewed by the future manager and he said after 5 minutes you clearly know more than me and we started talking about the best places to go for a drink in the area.
I got the job and he was a fantastic manager and good friend
Two ideas follow. I don't think they'll work very well.
Here's the #1 thing you can do as a candidate to turn the interview into a discussion: Come prepared with some interrogative-led questions. These usually begin with the words "who"; "where"; "what"; "when"; and "why". Then ask your questions at appropriate times. A good time might be, for example, right after you answer a question on a topic related to the question you're about to ask. Another good time might be when the interviewer asks "Do you have any questions for me?" Having been on the other side of the interviewing table a lot, it's quite surprising how few candidates have anything to ask about one of the biggest decisions they'll ever make.
The quality of your questions will determine what you get out of the interview. To prepare good question, you'll need to understand the following at more than just surface level:
- the position
- the company/group/pod
- the interviewer
Research these three things before the interview. The questions you bring to the interview should be designed to gather relevant and missing information on these points.
What's "relevant information"? You'll need some goals to figure that out. Don't set foot in the interview until you have some goals that make sense for you.
Reversing the above into a process for preparing for an interview:
1. figure out why you're interviewing at all, and interviewing at that company in particular
2. research the position, the company/group/pod, and your interviewers
3. draft questions you'll ask during the interview
4. ask your questions at appropriate times during the interview
Yes, the candidate should come prepared to (1) resolve Leetcode Medium/Hard problems with obscure data structures and algorithms, (2) have a Github profile and demonstrate their side projects and (3) have best instances of their past careers to answer behavioural questions in the STAR format. In the same time, we want to demonstrate how the candidate "thinks of their feet" and now we have interrogative style questions. The way I see it - we don't really require interviewers at all. I don't see any benefit of an interviewer. We can replace them with robots.
Life's too short to be stuck with mediocre employers.
Hard disagree. I've worked at a lot of places where I was frustrated, didn't give a damn and felt like I was completely underperforming. And yet, my career has been advancing both in terms of title and earnings. So, unless you have a different metric for "advancing your career" I disagree.
That being said, I agree with your main point :)
It seems sort of trivially true to me, excepting any workplaces that are simultaneously soul-sucking and growth-prospect-full, in such an outsized way that it's better to underperform there than overperform elsewhere...
I've done the whole money+title things at places where my work barely made any impact. You'll pay for it later on; 40+ hours of weekly grind takes a toll on your mind and body.
If the only thing you focus on is career advancement, you don't need to be at a great place that makes you the most productive.
Billboard worthy quote right there.
This usually is a great discussion where everyone feels good at the end, but tell a lot about the sophistication of the person being interviewed.
After this, pass a small test to make sure the person can do some real work.
This takes an extremely high level of cognitive ability, which is a far, far better signal than a take-home test.
I just had a useless interview with a company that pops up here from time to time. The only thing I liked about the experience was that the itinerary at least tried to make it clear what the key values seemed to be: listening to customers, outcomes, evolving vision. I tried to "map" my experience with their potential customers and how they could think about the "box" and listen and solve.
There's a 10 billion dollar problem in this particular industry and if you take the time to understand customers, it's pretty obvious. I watched first-hand the biggest competitor of this org pivot for this after being around for decades.
The "discussions" I had were not discussions at all. They all seemed rushed. There was no "deep dive" into tech at all.
Next time I interview, I'm going to try a radically different approach: I am going to undershare rather than overshare.
As an interviewer, I'm going to start asking people about cucumbers rather than speak about particular tech or follow some form-based process.
On the flip side, when doing the interview and when I'm answering/explaining something to a candidate, I'm not really able to think ahead to the next tougher question in a chain of questions. I wonder how that impacts my assessments. I used to do 3-5 interviews per week, it is a shame I didn't take notice of this and compare to the group's consensus and outcome.
Interviewed a guy with a PhD in organic electronics and asked him how to make an organic transistor at home. It was a great conversation, not sure yet if it was a great interview.
Conversations gives both parties more fuzzy feelings, but are they actually better or just easier and less awkward?
How do you know that? Maybe those interviews are the right amount of formal. Do you have evidence that they are too formal?
It doesn't me nervous. It makes me wonder if they know what year it is. :)
Ultimately, it's a relationship. Yes, it has to work for them. But it has to work for me as well. Fit matters.
If they're doing all the asking and I'm doing all the answering that's a red flag. If we get to the end and they say "We have a couple minutes left...do you have any questions?" That's another red flag.
Put another way, as I've said before:
How you hire is who you hire.
So if you're hiring ppl that can't see your red flags...well...um...that's a red flag ;)
I found that mindset very powerful.
And the best part, he got an offer but didnt accept it.
don't let the power asymmetry get to you, take that attitude and you wont easily made nervous or uneasy and instead projects confidence
prepare insightful and incisive questions about how decisions are made, tech stacks, even how executives think about dev process and the business etc etc
as it turns out, many companies really appreciate the thoughtfulness!
However, in personal experience, I've found that this works much better with more experienced developers rather than with junior engineers. Why? Because for some reason, a lot of junior engineers have been pavlov-ed into thinking every interview is for something at Google/Facebook scale (no matter where they are interviewing) and they start describing extremely convoluted designs using tech that they are also not completely familiar with just because they want to come across as knowledgeable.
Something that I struggle with in these cases is reining in the dev back to the "what" rather than the "how", because I've seen even good engineers go into this "let's add a system-bus for everything" way of thinking. Constraining problems explicitly tends to devolve into the "Interviewer-Interviewee information asymmetry" which is the same with most DSA problems (At least with DSA, most constraints are known by both parties).
On the other hand, almost every time I've picked an actual problem we have with a system, be it a bug or a new product or something else, as an interview question with an experienced interviewee, I feel like I've come out understanding the problem space AND solution space better just through the process of discussion and in multiple cases, actually ended up using a lot of ideas from these discussions, so interviewing feels much more "natural" and a "dominant strategy" in game theoretic sense.
"Did you have any conflict at work? Tell me about such situations"
"What was the impact of the conflict?"
"What steps did you take to resolve it?"
"What changed after you took those steps?"
Well, it's the same line of questioning and addresses all needs of the interviewer. Yet, most of them wouldn't do that. It's still a discussion format and win-win.
A lot of the conversation is on interviews these days, on the idea that anyone can be a genius programmer after a bootcamp. While I don't deny it's possible, I think traditional selection based on the school people went to, and building a relationship between companies and school is a good thing.
Trying to holistically evaluate a worker in a few hours is not nice. It's very intense for candidates to have such opportunities to unlock in such a short time. People prepare for interviews intensely, and can live rejections as a deep traumas as a result. Having this process happen over years in academia seems healthier, and more accurate.
Companies would benefit from having their HR spend time studying curriculums of some schools, and build relationships. That guarantees a steady flow of qualified workers.
I see this where I live here in Japan, and I'm quite found of the work culture / society it produces.
They are not numerous though, but definition. So the concern shouldn't be too large as well. In France where i'm from, and also here in Japan, i see the education system as mostly working. People get educated and the people more designed for more study can pursue while other go working before them. This seems to work enough to me. I wouldn't know how to improve it without regressing more on other fronts, for instance
Oh god how much I hate this! It’s misused by (some) managers so much these days, it’s infuriating. For me it has the very opposite effect than the intended inclusivity.
Ugh...
Wished more companies are implementing this way of interviews
Phil's instructions mix some good influences and can be used when working with people in other mediated spot environments like interviews/discussions too.
Sure, you can tell yourself fairytale stories, but you and the other person both know there will be generated a number right after the call ends that can only range from 1 to 4 and you will be assigned it.
Also if you treat this as a discussion you may come off as arrogant. After all everyone else is showing nervousness so the interviewer probably thinks "what's with this person who acts like they're already on my team?"
As you establish yourself the power dynamic changes considerably as companies are really trying to convince you to come over. At this point it really should be a conversation to understand if you’re a fit and it’s worth your time. Do the people you’re speaking with impress you?
A discussion means an organic, constructive exchange. If anyone is too stuck-up, it way not work well.
Obviously getting to know the candidate through discussion is best.
-threat the guy as a human being, showing respect and kindness
-try to understand his mental processes
-try to asses his knowledge level by meaningful discussions, no "tricky questions" or "leetcode"
-ask to explain what he work on, what decisions he took and why
-explain some of your actual work issues and ask how he would address them
-do not try to make yourself look smart while trying to make your interlocutor look stupid
I’m looking for confidence, ability to accept making mistakes and improving and finally the ability to convey information in a teachable fashion.
The word "boss" was original chosen because it avoided implications of a power dynamic between the boss and the worker. Centuries later, it has re-acquired the same connotation.
Lastly, I don't want to have to guess what we should talk about so that you can feel you know I can do the job.
It’s a simple matter of asking the right questions.
Who’s wrong and who’s right?
The interviewer is always right.
If you don’t know what I think you should know then you’re incompetent.
Most of us really want to be as honest as possible, not just because we are good people, but because went want to ensure maximum compatibility. This is incredibly deceptive in itself because employer compatibility doesn’t really matter. As an employee you do things the company way or you don’t work there.
So, just lie. I really hate that, but there is no reason not to and every reason to do so. It’s just the nature of conforming to system of inherent implicit bias.
I think this is bad advice. I have never lied in an interview. I've also never had a job not offered to me if I made it to the in person interview part. This isn't to say that I have magical job-getting powers, but only that not lying has not hurt my chances.
In one job I applied for, I didn't have a lot of domain knowledge, but I had knowledge in an adjacent domain and wanted to to jump over to this one. I told this to the interviewer up front, and the interview was a bit rough but I managed to do OK. What I did was explained my thinking process and in many cases arrived at the right solution, or close to it. In others I didn't. The interviewer was sufficiently happy with my ability to solve problems on the spot that they hired me. It wasn't hard to acquire that new domain knowledge, but I had to work at it. I also took a level down in the new job, but they increased my pay over my old job, so I didn't care about the leveling. Long term, that helped me as my salary ended up being higher as a gained levels in the new place.
So being honest about not being the perfect fit has worked out for me. I think it can work out for you, too.
That said you are probably best off training machine learning to do this for you. It won’t suffer the nonverbal faults associated with dishonesty, because truth to a machine is how effectively it completes the assigned goal.
And once they find out that you lied about your volunteering experience at your local little league team, your whole resume goes under the microscope. I’ve seen it happen.
Second, you control what appears on your resume. You can spin it how you want by the facts you include and omit. You list the great selling points about yourself and none of the bad. Don’t lie on a resume because its already under your control and it’s a document of record that can follow you from any point in the past.
This tread isn’t about resumes. It’s about interviewing, specifically as a discussion.
As someone who's now interviewing a person or more every week (during a hiring surge), I still don't know of a better way to interview someone, but I'm not convinced this is great. A lot of people, who are unquestionably smart, coming into the interview after long careers in big companies, have a lot of trouble expressing themselves (especially if it's not in their native language), let alone selling themselves. They come in trying to find the correct answer for each question, even if it's open ended questions to trigger discussion. And when asked for a concrete answer to something, they will instead fumble around, only touch upon the answer, and talk about something that distracted them.
We still frequently hire people who interview like that, but it takes a lot of thinking and extrapolating.
I'm still not sure what to do.
So your process will select for people who love to smalltalk about stuff, they will look great. But many great engineers doesn't love to smalltalk about stuff, it isn't a part of being good at the job.
How does hiring work today? First, the employer sets out a "careers" page (which varies quite a bit, even within the same company, even for the same job title!) which includes the following banal information: A job title, part-time/full-time/remote/location-based, a company values blurb, a paragraph about the general responsibilities of anyone with this job title, a tech stack, a list of prerequisites that nobody will ever meet "or relevant experience", and maybe the benefits and perks.
Nowhere does it describe the actual project they're working on, their timelines, what kind of situation you're walking into, what the specific team's culture is like, whether there's a strong team lead or everyone is just a genius, if they're culturally diverse, what their daily workflow is, whether their OKRs have sustainability or social responsibility goals, or feedback from team members. Is the project they're working on greenfield or brownfield? What's the architecture? Will you be on-call? Will you be supporting customers or working in a silo? What is the reporting structure like? Career advancement / lateral movement? Training? Do they go to happy hour on Fridays? Is there an LGBTQ ERG?
And from the other side, the company knows next to nothing about who's applying. After all the candidates have played tech buzzword bingo in their resumes, the company (or worse, recruiter) pulls out a divining rod and tries to pick up the one or two candidates who they imagine are a match culturally, technically, and professionally. If you don't know somebody inside the company, or a recruiter doesn't push you as one of the two candidates they've found locally, you might as well be a translucent blob of Arial 12-point font.
How can we connect employees and employers in a meaningful way that isn't an arbitrary screening process? Well it seems to me that somebody has already come up with an answer: dating sites.
Please, stop throwing things at me and hear me out! What are jobs? Relationships between an employee and an employer. Well, dating sites are masters at finding the intersections where people match, in order to find good relationship matches. You can create a curated list of multiple-choice weighted questions, and ask the other person to fill them out, with a small text blurb to elaborate on your answer. The most common/popular ones automatically bubble up for everybody as default questions.
This combination of quantitative and qualitative matching would allow people to quickly see which employees/employers are the best match. We may still need a way to ascertain technical skill or professional experience, but at least the people who come in the door would appear to be the closest matches to what we want. Will there be some catfishing? Sure, but there already is with today's hiring mess! Can somebody please make the OkCupid of hiring? I'm waiting to open my account.
I know two people who found their spouse through a dating site. The first was forced to get a divorce after his wife tried to kill him and nearly succeeded - she had some mental health issues that weren't captured by the dating site. The second found his 4th wife that way, and as far as I know they're still good but I haven't quizzed him on his personal life in a while.
Economics: Thomas Greco, community currency economist https://community.intercoin.org/t/interview-with-thomas-h-gr...
Regulations: Sara Hanks, former SEC regulator and author of Regulation S https://community.intercoin.org/t/interview-with-sara-hanks-...
Freedom of Speech: Noam Chomsky, sociopolitical commentator and linguist https://community.qbix.com/t/freedom-of-speech-and-capitalis...
I don’t hold back, in the Noam Chomsky discussion I accuse him for example of having a lot of social capital (followers and influence is a form of capital that is convertible to other forms) and he brushes it off. Overall the discussions tend to focus 99% on substance, and deal with the Web, Social Platforms, Blockchain and Cryptocurrency, how they can change the world and the issues surrounding them.
PS: I know that for now no one has heard of Intercoin or Qbix or my interviews and I am OK with that. Eventually it will be discovered once our products are more mainstream. I am looking forward to interviewing Edward Snowden and a few other people next.