Lessons from a tech job search
blog.nindalf.com
blog.nindalf.com
In the past, as a hiring manager, my best hires by far came from a recruiter that I trusted. His hit rate was amazing. He spent hours interviewing people himself and by the time they came to me for an interview, it was because he already knew they were qualified.
In a world where people jump every few years, hooking up with someone like that seems like it could work out well, if they've built up a decent reputation. Basically like a good contracting company, but for FTE. Instead of multi-stage interviews at 10s of companies (or more), everyone on both sides of the process could save a lot of time and get down to the nitty gritty.
Just spitballing. I am only halfway through my cup of coffee, however. And clearly things like this have been tried, but always on some kind of large scale, which in turn destroys the effectiveness -- because it gets gamed, I'd guess.
But at a much smaller scale, does it work, do people do it?
If you don't know what to look out for, bad recruiters can frequently come off as better from a candidate's perspective. They get you more interviews, and they won't tell you to pass on an offer because the compensation is too low. You generally don't find out that the job would be a poor fit until you interview, and you won't find out that you're being underpaid until you've already started (if ever).
(No, a government employee doesn't particularly care about someone they just met, either. They have their own incentives, too.)
Even if they did it often depended on what I was working on at that moment. The might be the best backend rails engineer I've ever worked with but if I'm only working on front end react roles I'm not going to have anything for them.
Because I had relationships I could call past clients who I know needed good rails folks and pitch this persons background but they would open up a role maybe 25% of the time?
It's just difficult because third party recruiters don't really control the roles they work on.
Years ago, recruiters seems to have a line on positions I had never heard of. Nowadays when recruiters contact me, they are already about positions I know of on Linkedin etc. Maybe with more people working from home (including me) this might change.
One thing recruiters can still good for is post-interview feedback. Some companies feel more comfortable giving it to recruiters than directly to you.
Echoing this. In fact, it holds true even for in-house company recruiters, as long as they feel you are a reasonable person and are comfortable disclosing it to you (without fearing that you will start causing problems due to finding out this info). Yes, even FAANG-level recruiters can be ok with that, but that's on a case by case basis.
I personally noticed that over the years (as I got better at interviewing and at communication in general), recruiters themselves would start going "technically I shouldn't be telling you this, but..." more and more frequently. And no, I never asked for "more detailed feedback", they just decided to volunteer it themselves. I can imagine that asking it directly would have been fairly awkward, ("but can you give me the real feedback instead of what you just gave me?")
And the wild thing is that they weren't bsing or just giving me generic "sorry it didn't work out, practice your algos and systems design more". They would give a pretty detailed feedback, half of which would match the stuff I already knew about my performance on those interviews (e.g., "I felt I did poorly on interview #3 due to me not being able to efficiently optimize this one approach and then maybe being a bit too vague during systems design round in the beginning"), which acted as my personal litmus test on the legitimacy of the feedback. And with the other half being brand new information that actually opened my eyes to some blindspots I've been totally missing.
Ime they are somewhere in the neighborhood of Car Salesman, trying to get their commission at all costs and bringing jobs that are only tangentially related to my experience to the table.
So now I focus on filtering the 5-10 new recruiters that contact me through linkedin in or my email every day down to the positions I'm actually interested in.
This isn't true, of course, for ALL recruiters, but definitely most. So as you can see, the only downside of finding a really good recruiter is that because they are good, they won't necessarily stay an individual recruiter forever. And the bad ones? Well, they churn and burn out relatively quickly.
Apple - lots of evidence it's a toxic work environment, highly secretive. Maybe not an instant veto, but skeptical.
Deliveroo - Gig economy gets a veto from me.
Uber - ditto, if anything, even worse.
Spotify - Would have once upon a time, but these days they seem pretty awful, and their front-end tech is sorely lacking, to say the least.
Amazon - intensely and notoriously abusive to employees at all levels.
Netflix - high-pressure work environment not for me, some disturbing practices.
Palantir - state-sponsored spying, no thanks. Lives up to its name.
Google - mostly an adtech business at this point. Skeptical.
Meta - I'd rather be homeless than help Meta do anything for anyone.
The places above, I'd be reluctant or outright unwilling to ever even bother applying to. That leaves Babylon, Cloudflare, Monzo (where the OP was hired), TrueLayer, Instabase, Microsoft, Shopify, Wise, Revolut and JP Morgan as orgs I didn't immediately veto or view with high suspicion, and I still view the several related to finance as inherently pretty suspicious.
I can't be the only person out there with a robust "will not work for" list. Fortunately, there's no shortage of tech companies. How do people filter out companies when considering who to apply to?
I also think this is part of the reason salaries at these companies are so high (exceptions aside, they're generally higher than at less evil companies). If they didn't distinguish themselves on salary, people would always go with the underdogs which may not be as corrupt yet.
Microsoft, to be honest, I'd still be open to. Their anticompetitive behavior is a big issue, but I don't know that I find them to be as 100%-tainted by it. With Microsoft I'd be more concerned about lack of quality control or care for end-users.
I almost only conduct PM / technical design interviews now, so I rarely get to go into that much depth with candidates (don't expect PM candidates to get nearly as far as dev candidates), but that looks like an ideal breadth and depth.
> Reverse Questions > > But IMO this is only for you, not to impress the interviewer. In my experience, asking no questions didn't affect the result. For example, by the time I did the 3 coding interviews at Google I was mentally exhausted and couldn't muster the energy to ask them anything. I still got an offer. Your mileage may vary.
Correct this should absolutely be true. Unless your question is something blatantly offensive, it doesn't matter one way or the other. That time is for you, and has no affect on your feedback.
I say should, because, well... people are people.
Yeah, the author linked to some interesting other links. Good article, good luck to him!
I don't trust that the algorithms will identify qualified people, and I think job search is too important a thing to trust to algorithms. Getting discovered within the traditional application process (LinkedIn, Indeed, applying through company website) is difficult, because you have a large number of applications, and many of those are entirely unqualified. When I was recruiting, it wasn't unusual to get 50+% of applicants for a Senior Dev role that clearly had never written a line of code.
It's a needle in a haystack problem, and the bigger issue is that at some point is the recruiter going to keep investing time looking through the haystack to find a couple needles, or will the recruiter identify a better way to find a few needles?
Direct outreach to recruiters through LinkedIn is what I coach my clients to do, and I provide specific language for that messaging which is just as important. Recruiters like hearing from qualified candidates, and if the recruiter gets enough messages like this he/she doesn't have to wade through the resume pile. It's a clear win/win.
This isn't language trivia. It can be the difference between Util.helper() running very quickly or blocking while an unrelated cache loads. Even if you don't know, you could tell them that (why it's good to know), what your guess would be and why, and how you could find out experimentally.
> They later got back to me saying they wanted someone with experience with Java 14 and I had only worked with Java 8.
This one's weird. You can get caught up from 8 pretty quickly.
I got a comment elsewhere from a former JPMC development manager about their hiring practices.
> most people there hire for the specific problem they’re facing this week, as opposed to trying to get the best talent.
That jumped out at me, too - like, "what the hell does 'experience with Java 14' even mean?" OP did mention earlier in the post that his Java was a bit rusty, so maybe they were just being nice.
All that to say, it seems a lot more like a lottery trying to get a job with the established players (after jumping through all their interview hoops), and while the money might be better, the type of work, what you work on, the level of autonomy you're given (or not) is also very important.
Note this doesn't mean trying to test for the skills that they must've applied to do those jobs. That's hopeless to achieve in an interview for all the reasons endlessly documented in these threads. Instead, assume that if they did the jobs listed in the resume, obviously they must have the skills to have done them. So now the interview is about validating they did those jobs, not the technical detail itself.
Based on more than two decades of hiring, this works very well.
Is hello world now code for hard level leetcode problems?
And people without experience - how will they get jobs? I feel our industry already does too much of this - asking for 5 years experience with a specific technology. I’d like to push back against that.
Fwiw I’m not entirely unbiased. I am a person with minimal experience and no relevant degree who got a job by preparing hard for interviews. I’m happy I wasn’t filtered out by “10 years of relevant experience and a relevant degree”.
Why not get the degree then? If you'd started four years ago, you'd be done by now. If you start now, you'll be done in four years (maybe a little longer since you're working full time).
And not just the cost, the opportunity cost! I would have forgone the last 4 years of salary and work experience. I wouldn’t have been able to write the post this thread is about if I had been in school in that time.
Thankfully, our industry doesn’t worship pieces of paper.
I've seen several senior devs with 15+ years of experience who can't complete basic programming tasks (in a language of their choice) despite allegedly working at a job where they write code every day. I'm talking fizz-buzz level stuff. It's baffling.
Everyone I hired could do the work, regardless of whether I asked them algo stuff. The only people who didn't work out had non technical motivation issues.
I guess there's always another side to experience, because it seems like you've come across this a lot.
These widespread anecdotes should inspire reflection, not just on the utility of technical interviews, but on the very nature of the work that goes on in the software industry. What exactly is going on.
> Doctors, lawyers, contractors, plumbers, electricians, accountants, agents
Also, the level of complexity/difficulty that a dev might face (but usually doesn't) is higher than in of these professions.
>Also, the level of complexity/difficulty that a dev might face (but usually doesn't) is higher than in of these professions.
Fascinated to learn how you came to this conclusion.
I see very few devs (like, none) who get that sort of support system. At best, arguably, a good PM might help, but they also bring a l other layer with often extra steps to desk with.
In short, I think we're arguing the same thing and I agree with us.
If you apply at average European companies for example, paying average EU wages, you don't get any of that, but you'll have to be OK with earning very avenge wages in line or sometimes below most other skilled white collar professions (in Western EU at least, in the East devs still earn higher then everyone else).
It's kind of like dating, the less attractive a company is to potential candidates, the easier it is to get in, the more attractive it is, the harder it is. Supply and demand.
Ironically that is still in line with your dating analogy.
True, but it really depends on the region and local market. If you go to an over-hyped place like Berlin for example, where there's tons of low quality start-ups claiming they're the next Google, and tons of both ambitious and low-quality candidates pouring in from abroad with inflated resumes trying to break into the market, then yeah, the hiring process will be broken from all the effort needed to filter out the posers and chancers from the candidates who can actually deliver results, especially if you don't have a strong network of contacts you can leverage.
But in my small city that nobody from abroad has heard of, hiring is much more sane, since there's much less noise you need to filter out. Granted, the number of opportunities and the pay is also much lower than in places like Berlin so that's the trade-off for sane interviews since the small market attracts less posers and chancers.
Occasionally you’ll get a set of rounds that last 3-4 hours, but it was just as rare back then.
The main difference between big tech companies is the reliance on LC type algo/ds, and the insistence on getting to the optimal solution for anything but the hardest questions. Also 'normal' companies are more likely to ask more domain specific questions... for instance, you might get pairing sessions that stress knowledge of language/framework, SQL query building, etc, and are going to be a bit more permissible of mistakes.
From what I recall, most companies did 3-5 rounds with escalating time commitment from both sides as the rounds progressed. A typical process would be:
* short 15-20 minute phone call with a recruiter to discuss your experience and gauge your interest.
* take home coding test. I consider this step to be a low pass filter to weed out candidates who can't code at all.
* phone interview. This would take about 1 hour with 1-2 engineers on the other end, possibly including the hiring manager. Technical questions would get asked here.
* in person interviews. Usually a full day with the company flying you out to their location. This would be a mix of culture fit, tech questions, meeting the team, etc.
That's four rounds. What would you cover in the other 3-4?
1 Online assessment/coding round
2-4 coding calls each 1 hour
1 System design
1 Behavior
1-2 Another bullshit meet the managers call
Why would you count that as 1 interview? It's always an exhausting 4 hour marathon of algorithms, data structures and systems design rounds with 4 different people, frequently split over a couple of days.
I've also never seen it split over multiple days. Often, pre covid, the company is flying people out and paying for hotel rooms and food at this stage and the interviewee is taking time off from their current job. An extra day adds unnecessary costs to both sides. If I was interviewing somewhere and they tried to split up this step I'd probably get annoyed and potentially cancel the interviewing process.
You could theoretically have ten 1 hour interviews, back to back in 1 day, and call it 1 step in a multistep process, but most people would call it excessive.
(note - staying the same size is fine if that's your desire, but it's a problem when you're aiming for aggressive growth and can't)
You see the one or two leads who stay while a never ending list of mid to senior folks trickle in and out of companies.
I share your takeaway about keeping the resume updated. It’s the single biggest, low effort improvement I can make.
- Apply for job or follow up with recruiter
- Prepare for interviews
- Complete phone screen so you don't waste each other's time
- Possible programming assignment for the same reason
- Onsite interview for both sides to collect more data points
- Negotiate terms of employment
I've had to sequence rollouts more complex than this.
Um, any word processor? Even a text file? A good resume is only a page long. Spending time researching the ideal tool, buying it, installing it, worrying that it is malware, learning how to use it, seems like far more time than just typing it in.
Heck, my early resumes were written on a manual typewriter. Then they became text files sent to a daisy wheel printer, which made them look very nice.
I still think keeping the content and layout separate has its benefits but like you say, using any tool is better than what did.
This whole "application," process seems like the artifact of a kind of historical paternalism among employers that doesn't reflect reality anymore, and it seems to be an unneceessarily synchronous bottleneck in the talent market, where both parties (employer and employee) have to time the market correctly. Objectively, that seems...limited.
I found I don't actually like take home interviews, I work as a mobile engineer so it's often the same take home, a list of stuff retrieved a back-end and then rendered in a list on screen. Selecting a list item should open up a details page. While the take home is never particularly difficult, the boundaries of the task are often not set clearly. So it's easy for that 4 hours to extend to a whole weekend to make sure all the latest patterns, and trendy libraries are used. Annoyingly on a few occasions after sinking a weekend into a project, I have had an auto-reject with no feedback. That soured me on them. I have put a few hundred leetcode practice problems over the years and can discuss mobile system design pretty extensively, i'd rather interview that way in future.
And including those could potentially be a liability. I had a take-home assignment (a front-end application) where I decided to use Typescript, because I would like to use it and I figured it would reflect nicely.
One of the items of feedback given (I still passed) was that there was an implicit "any" in the code. If I hadn't included Typescript would I have gotten feedback that I wasn't using Typescript? If you're using Typescript but not going the full 10 yards and making sure it's set up in a perfect way you'd use it in production? Could including it harm your chances over not including it because you're not using it in a way the reviewer likes?
Ultimately you'd think it wouldn't matter and that just including it was good enough (and I think it was for this specific reviewer), but it's a tricky game of hoping your choices line up with the unknown opinions and biases of the person reviewing in order for it to work out.
I did two take home assignments but zero white-boarding, just a few general language/framework questions. Some very casual system design questions also. This was for mid-level to senior full stack web dev roles.
I had a minimum salary but beyond that do not need more, so I didn't bother with FAANG or large enterprise stuff. Very happy where I landed.
I was actually really surprised at how smooth and relatively simple the whole search was compared to the almost horror story level experiences some people have. It is mentally exhausting but I was lucky to have polite and professional interviewers.
I'm interviewing with some startups right now, found this site helpful for anyone in the same boat: https://topstartups.io/
That's risk. The difference is that you're comfortable with the risk, but it is risk.
It might have found funding before fit, leading to the market never materializing. The leaders may not have enough experience to see the path before them while at the same time the VCs push for high-risk moves to drive their returns instead of making moves to ensure business stability.
Fundamentally, startups do not share the goal of a long-term sustainable growth pattern. They shoot for the stars, and either make it or crash.
Here's my other buffer against job loss: I consult in between jobs, sometimes for years. In fact I think of it the other way: I'm a consultant that occasionally takes a job for variety.
There is risk with all jobs but how many mass layoffs of eng have FAANG companies done in the last ten years? How many start ups have shut down in the last 10 years?
While I loved my startup time, learned so much doing it, and wouldn't change anything about it, at this point in my life with a mortgage and teenager, I'd realistically need a startup to be able to at least 10-20x for the risk to be worth the opportunity cost of missing $BIGCO$ salary.
so don't get too discouraged by the outcome from any particular interview, part of that is hugely variable and essentially random. focus on putting the effort into the bits in your control and maximising the number of situations you create where your prep could pay off.
A red flagger would be someone who built a supercomputer out of beach pebbles then proved P=NP on it. The interviewer already knows you're good enough for the job, they're just looking for red flags that would disqualify you. A green flagger would be someone who worked at GenericCorp for 2 years on a Java queue. The interviewer knows you're a programmer, but they need a signal that you'll actually be able to do the job.
Why does this matter? If you're a red flagger, all you need to do in the interview is not make an obvious mistake. They already want to hire you, they just have to do the HR dance first. If you're a green flagger, you have to do everything right in the interview to get the job. They need programmers ASAP, but you still need to prove yourself. Being a green flagger is much harder than a red flagger. Becoming a red flagger is simple: Your interviewer needs to think you are smarter than them. If you pull this off they will always give you the benefit of the doubt. Your job interviewing will be so much easier.
To do this you just need one thing on your resume that they don't know how to do. If your resume has an internship writing React, and a side project using NodeJS, your relative inexperience will make them think "I can code circles around this chump." Switch that side project to a niche area they've never dabbled in, and suddenly they're over their head. "What do they know that I don't? We must hire immediately!"
I accomplished this by doing side projects in machine learning and crypto. For any programmer with some tenacity these are totally doable, but most people I interviewed with hadn't done it themselves so I became a red flagger. It doesn't need to be these subjects, it should be whatever niche computer topic you're most interested in. It doesn't need to be complicated either. If you can demo it, and it works, and you can explain it in a way that teaches the interviewer something, you've made the job of interviewing much easier.
A tip I have that I don't see much is related to this - good people love to learn, and also generally like to teach, and this goes both ways across the interview table. If you know something the interviewer doesn't and they want you to teach them about it, that's a good sign for your interview outcome, and also a great sign that this is probably someplace you want to work.
And vice-versa - if you don't know something in an interview but you have time to ask the interviewer to explain it, or to point you to a reference where you can learn about it, that'll help a lot with the they-don't-know-this signal, especially in more junior roles. In most technical jobs, it's impossible to already know everything, so demonstrating that you're someone who is always learning is the next best thing to already being the expert they want.
Thank you again!
Further, focusing too much on a niche area totally unrelated to the job you're interviewing might be evidence against you. If your interviewer is hoping that you'll spend the next decade on graphics frameworks, an intense interest in crypto might be a red flag that you won't stick around.
I think it's much more important to find the right balance of confidence without over-confidence. Do lots of practice interviews, including interviews at companies you're less interested in. Learn how to pace yourself to a speed where you don't have awkward pauses but also don't make stupid mistakes. If you practice to the point where interviews start to feel like a fun chance to meet people and solve interesting problems, you'll do great.
Do at least a little research into the companies you're interviewing for, and show an eagerness to learn about what they do. As a new grad, an eagerness to learn can make up for some other gaps. Similarly, if you happen to have a personal project related to the team, it shows you've already thought deeply about the area, even though the interviewer probably knows the area better than you.
Also, make sure you can talk with confidence about anything on your resume. You never know when the interviewer might happen to be an expert in whatever obscure skill you put on there, even if it's unrelated to the job. For example, I know a few people who lost out on entry-level jobs because they put a real-world language they learned in high school on their resume, and when the interviewer happened to speak it fluently and realized the candidate had forgotten it entirely, the interviewers disqualified them for lying on a resume.
I did a take home project for a startup and fulfilled all of their requirements. They said the code was sound but wanted more documentation and they passed on me.
It's been infuriating to say the least.
I had a similar experience with a toxic, sociopathic CEO from a previous job leading to at least one known instance where an interview process was going along just fine and got cut short after contacting that person. At first I was very worried that, given the highly niche aspect of my work, I would have trouble remaining in that part of the industry.
So I switched tactics, and that CEO has become the first previous boss I will willingly trash talk. I get it out of the way immediately and then it's a non-issue. And then I get to use the reaction as a litmus test for whether the culture will fit. Just make sure not to come across like a jerk.
It will benefit you in multiple ways, not the least of which includes honing/practicing your skills, learning some new technologies, and having something to show for it.
1. You knew you left on bad terms.
2. The company you applied to asked for a reference from your previous company, which is fairly standard.
3. Previous company gave you a bad (or at least less than good reference).
Your mistake is that you should have been upfront with the new company about leaving on bad terms from your previous one. Most interviews include some form of a "why are you looking for a new job?" question, and that's your opportunity to explain at least some part of what went wrong. The fact is, as a hirer, I would treat any negative reference that a candidate gave to me as a giant red flag, because the candidate pretty much controls who they're giving me as references!
You're right. I should have.
> the candidate pretty much controls who they're giving me as references!
I was required to give three references, one of them must be my manager. The other two were positive but I had no choice about the manager reference. I also didn't want to assume they would use the opportunity to screw me. When I left they even offered me more money but I declined so I must not have been horrible at my job.
And I’ve seen entry level candidates demonstrate far above entry level skillsets and not pass the interview.
If that's actually the reason for the question, that's clever :P It doesn't necessarily imply that they cheated, but maybe they use that to flag candidates. I've done a lot of interviews, and there were a couple of phone interviews where I suspected the candidate was cheating.
Were any of them more challenging? Did they all expect perfect working optimal code and/or make you run test cases, or was it more like "ok you more or less have the right algorithm" or something in between?
How fast do you generally solve various LC questions on your own? Thanks in advance, appreciate sharing your experience.
Preparing a resume: I just updated my linkedin profile and exported that into a pdf using the tool they provide. I think this is perfectly fine. I only ended up sending the actual pdf to one company (Stripe) and I get the sense it was just a formality.
Scheduling: This really tripped me up actually. I didn't plan it very well and I ended up asking a company where I had already completed the interviews to slow roll making an offer because I had other interviews scheduled and didn't want to turn down their offer just because I hadn't finished all the interviews I wanted to do yet. This kind of sucks because it's super stressful, but I think it really is best to try to schedule it so that you do all the final interviews you want to do all in the same week or maybe two. I think this is really the main reason to narrow down the search to a small number of companies (like less than 5). There are only so many interviews you can do in this time frame.
Algorithm interview: I did not get any hard questions in these this time around; they were all of the screening question variety, like Leetcode's "easy" (or perhaps easier), where if you know how to write basic code, they really don't require any preparation.
Design interview: I didn't prepare for these because I actually do architectural design at work fairly often (as opposed to the weird little bottle coding problems in interviews, which I don't ever do). I was a little disappointed at how I did in these; it turns out that talking through this under time pressure is not the same as doing it for real, and I often wasn't actually quite sure what to draw in the boxes they want you to draw, because that isn't really part of my real process at work. But I guess these went fine because I didn't get turned down for anything because of this. But I may prepare more next time.
Something not covered in the article, but which I want to mention: The styles of interviews listed here are not the only possible ones!
My new all-time favorite interview I have done was at Stripe. Using my own language of choice and my own tools (ie. my IDE), they dropped me into a fairly large codebase (which looked like it was adapted from an open source project for the purpose of this interview) with a failing test case and asked me to figure out the bug and fix it. This was really really fun and very illustrative of the kind of thing I do at work pretty much every day.
I had another interview with a similar sort of question except it was in the realm of operations. It wasn't quite as great because it was a bit more contrived, but I still really enjoyed it. The contrivance was: you are new and our sysadmin is on vacation with phone service but no internet, we start getting reports that people aren't seeing anything when they go to our website, you are on the phone with the sys admin and your job is to ask questions to get to the bottom of what's going on. This seemed like a hard kind of interview for the interviewer to do, but it was really fun for me.
Stripe also did a "system integration" interview, which was like one of the take-homes mentioned in the article, but was live-coding on screen share. I had to use an unfamiliar json library and an unfamiliar http library and interact with a couple unfamiliar API endpoints and get it all to work together. This went ok, but it was a lot of moving pieces for a one hour live interview, and I think it would have been better as a take-home with a two-hour or so time box.
I will say that I was pleasantly surprised that a lot of people seem to have started moving somewhat away from the esoteric CS-y data structure and algorithm interviews that I think most of us despise.