What kills me is the fact that the interviews (especially the technical ones) go in depth into topics that aren’t ever pertinent to the job. It’s simply so the interviewer can rank you vs themselves. You need to be good but not too good you’re a threat.
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.
Yeah, I try and background check my interviewer thoroughly because of the “threat” issue. I always ask who will be interviewing me and look them up.
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.
I have done 300+ interviews in a 13 year career in FAANG companies and anytime I get a sense a candidate knows more than me, I get all excited and will work extra hard in the debriefs to get the person hired. If the spot is for my own team, even better ans will nudge my manager to hire the candidate. The prospects of learning from the person on the job is too enticing.
Good for you! Andrew Carnegie said something like "I don't know how to make steel, but I do know how to HIRE the men who do!" He wasn't threatened by competence.
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 never heard about having to do this during an interview, but it sounds concerning.
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.
> What kills me is the fact that the interviews (especially the technical ones) go in depth into topics that aren’t ever pertinent to the job. It’s simply so the interviewer can rank you vs themselves. You need to be good but not too good you’re a threat.
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.
This personality defect is painfully common. They view themselves as "the bar."
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?
That’s why you need experienced hiring managers. The questions should be discussed and approved before the interview. You just don’t let an engineer ask whatever they want. An interview plan needs to be shared to avoid overlapping questions or topics between interviews. In this particular example the hiring leader did the right thing, only after doing the wrong thing: not review or having an interview plan discussed beforehand and training the interviewers. The interviewing principles need to be clear to all your interviewers.
> You just don’t let an engineer ask whatever they want.
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.
That is a major problem in interviewing. Everyone has their own set of internal guidelines!
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.
In my anecdote, we already had very explicit and rigorous guidelines. We had goals, evaluation requirements, question banks, and more importantly post-interview meetings where all interviewers matched notes and we're tasked with gathering data on topics that overlapped the responsibilities of other interviewers.
Even so, the data structure engineer cracked open Trivial Pursuit on the candidates and wanted to reject him based on one answer alone.
Yup, some people just seem to have a hard time with evaluating candidates fairly rather than by some arbitrary guidelines inside their head.
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!
“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.”
Expensive because, under deadlines, it's a bit of a nightmare to have to twist your mind into all these shapes (and shatter a few times because your first couple passes of understanding are going to go so right until they go so wrong) until whatever you're reverse engineering finally clicks. It's even better when you feel you're just at the cusp of delivering a new feature on top of what you reverse engineered, and you realize you're missing a skill and have to level up your knowledge to inside of a couple days (oh, and dont forget the times when you think you've learned just enough of that skill to deliver and realize you need to explore an entire subfield of that skill to truly deliver).
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..
Last three times I've joined a new team (2004, 2015, 2017) I spent my first week trying to fix tiny bugs and generally just reading my way through the codebase till I understood what was going on. I highly recommend it.
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.
That only works if the code was written in a semi-digestible format; I've met my fair share of monstrosities that were propped up by race conditions -- you're not going to briskly digest them in a week (especially if you're in the unlucky circumstance of only having a single breakpoint per run and the engineers who had any understanding of it haven't worked there in 20 years).
Test cases can be a good place to start because they are usually clustered around business critical functionality. Or problematic legacy code that needs to work :)
I wish that was an option for at least half the codebases I've worked on. Tangent: you'd be surprised how many life threatening codebases have little to no tests at all.
Test cases? I still feel lucky to discover that a new (to me) project is even using source code control, let alone has some kind of test suite, let alone one that it currently passes.
Reading through a codebase without a specific purpose is a very slow way to get up to speed.
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())
"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 conducted hundreds of interviews and I agree about the tech stack, but disagree about culture.
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.
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.
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.
> > 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.
> 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.
I recently interviewed a candidate that seemed solid technically but kept calling me bro. I’m pretty laid back but that was a fail. Note to everyone here: don’t do that.
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.
I haven't had that happen, but it would be refreshing. I would be really weirded out by a "sir" though. casual environments where people can just work and not worry about wearing a persona are nice.
I think the use of "sir" depends on the person's background culture. If you're from the US, it's probably too formal unless you're in the military or something, but other cultures place a higher value on respect for authority. I've had people not originally from the US call me "sir", and while I make sure they know they don't have to, I also don't worry about it.
I would also be weirded out by sir. I say dude a lot but I wouldn’t throw that out like a nervous tic in an interview—it’s a little too familiar and doesn’t exactly reflect situational awareness.
I recently interviewed at a place where the interviewers kept calling me bro or dude, so maybe they'll match with each other at some point.
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.
The same sort of problem exists across generations. I've had a few meetings with potential clients for our business who were quite young (sometimes literally but certainly culturally) and it felt like they were speaking a different language. When that language sounds like sound bites they probably heard on TikTok last night and yet somehow conveys no useful information whatsoever it's usually a good sign not to pursue that deal any further! You don't have to be all stuffy and formal but professional presentation and effective communication are valuable skills. I can only imagine what they must sound like when they're interviewing potential employees for their own business.
It depends what company culture actually is. I have worked at companies where documentation has been frowned upon – I'm not exaggerating either. That is something I most definitely will try and subvert.
With most employees not staying at a job for more than two years, why wouldn’t you hire someone who can hit the ground running? If they spend six months doing negative work ramping up and leave in two years, your investment in them didn’t go far.
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.
Sure, it's most dependent on the age of the company/software. The older, or lower level the code, the more hacks and workaround that appear in a codebase.
And you can know 100% of the technologies they use; open the repo and still say,
“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.
That wasn't the point. You missed the context or something. Those were just examples of initial thoughts that come up when starting to understand a new codebase.
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.
Sounds like HR shouldn’t be in charge of deciding engineering salaries and raises. Seems like HR creates more problems than it solves. Time to reduce the scope of their roles.
that number comes from their hiring spree when around 20% chunk of their workforce had 0 years of tenure, the data was pulled from LinkedIn and includes all employees or people claiming they are employees
Personally I really dislike very specific questions you can Google an answer to in 3s and consequently no one remembers it while doing an actual job. IMO when it comes to verification of actual technical ability the candidate should be told an example of an actual task she/he would be expected to complete routinely and they should either do it during the interview or explain how would they go about doing it.
One question I asked recently was "what is the `with` statement in Python for?" If they ask for clarification I'll mention related terms like "context management" and "RAII", which we could discuss without Python syntax.
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.
I get what you mean I think. However if you’ve been doing C dev for several years and you “don’t remember” what a static variable is and when to use it (or not) is not a great sign. Cumulative signals is what determines hire or no hire, not a single “wrong answer”. Even when a candidate doesn’t know an answer you can get useful signals. If you give them the answer or hints and see how they react or a follow up question after giving them the answer.
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.
Static variable sure but there are many other examples, like returning a C fixed-size array from a function. I had this question asked and they specifically insisted on being compliant with the standards and not using an out-argument. This is a ridiculous question.
I guess my point is that what you really dislike are niche pedantic gotcha questions, not 'very specific questions you can Google an answer to in 3s'. I fully agree with that btw.
Being pedantic about standards and expecting people to recite them perfectly as a way to assess skill or seniority is what is wrong. Even when you are implementing a 'standard' there's room for robustness principles (liberal in what you accept, strict with what you send) that should be weighted instead of blindly following a 'standard'.
No, but this is a very niche thing to know and if I remember correctly gcc has a widely used specific extension for that which would not be accepted in that case.
I’m not going to justify going in depth in topics not relevant for the job. However going deep in tech topics is necessary to evaluate experience and seniority. The “best interviews” process you described is adequate for the first eng levels but if you want to interview for senior, staff, principal; etc it gets harder and going into depth and breadth is necessary.
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.
‘going into topics “not relevant” for the job is revealing‘
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.
> so the interviewer can rank you vs themselves. You need to be good but not too good you’re a threat
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.
Yeah - my last interview was a bit like that. Uninteresting, lazy factorial question, some syntax bits on Python, can you list some canonical definition of object orientation, no probing at all on any topic of interest, and then a brief trivial squabble on what a list comprehension is.
This definitely rings true to me. We give an interview that’s basically a simple parser, and ask candidates to do it recursively(in Elixir) using function head instead of Enumerable. We link to the relevant docs and it’s a paired exercise with tests built in. It’s generally been a good predictor of candidates ability to work in our code base and collaborate. The whole thing can be done in 50loc and is not meant to be terribly hard.
> You need to be good but not too good you’re a threat.
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.
That’s why assembling an interview panel requires some finesse. How senior the candidate is expected to be needs to be calibrated and interviewers selected accordingly to seniority and domain expertise. Not always possible, so it’s always imperfect. Assessing performance is really hard, even more so with limited interview time that requires determining not only hire or no hire, but also level and compensation.
"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 ...
A resumé is a tool for you to guide the interviewer, and you should use it for your advantage.
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.
At least in roles where I have sent out a resume, including keywords was less about the interview, and more about passing the not necessarily tech savvy hr or external recruitment process.
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.
To be clear, the keywords to tick the boxes are all still there, just presented in the context in which you used them, which adds additional meaning and qualifies what you mean by "having experience with X" to an informed reader. My CV has them in bold so that the HR person won't miss them on a quick scan.
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.
Why are you even in a position where you are dealing with HR as a filter? By the time my resume gets to the ATS, someone who is in the hiring chain already knows to look for it or at least I’ve gotten an internal referral.
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.
And once you break the can’t get a job <-> don’t have experience cycle, you should be forming a network from day one. That network can start with third party recruiters who you reach out to on LinkedIn.
FWIW, at least in my corner of the world, nobody is actually looking at your resume let alone being "guided" by it.
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.
I particularly love these hour long interviews where I've had to fly half way around the world to spend an hour answering shitty questions from some completely unprepared lazy asshole like you who hasn't spent 5 minutes reading each resume.
My first boss in tech made us all perform interviews. He always used to say that if it's on their resume, it's fair game passcode. We wouldn't judge you for not knowing something, but we would judge you for saying you need something that you didn't know.
Listing all the tech you've worked with is pretty pointless in my opinion.
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.
Yeah I used to think like you, but I kept getting screened out of interviews because my cv was missing keywords. Then I listed every technology I ever worked with and suddenly I was getting interviews.
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
> Then I listed every technology I ever worked with and suddenly I was getting interviews.
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.
>I never tailored the cv to each job as that would take way too much time, especially as you get more senior.
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.
My experience has been the complete opposite, as a junior you are less picky and pretty much every role hits your requirements so you apply for a couple jobs and get offered most of them.
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
> If you've learnt all that, you can learn to use more.
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.
Kind of funny given that a sanely factored system with minimal dev dependencies can have anyone writing code on the first day, and other systems involve reverse engineering insane build systems after waiting a couple of months for VPN access to be granted.
It depends on the company and the tech stack. If it's an in demand stack with plenty of candidates then the most capable of hitting the ground running will win.
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.
How does that even work though. "Hit the ground running"? It takes me months to get into a codebase and such a small thing as get it to build might be a multiple week hurdle if the guy you replace is gone.
Is this a US/SV thing? I hear it here over and over but in 20+ years of professional development (Europe + US/Canada remote start ups) never I needed more than a week to start working on a system (usually is 1-2 days that are mixed with onboarding sessions as well).
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).
What stack are you working with? With Node/React I (as a fullstack) could run most projects in 10 minutes, with about 4 hours for the worst offenders with local kubernetes and aws authentication. And I usually merge my first PR on the first day.
I used to think this way until a few phone screens where HR asked me about having experience with X but also ask me about Y and have no idea X and Y are related. Aka:
Q: Do you have experience with Ansible?
A: yes I do I've written custom functions and extensions
Why not? In resume screening they look for keywords. You need to list the thing they want.
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.
> It depends if you want to work for a company that hires based on [X]
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.
What criteria are you using to define 'best'? I'd have thought "can't be replaced with a simple regex" would be a reasonable heuristic, but if you're right then that can't be it...
I only worked with local recruitment companies back i the day. I’ve met plenty of recruiters in their office an for lunch.
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.
In no desirable company has the hiring manager enough time to read every resume that comes in as they get spammed with them. They all go through an automatic filter, then an HR/recruiter filter before reaching the hiring manager. So if you don't pass those filters you're not getting to the hiring manager.
This is not true. Basically only large, non-tech enterprises use the keyword stuffing automated scanning process.
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).
Not the case where I live in Europe (German speaking countries). From what I've been told by people in HR, lot of people desperate to emigrate from Africa and East-Asia will spam every tech company with applications even if they don't fit the job requirements or the company doesn't offer visa sponsorship so even small-ish companies use automated filters as they get too many applications that don't fit the job description and overwhelm the short staffed HR department.
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".
Did you ask them about it? Maybe it's not something they just bring up?
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.
Given that I've hired a bunch in big tech so have been talking to recuiters very often (and that I've done LinkedIn sourcing for said companies) I honestly don't think this appears to happen in Ireland.
Which is odd, maybe something to do with the fact that Ireland isn't in Schengen?
> In resume screening they look for keywords. You need to list the thing they want.
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.
I hate the "give me an example when" questions because as soon as I hear them I forget everything I've ever done lol. Also, they can be so ridiculously stupid, "Tell me about a time you worked well under stress?" Like, why can't I just tell you that I'm not going to lose my shit when it hits the fan instead of playing stupid word games.
Second this. I've taken to studying a list of previous examples because I frequently can't dig up ideal examples from memory on the spot. A touch of adrenaline from nerves, even if not obvious to others, really affects my performance in this way.
The merit of a 'give me an example' question is that it evidences a degree of self reflection in the candidate. Specifically, that they can abstract their daily circumstances to produce general truths regarding themselves. This we should all be doing regardless of whether we are preparing for an interview.
I passed a 5 round mostly behavioral interview loop at AWS (cloud consulting), I could answer any of these questions except 6 (I’ve never been a manager) and 15 and 16 (they are new) based on my prior experience.
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.
> Why not? In resume screening they look for keywords. You need to list the thing they want.
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.
I've actually never gotten a job via my network (besides an "internship" driving a forklift in a warehouse), and have worked at startups and big tech companies just from applying on the website. I wouldn't discount it!
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.
I’ve gotten jobs both ways. Ironically(?) the one I liked the best was when I applied randomly online and the one I hated the most was through my network.
> 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.
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.
The advice on this is all over the place. It comes down to a matter of to whom you should appeal. Are you trying to pass an HR filter so that a human actually reads the resume or do you appeal to common sense and write a resume actually intended to be read by humans but immediately rejected by HR staff?
I agree. I’m a contractor and I feel the tech list allows the client to know upfront what I know out the gate and what I don’t. They can make an informed decision around who they want to get in for their project.
The best interview that I ever experienced was when I applied for a Software Engineer position at VMware. The interviewers brought a laptop with an IDE and a project with a bunch of source code (based on one of their real in-house projects), and the task was to understand the exising code base and add a few new features to it.
A real everyday task, no crazy algorithms or other menthal gymnastics.
Assuming an interview is a typical 30-60 min time slot is this actually a realistic ask? It seems pretty crazy to 1) get up to speed on a codebase and context in such a short amount of time to 2) then be able to actually develop against the codebase in a meaningful way to add more than one feature to it.
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.
2 hours slot was allocated for that task. There was an API that I had to use to perform some operations and that made the task easier, as there was no need to study the entire code. C was used as the programming language, with a few thousands lines of code total. I completed the task in 2 hours successfully. I liked the fact that this method required zero preparations from the candidates side, and tested the actual abilities to code, as opposed to solving abstract problems.
This is naïve and looks like the guy doesn't have all that much experience
"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.
Sounds like you've had some rough interviews. I think you're also right, though; it is generally rough out there these days.
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.
I haven't seen that list for a while and it's a good one. Looking at it now it's even better because point 1 is: Do you use source control?
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.
I would actually argue that the best jobs are rarely advertised or filled through traditional interview processes.
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.
That's completely true! But... that can make it very hard. I personally struggle a lot with socializing and networking for personal reasons. However, I would say I definitely have useful skills and would consider myself very employable. But I simply cannot compete with someone who has better social skills, regardless of skill level.
You're probably not going to walk into a 450k/yr job through networking and connections - just saying. Those will require a traditional interview process, I can almost guarantee it.
> First, you need to understand how a hiring manager approaches an interview.
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?
I've worked at dozens of companies, startups and big tech, none of them used keyword screening, none of them got reviewed first by HR. I'm sure it happens at some places but certainly it's not 100%.
On my resume, I use English descriptions of what I did to develop business-level features. At the end is "Keywords: Python, AWS, Kubernetes, Terraform" for the keyword screening software.
A human can see I learned different tech for each job, and other tech has been mastered and is re-used over the years.
We are told at BigTech interview training that if a candidate starts talking about any area that is protected, immediately change the subject.
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.
Are we supposed to be that subtle? I've just been bluntly asking "what is your work/life balance?" "how often / at what times are you paged?" and other super direct questions.
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.
Or homeless and the interviewer is a homelessphobe. Trying to be additive to the sentiment, not take anything away.
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.
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.