Leveling up in job interviews for software engineers (2022)
phauer.com
phauer.com
The best interviews I’ve ever taken and in turn, host, are the ones where we break down a problem with low code, no gotchas, little examples of specifics just to make sure they know how to write it in language of their choice. That they understand the problem, can satisfactorily break it down into actionable tasks, and come up with a solution to the problem.
Everything else: tech stack, jira, agile, culture - is company specific and should be taught to your employees and not be made the bar. If you need someone who can hit the ground running you can focus on a tech stack but ultimately it’s up to you, the company, to ensure they fit. Not the new hire.
Story time.
A few years back I was in hiring loops as an interviewer. Half a dozen engineers in my company interviewed a candidate during a morning. Everyone had their notes and we were discussing if we should hire the guy or not. Everyone gave thumbs up except one engineer. It turned out he tested the candidate on data structures and algorithms, and the candidate hadn't memorized the computational complexity of some bullshit algorithm that only shows up in lame trivia games no one cares about. Based in that, that particular interviewer gave thumbs down. We discussed everything, went through all notes, and ultimately based on all feedback the hiring leader gave a thumbs up. The data structures engineer threw a tantrum. In his opinion, we would be lowering the hiring bar if we hired a candidate that failed to meet his bar on what he felt were basic competences. The hiring leader asked how many times he used that algorithm in his everyday work. The data structures engineer answered that alas he never used it at all, but still he felt that everyone working in his org should know that.
I feel some companies don't have good hiring managers and give free reign to bad engineers who have no idea what it takes to deliver production code.
I have worked on teams trying to improve our interviewing process, and one key goal was aligning everyone in exactly what technical and personal attributes we were trying to hire for.
Even so, the data structure engineer cracked open Trivial Pursuit on the candidates and wanted to reject him based on one answer alone.
Of course if you're looking for a software jeopardy contestant maybe memory recall is important, but for the rest of us it is much better to have a good understanding of fundamentals and know where to look when it comes to specifics!
In my anecdote, the data structure engineer was indeed tasked with evaluating the candidate on his data structures knowledge. Except that the candidate had guidelines that went in the line of assessing basic understanding and proficiency in following an algorithm, but instead opted to make it a game of Trivial Pursuit.
It's always trumped up nonsense blown out of proportion. In one debrief, they made a stink because they botched an implementation of a red-black tree. it was the most pretty, trivial nonsense. The only time people are implementing red-black trees by hand are... when they're studying for our bullshit software interviews.
We also had a guy with a Ph.D in.. something. He wanted everyone to know he was very smart. Especially the interviewees. The problem he asked was so bizarre and complex that it took those of us already at the company several hours to figure it out upon giving it a try. it's just, like, dude, what is the point of what you're trying to do here? How small is your ego that you need to bully strangers on irrelevant nonsense?
For what it is worth; based on what I've seen in interviews. Programmers can only rank people who are close to their own level. If someone like Terry Davis of TempleOS fame shows up for an interview, should the interview declare them as a madman? a genius? both? If we need to build an OS, are his design choice eccentricities sly moves of genius or evidence of a diseased mind?
It isn't as much that strong programmers are a threat (that might be a factor) but more that big gaps in though lead to both productivity and inscrutability. And people avoid things they don't understand.
You can google many things easily. Understanding the answer and knowing how to apply it to different problems matters a lot more. I still expect some concepts and definitions to be remembered if you’re claiming expertise in a topic.
that's wrong?
I hate those types of trick questions.
Yes, they can Google the answer in 3s.
Yes, I could also ask a long-form question about how they would approach wrapping an IO interface in Python.
But if they don't understand `with` or resource/context management, the chances that they would produce a reasonable answer to the long-form question are tiny. They will produce an answer anyways, and it will likely be a waste of time. So we cut to the chase and target the core concepts directly.
Heck. Sometimes going into topics “not relevant” for the job is revealing. If their cv says they spent 5yrs writing Linux dev drivers but the position is to write golang web services I may still ask about device drivers if I can get a domain expert. Good people tend to understand very well the things they’ve worked on.
I would suggest anything on the applicant’s cv is fair game. What makes no sense is asking about removing duplicates from a linked list when that’s nowhere near what the job will entail.
Now trying to remember a specific algorithm like red-black tree rotation or Djikstra’s is something completely different
I specifically try and answer their questions and “hold back” a bit when answering if I can. I also sometimes will drop a nugget of knowing more and study their reaction. Some interviewers react quite poorly if you hint you know considerably more about a subject than they might want you to know.
I have friends with a lot more education than myself (PhD, masters, very senior) and they say they have to do this A LOT.
The goal is to see how the interviewer handles not being the smartest in the room about everything. This is a big deal because it can suss out whether the other person is “on good behaviour for the interview” but otherwise has an enormous ego during regular work hours.
No one wants to work for an ego maniac vetting out all the A+ candidates out of fear of competition.
My advice would be to not play mind games and just interview as yourself. Interviews go both ways, so if your interviewer is a psychopath you'd want to know sooner. Then just give the job a pass.
However, my experience with FAANg companies is: the interviewers cannot handle an interviewee who knows more, has more experience, and who comes up with better solutions to their stock 'whiteboard' problems.
Such a person should not squander his/her talents in a FAANG. That's why there are start-ups.
I will happily hire someone who’s a threat to take my job. If I don’t, I can’t ever move up either.
Yes, I know the answer is to keep them at market wages and don’t fall into the salary compression trap.
But often that isn’t under your control as a hiring manager. HR won’t give you a budget for raises. But will give you the budget to hire at market rates.
Edit: specified its specifically about the tech. The business side is a whole other thing.
If they know the technology that’s one less thing to worry about.
“what the hell were they thinking using X like Y!”
“Why didn’t they use Y here”
“Oh man, this looks like monkey patched code from 2 full versions ago, the right way to handle this now would be 1/3 the code, but oh they can’t update it because they’re mutating the data structure in order to Z… Fuck…”
Edit: Eventually, you'll come to an understanding of why it's that way, but it takes time and often experimentation.
With maturity, you realize whatever they did worked well enough to get the company to a position where they were able to hire you.
As Corey Quinn (a well known “cloud economist”) says, “legacy software is software that generates revenue”.
My point was exactly the opposite and parallel to what you said. But even with experience it takes time to decode those decisions.
The point is that it takes time to understand the whys of code that is counterintuitive at first.
Even if you are a 100% match for the technology.
When I joined a kernel gfx driver team, the expected ramp time was ~6 months. My friend working on Mesa had a >1 year ramp time!
If I open the source for a Django or React app, I can get to fixing bugs in a few days or less. It just depends.
“If you need someone who can hit the ground running…” then you need to have documented the crazy decisions that led to the awkward implementation that is your product. I have yet to meet a company who is using standard, recommended, tried-n-tested, well-known solutions to typical problems. Unless you write docs or stick to standards, no outsider has the context to “hit the ground running.”
I learned to do this when I was working on my master's, and my advisor suggested a project to me, and when I asked him for help figuring out where to start, and he told me to read through the code until I understood it, and come to him if I spent more than an hour or two stuck on things. Thanks, Mikhail - your advice was fantastic.
The best advice I've heard is "start from the data structures, they are at the heart of everything".
I like inventing purposes while reading through code if I don't have a real one. I call it "scavenger hunting" and often use it as a programming exercise when teaching. For example here is a scavenger hunt for CPython and Postgre - which lines of code would you need to touch to achieve these purposes?
https://github.com/python/cpython In json module: add parameter to load() and loads() that when True only allows spaces as whitespace characters in the json (and not tabs or newlines)
In re module, python regex has syntax for a digit (\d) and for an alphanumeric or underscore character (\w). Add \l that means "any letter".
In re module, python regex has syntax for hex escapes (e.g. \x0a), octal escapes (e.g. 0o012), unicode escapes (e.g. \u000a). Add binary escapes (e.g. \q00001010)
In python C implementation: Replace the hash function used when inserting a string key to a dictionary
In python C implementation: Add an average() builtin function (like e.g. max(), sum())
https://github.com/postgres/postgres Better string hashing algorithm for query plans that involve hashing a column
"Better column combination hashing algorithm for query plans that involve hashing a column
Some queries will want a hash on (a, b) which involves calculating hash(a), hash(b), and then combining them into combination_hash(hash(a), hash(b))"
"Add a new kind of step to execution plans
e.g. a step that logs to a cloud logging service. No need to compile it into queries, just to add the data structure for it and code that runs it when relevant so it could be compiled"
"Add gzip compression as a way to avoid page splits
Today when a page is about to be split, bottom up deletion and deduplication are attempted to keep the page from splitting. We want to add GZIP compression as a third way to try and avoid expensive page splits."
"Add a complex number column type
The column should hold a float for the real part and a float for the imaginary part"
Add Configuration Flag to Never Use Covered Index Optimization
"Add new type of index
e.g. index that runs Principal Component Analysis to index high dimensional data, but don't care about the details, just the integration points"
I've delivered every single time, but I can't do this shit more than a few times a year; I don't say this lightly: it's fucking unhealthy..
Tech is usually easy to pick up, and highly company specific. Any good engineer should be able to learn new tech, and things will change over time.
Culture is much harder to "teach". For me testing for culture fit has become much more important than tech acumen, particularly at more senior levels. You need to have a sense of at least whether the candidate aligns with the company culture, and is willing to fit.
Not doing this risks several scenarios:
a) The candidate takes a while, but finally fits with the culture. This is suboptimal but ultimately a good outcome.
b) Candidate refuses to fit with the culture. This will likely cause performance issues, and the employee will ultimately leave or get fired. Not a good outcome.
c) Candidate actively subverts the company culture. This is the most destructive outcome and can be quite damaging, particularly at higher levels.
Checking that someone will be a good fit for the company is better for both the company and the candidate.
Counter note: I've done 100s of interviews. A bro, bruh, or brah wouldn't even register as something notable to me. This is just how my younger coworkers talk.
Their use of "bet" has taken some getting used to.
Without wanting to get into a discussion of the gender-neutrality of those words, I'm not a man and everyone that I talked with there was, and it just felt odd.
Note to everyone here: Not everyone is as uptight as this guy and you shouldn't be either.
Sometimes two philosophies aren't necessarily wrong but simply aren't compatible. Choices like emphasising frequent collaboration and constant communication or async-first deep work. Mismatches there are genuine culture misfits and it benefits everyone to realise that early and move on with no hard feelings.
But a lot of ideas in how a team works are not so black and white. It's valuable to hire people who have different ideas and aren't afraid to advocate for them when the time is right as long as they are still team players who will accept a result that isn't their personal preference if that's the team's consensus or management's direction. Not hiring people like that because their personal preferences don't align with the team's current way of doing things is also a culture misfit but in this case it's a dodged bullet for the good candidate.
> On the other hand if you never hire anyone with different ideas then you'll inevitably create a monoculture that had difficulty seeing its own weaknesses and making improvements.
This is a balancing act for which there isn't a hard and fast rule, because organizations need a culture, but not all cultural values are good.
A group might want to bend on someone who is weaker on their Documentation And Testing value, but not bend on someone who is weaker on their Honesty value; but maybe they won't bend on Documentation And Testing because they view it as essential and don't want to risk that the FNG won't internalize it.
"But that isn't the cultures I object to," I've heard critics say. Of course not. But sometimes those are the cultural values that folks are trying to conserve. That's why there's no hard and fast rule.
Sometimes the cultural values are dishonesty or bigotry or cronyism, or simply an aversion to being called "bro". But often they're honesty and open-mindedness and fairness. We should not toss out the baby with the bathwater.
Maybe only about 10% of people who are sadists or calculating assholes actually follow that motivation? Unless you had a very special sample pool. Most interviewers i've met - both good and bad - were just trying to do what they think is right, with varying degrees of competence.
"The tech stack in your CV should NOT look like this: [fig of bullet points of techs]"
Why not? In resume screening they look for keywords. You need to list the thing they want.
"If you have worked with a technology years ago, your experiences is not up to date anymore. Tech evolves so fast, and you get rusty and forget things."
This is a trope. Tech hardly move at all and it is way faster to refresh, dunno, 8 year old Java Spring experience, than learn it from scratch. The hiring manager might believe that you need recent experience though ...
I think - what he meant was - only to include ones strongly applicable to the job.
It depends if you want to work for a company that hires based on keywords on resumes, or one where the hiring manager reads and understands resumes. In my experience the second type of company is a lot better to work for.
Source: I don't do this, and basically never get a call back from anyone using Taleo, but almost always get call backs from Big Tech/startups with humans that look at resumes (tbh I suspect my pdf format also causes issues here).
Also, what is a "tech company" to you? Does making SW & HW scanning and moving devices for the semiconductor, automotive and shipping industry not count as "tech"? I feel like SV has stolen the word "tech" from "technology" to now mean "disruptive VC funded mobile web start-up founded to make money on advertising, skirting regulations and tracking users", the same way cryptocurrencies have stolen the "crypto" from "cryptography".
That being said, a lot of my roles have come through external recruiters so maybe that's what saves me.
It's odd that Ireland wouldn't see the same spamming though, given that we're an English speaking country with lots of tech roles.
Also external recruiters don't use autolatric filtering systems since they usually just fish people via LinkedIn. It's mostly the companies own application websites that use these systems as they're the ones getting spammed, not the external recruiters.
Which is odd, maybe something to do with the fact that Ireland isn't in Schengen?
This was pre-remote work. Even now, I wouldn’t just random work with recruitment companies. I work with people. I would reach out to a recruiter on LinkedIn and start a conversation.
Honestly though, at this point in my career, I doubt that I would ever go through a third party recruiter again just because I do have a network.
Must we always presume malice? I'm so tired of this piece of conjecture.
Big companies have layers of candidate filtering because of _scale_, not because they unanimously and comprehensively don't know how to do hiring in the right way.
I can see how this might look malicious from the POV of someone who hasn't been involved in every part of the hiring process (as the OP clearly hasn't) but it's no coincidence that the most respected companies with the most talented engineers all read from the same hymn book.
Anyone involved in hiring on either side of the table also needs to understand that companies aren't looking for their soul mate in every role they hire for, and that noone is sitting around pondering the 10x dev who might have been.
Good enough processes for getting engineers/hires of the desired quality or higher: this has always been the goal. Anything more is corporate masturbation; something to scoff about in LinkedIn posts and appeal to those who, as I said, must always assume malice.
On top of that, once you “get in a position of f*%# you” (https://m.youtube.com/watch?v=xdfeXqHFmPI) your shit tolerance level starts going way down.
I've found that engineering culture rarely matches how HR/recruiting works, especially as companies grow but even in startups often times.
I think any reasonable hiring manager understands why resumes are blend buzzword essays.
I agree with this. One way or another, as an interviewer I need to know what your skill/experience set is. Skills/experience can always be developed, but that should be a known factor at the point of hire.
One positive point that TFA made was the need to 'Listen Carefully and Answer on Point'.
As someone who interviews regularly, I cannot count the number of times that interviewees have not followed this simple advice. To the question "Give an example of when you last frustulated a gibbet..." they will describe in detail their general thoughts on the many finer points of gibbet frustulation, but not actually give an example.
Also, be "Concise and Offer Details on Demand"
Top tip: when you have finished answering a question, stop answering the question.
You don’t truly know what you would do in a situation until you’ve been tested.
> You don’t truly know what you would do in a situation until you’ve been tested.
I had an interviewer ask a broad "What can you do with X" question, and my mind went blank.
Five minutes later, he asked about solving a problem and I said "Well I would use X to..."
Open-ended "give me an example" questions are not a situation folks encounter in their job. It's entirely an interview question.
It's entirely a shitty interview question.
https://managementconsulted.com/amazon-leadership-principles...
While they are grouped by the Amazon LPs, they are more or less standard soft skill behavioral questions. Almost all of these questions have been relevant during the latter part of my career as the dev lead (2 jobs ago), the de facto cloud/enterprise architect (my last job) and my current job (cloud consulting department).
These are also the standard type of skills you need in most senior dev positions where they are filtering on “scope” and “impact”.
My last three jobs since 2014 before my current one have all been based on my ability to navigate behavioral questions and just have conversations like adults to the hiring manager (department head, IT director, CTO) where we talked about their real world problems and how I would solve them.
If you've learnt all that, you can learn to use more.
At most I would detail what you feel your expertise is and what other skills you have that the company is asking for. Have you programmed in C# for 5+ years and continue to do so? You might think you're really good at it, so make that point.
Did you use React for a little while and the job asks for that experience? Mention it.
Did you use OCaml 5 years ago and not touch it since? Probably don't mention it.
CVs should always be tailored for the job. It's not a life story, it's an advertisement. Car advertisements don't list page after page of tech specs. They focus on the key things they think are selling points. You should do the same for your CV and that will change depending on the requirements of the job you apply for.
From my experience, at least in Europe, companies are paying the most for people who can "hit the ground running", i.e. being able to contribute from day one - both in terms of code as well design/architecture decisions. That neccesitates knowing their exact tech stack.
I may not be able to refactor the system to use micro services or whatnot, but to dig into the code and start fixing some bugs or even add a small feature has always been a week 1 goal for me (and one I set to the people I manage now).
If you have a less popular tech stack then you need to be more flexible. You aren't going to get a lot of developers that know everything and you will need to look at how adaptable they are.
Where I work we don't particularly care about specific experience with our stack. A good developer is a good developer regardless of the stack. And we set aside time for people to get comfortable with the code base. It's not expected that even seniors come in and make contributions on day one. Obviously it's more generous to juniors and mid level developers.
That's why I said list what's relevant to the job, but don't list your entire life story there. If you're an expert that can hit the ground running, then make it known. But if you're applying for a front end React role and you're listing PHP experience from 5 years ago, it's probably not relevant. You can use that space to detail more about what you're good at.
I never tailored the cv to each job as that would take way too much time, especially as you get more senior. As a junior developer, sure, it might be worth it because you might get offers from most jobs you apply for. Nowadays I would have to apply for dozens of jobs to find a good fit.
This might only apply for EU and UK though, I imagine things are a lot better in the US
How many jobs are you applying for? It's harder when you're a graduate looking for a job. When you're senior you're probably only applying for a handful of roles that caught your eye and it only takes 10 minutes to refactor your CV to make it more relevant to each company.
As a senior, you have to apply for lots of jobs because most the jobs you apply for won't hit the requirements (for example, salary). For reference, I have 15+ years of experience so I'm fairly senior for the industry.
The last time I thought about getting a stable job I got quite a few interviews but most of them were offering £100 to £120k which I consider fairly low (I was making that in 2014...)
It's honestly quite a waste of time, I don't know how much different it is across the pond but I imagine it's easier over there, considering the kind of comments you read on HN and such
I got flooded with job spam that way. As a signal-to-noise ratio, I would much rather strip all the keywords from my CV and get an occasional cold call (or e-mail) than wake up every day to a mailbox full of jobs that are not related to what I've done, but matched some keyword on my resume.
Q: Do you have experience with Ansible?
A: yes I do I've written custom functions and extensions
Q: do you know python?
:/
If you stuff your CV with a contextless list of random tech keywords, half of which are things you did a "hello world" with years ago, the interview is now a game of Russian roulette, and the gun is aimed at your face. Sure, you'll pass the resumé screening, but at what cost? You're leaving a lot to the interviewer's imagination, and what they imagine you should know is not necessarily what you know.
"So, your CV mentions you have MongoDB and DevOps experience. We're actually having some weird issues with it recently, it seems that under very intense loads, some of our nodes get locked and time out, and then the cluster loses quorum. Do you have any thoughts on what we could do?" It sucks to get a question like this, when all your previous experience in the matter is that you pressed the "create instance" button in the Atlas UI three years ago, and decided that was enough MongoDB-ing and DevOps-ing for a CV bullet point.
You can prevent this by showing those tech keywords in the context in which they're relevant. "Created and deployed an online application for candy bar enthusiasts, using React, NestJS and MongoDB on the cloud". Now you might get questions like "I see on your CV that you worked on an app for... candy bar enthusiasts? Could you tell me more about it?", or, "Your CV mentions that you built an app using MongoDB and NestJS, how was the experience of using MongoDB in a Node application?", which you are more qualified to answer. By adding relevant human context to what you did, you guide the interviewer towards the questions you'd want them to ask.
In an interview I would hope to talk more about the more detailed parts, but it feels like I need the tickbox stuff to get to that point.
Only moving to companies where I can get an internal reference seems very limiting...
I specifically look for companies where they want someone to be hands on. But also lead initiatives as an individual contributor. It traditionally has been at smaller companies (since 2008).
Those types of jobs don’t come from submitting my resume to an ATS. I have to either use my existing network or reach out to someone directly at LinkedIn.
That said, if you optimise your CV for success in recruitment processes where no one understands what you're talking about, you will get jobs at places where no one knows what they're talking about.
FAANG dependent, of course, but at mine, we've got competencies assigned ahead of time, we drill into those, ask our pe-fab questions, and move onto the next interview. There's just no time to thoughtfully read resumes.
You should be ashamed of yourself.
If you’re an experienced developer and still randomly submitting your resume to an ATS instead of depending on your network you’re doing it wrong.
I have never in 25+ years across eight jobs randomly submitted my resume to an ATS hoping and praying someone would find it based on keywords. I’m much more strategic.
Yes, I’ve applied for (and currently work) for very large organizations.
Sure for a lot of jobs you have to submit your resume to an ATS to start the process. But I only do that as a perfunctory step after talking to someone who is already looking for my resume in the system when I submit it to start the process.
> This is a trope. Tech hardly move at all and it is way faster to refresh, dunno, 8 year old Java Spring experience, than learn it from scratch.
I last wrote a line of C# in 2020 after doing C# in for over a decade. But the last time I was in the weeds as a heavy C# developer was probably around 2018. Even in that brief amount of time, I know that the ecosystem has gone under changes and what are considered best practices have changed. More importantly, new features and frameworks have been added.
1. I got the job based on a previous internship that itself was based on talking to people in the career office in college. (1996)
2. I talked to someone at a local recruiting agency and went to the office and met them in person (1999)
3. I found an interesting looking job on CareerBuilder for a startup and reached out to the internal recruiter via email and we started having a discussion (2008)
4. When that company was folding, a couple of recruiters reached out to all of us and I was hired four days after I was laid off (2012)
5. I reached out to an in house recruiter on LinkedIn where the manager was looking to start a “tiger team” of experienced developers (2014)
6. I had plenty of recruiter i knew by now. I responded to every local legitimate recruiter who reached out to me. I told them what type of job I was looking for (a tech lead position at a smaller company) and just waited for the right opportunity. I found it in 2016.
7. The same for my next job, I was looking to work for a company that was doing new “cloud initiatives. I asked all of my recruiting contacts to be on the lookout. The recruiter I met in 2012 that I had stayed in contact with knew a guy who was the newly minted CTO of a startup that was trying to bring development in house and be “cloud native”. Before they were using a contracting agency. (2018)
8. A recruiter from Amazon Retail reached out to me about a software development position. I really wasn’t interested in relocating, working as a software developer for any large company or ever being on call. I kept talking to her and she recommended I apply for a position at AWS ProServe. But even then, she shepherded me through the process and made sure my application got looked at by the right people.
I didn’t just blindly hope for a keyword match (2020)
And btw, in my entire career, I’ve done exactly two coding tests and both of those were FizzBuzz level sanity checks.
Then I "do it wrong" about half the time! There's a lot of tech out there to explore and if I'm only tethered to my (now many-)siloed network, I'm not going to see it all.
Honestly, hiring "networked" people is also hit or miss. There are a lot of decent IC devs with meh friends; combine that with scattershot hiring practices. And I've seen creepy empire building happen via external hires of networks of friends before, too.
I don't think there's a silver bullet.
Can you share any additional details about what the process actually looked like or what type of task you were actually performing in the interview? Size of the project (~LoC), tech stack, complexity of the feature, etc.
"Good candidates now ask many diverse questions about the team setup, role expectations, challenges, the tech stack, career and mentoring opportunities, work times, etc."
And if the interviewer doesn't like these questions, because they have too much ego in this? Because I can't actually ask good questions because I don't have enough knowledge of the inside of their company (other than off the website, which is their public face so they're going to be distinctly partisan about how good they are), whereas they have a potted summary of me in front of them in the form of my CV?
Or if they out right lie about the tech stack, the "career and mentoring opportunities", how fucking bad the management is…?
Because this is exactly what happened at a number of companies I've interviewed for, and most especially the one I'm working for now.
My experience is you make yourself look cute and cuddly, don't challenge too much (eg. don't ask if they have an bug tracker because often they don't[1] and they'll get irritated).
Great advice for an ideal world, not this one.
[1] And if you find out they do have one, especially don't ask if they actually use it.
Maybe you're OK navigating around that person, but many are not, and I'd rather not have to bother.
Yeah, there's only so much you can glean, but just like they're looking for red flags from you, you're looking for red flags from them.
But even that’s irrelevant because of turnover and reorgs, you’re not likely to be under your current manager for long.
At the same time, the "candidate asking questions" portion is 10 minutes if you're lucky, and it's between two strangers who've known each other for maybe 45 minutes up to that point. It's understandable why the interviewer might give canned answers.
I think it's still worth asking the questions. The Joel Test [1] may be older than many candidates these days, but a large number of companies still fail most questions.
For the trickier questions, I think you have to read between the lines and look at what's not said. If you ask about work-life balance and the interviewer gives a little "hah" before answering — well, there's your answer. If you ask about the build system or deploy process and they keep hand-waving — well, they're still telling you something very important about the engineering culture.
[1]: https://www.joelonsoftware.com/2000/08/09/the-joel-test-12-s...
I wouldn't even bother asking because the answer is obvious. Everyone has it. Until I started at my current place. They don't and they're not interested in getting it. Idiots.
Next interview I'll brush up on those 12 questions. Thanks.
In my experience, building strong relationships and networks within the industry has been far more effective in securing meaningful employment opportunities. Rather than focusing solely on perfecting your interview skills, I would encourage folks to prioritize developing their network and cultivating relationships with potential employers.
I stopped reading there. Does the author know before your resume even gets to an interviewer that it will go through keyword screening software then be reviewed by HR and binned, all long before a hiring manager sees it?
But even if that’s the case, I’m still going to use keywords as part of the narrative.
“Using <technology> accomplished <result>”
A human can see I learned different tech for each job, and other tech has been mastered and is re-used over the years.
I've stopped interviewing for corporate jobs until I can get my money up. Probably an easier hurdle to overcome in some ways, since I can pay my homeless away with temp jobs and have a clear path to acceptance: nice shoes and clothes, reliable phone service, a presentable and quiet place for video calls.
There is a real cost to each interview, otherwise it'd be easier to just keep doing them and count each instance of discrimination as a data point and assistance in helping us avoid an environment that isn't a fit.
A funny thing is that people used to think I was gay because I presented myself a little too well and was a little too gentle in my attitude or something. Now I'm out here doing construction demolition and I'm a little too rugged looking to make my old friends comfortable.
Best wishes to everyone who has a hard time finding an environment where they fit.
But when I was interviewing at your normal corp dev or startup, I would purposefully try to squeeze in tidbits about my personal life to hint at how important I found work life balance so companies who didn’t respect that would filter me out.
If I show up and it sucks, I'm just going to leave anyways, so... seems better to just be super clear that the salary buys you normal work hours. Want more? pay more.
This misapplied market research that tries to make jobs "cool" (upskill!) gives me powerful Ballmer "I love this company" vibes.
Once you get them, unless you've been perpetually practicing for a year or more the odds you pass are slim to none.
Even worse for CTOs. If you make the development look too easy your CEO will wonder what you even do.