Interesting how different our job market experiences were.
First, only 8 applications! That’s fantastic - I likewise am starting a senior software eng role… but after 6 months of unemployed full time interviewing, and around 80 applications. FE, not BE, though.
In terms of content, I think every coding round required time/space complexity analysis, and (as an FE!) most had me doing things like building recursive binary tree checkers, solving medium Leetcode problems, etc.
> I made a point of challenging it and asking whether it was representative of the role
Yes! Love this. I had a systems design round, which are usually my time to shine, that focused exclusively on designing an app’s database. A DBA I am not, and I essentially flunked. I brought it up to their CTO on a later call, as I really didn’t think that was a fair assessment of me.
I have had a kind of similar experience. 5 years experience, feel underpaid so started looking for a job. Did hired.com, was contacted by about 20 companies. That turned into 5 phone screens, 0 on sites. 2 of the phone screens said I passed and were going to schedule an onsite but ended up ghosting me.
I also applied to about 10 other places directly but never heard back from any of them. Got contacted by Meta but then they cancelled my interview. Weird to me that everyone is saying that it is a white hot market but I can't even get an onsite.
Well, the root cause is likely the interest rate hikes but the proximate cause is that the economic environment has become drastically worse in the last ~6-9mo.
Tech stocks are down a ridiculous amount and funding for startups is now much harder to come by. Probably other factors I don't know about as well.
Good to see I am not the only one interviewing a ton. I have a different experience than yours for FE interviews. No leetcode questions. Mostly take home or live coding React/Vanilla JS stuff. No system design rounds either mostly talking about the tech stack in breadth and sometimes in-depth.
You guys are not alone. My last job search was probably on the order of 100 applications, 10 interviews, 1 offer. It's been this way my whole 20+ year career. I don't know who these Captains Of Industry geniuses are who are getting multiple offers from 20 job applications, but I'm sure it's not the norm.
> My last job search was probably on the order of 100 applications, 10 interviews, 1 offer.
This is bizarre to me. How many years of experience do you have? I am in the US.
I get almost a 1/1 interview to application ratio and numerous offers, and I'm nothing special. I've just "been around the block" and I can convey that I've dealt with the big, difficult problems in the real world and have tackled them head on. Maybe it's the honest "been there, done that" I can convey after 20 years in the industry.
We may also be applying to different types of companies. I don't go for the "5 rounds of social fit" type companies, I go for straight engineering.
That's been my experience as well. Last job search, I put in 3 or 4 applications and after all the calls and interviews were done I ended up with 3 offers.
I'm nothing special. But I do learn a little about each company I'm applying to and tailor my resume to each position. If possible I develop an internal contact so I can get some informal information on the position from the inside in advance. I only had inside contacts for two of the companies last time though.
I can't imagine doing that for 100+ companies like some people apply to. I have to imagine most people applying to that many are just doing a spray-and-pray method.
Or maybe advertising themselves but not selling themselves. In some cases a 2% conversion rate is a decent goal for a marketer advertising to the general public, but would be pretty bad for a salesman getting commission from personalized sales.
I'm no salesman, but approach the job hunt like an enterprise salesman who needs to land a good account with a good commission to live on.
Not who you're replying to, but I have 10 years FE experience, and have managed small teams (3-5). My hit rate for interviews to applications was around 1:6. My only requirements around applications were: no early startups, a modern tech stack, and a minimum engineering team size.
The overwhelming majority of companies simply ghosted my application – Spotify, Atlassian, ADP, Lyft, Stripe, and Squarespace were all applications I made in one week, none of whom ever responded.
Hopefully I'll be closer to 1:1 once I've got 20 years under my belt ;)
OP here, I didn't keep an accurate log, but yea it's all ghosting. I'd estimate it's about 85% "never contacted" ghosting, about 5% ghosting after an initial call w/ company recruiter, and 10% ghosting after doing at least one phone screen. I don't know whether these companies are just incredibly disorganized and forget people, whether the jobs don't really exist in the first place, or if it's just their cowardly way to say "no" to a candidate without actually saying "no".
It is my belief that, like most tech companies, they have pretty much a huge raging river of good candidates to choose from, so they have to use a very coarse filter (ignoring almost everyone), in order to deal with a manageable number of them.
Western EU thing as well. There's an oversupply of candidates (everyone wants move/live here) and a low supply of jobs (in some countries), so companies can afford to be very picky.
Eastern EU has the opposite phenomenon, oversupply of jobs due to outsourcing/nearshoring coming in, and lack of skilled candidates since may skilled ones moved west.
Yes. My no-name company paying average or below average wages, in my no-name western EU town in Austria, has received over 30 applications for one position within a week, most from outside the EU (I think the Russo-Ukrainian conflict added a lot of gas on the fire).
So most companies here have raised the hiring bar accordingly due to this oversupply of applicants, therefore getting a job now is pretty rough if you're not at the top of your game in terms of experience and skillset.
This was my first time going after “senior” titles, and was also the first time I’d seen system design interviews. They only cropped up in final rounds. I had them at Amazon, Uber, and three other companies.
I was supremely nervous about them before but I actually wound up doing really well (save aforementioned DB crap). It was a chance to talk about my personal niches, like accessibility and load times.
Frustratingly, every single one was wildly different. I found that approx. 0 of the “cracking the system design” stuff I read beforehand helped in anyway.
Glad that I am not alone. Just got another rejection email. No LeetCode, problems seemed realistic, I solved them all. Really have no idea what they were looking for.
This was my 4th application where I was rejected after final round. A lot more where I didn't get past initial screening etc. Feeling down right now.
I have 15 years of technical experience, I never got a chance to specialize but I can handle everything, DevOps, database, frontend, & backend. Perhaps that's my fault for just getting work done instead of focusing on my career. Perhaps I am getting really old for this industry. Maybe I really should go in the management.
I'm so sorry to hear it. I will tell you that I likewise had a lot of final round rejections. The most soul-crushing rejection came after 9 interviews, a 10hr take home, and a 4hr on-site – and through all of it, every decision maker told me they were excited to start me.
Nope, rejection comes 2 weeks after the on-site with no explanations, and they refused to elaborate further.
The sole advice I can give is unfortunately to just keep going. Wish I had more. Best of luck.
Until this job search, I usually had two interviews, one technical screen and one behavior interview. And this was for senior roles. And usually, I almost always got offers. Most of the time, I was deciding between two jobs.
I think everyone is trying to replicate FAANG's success by copying their hiring practices. Maybe this is a hazing ritual to find really obedient workers.
Either way, we have to play this game and keep trying.
600? Did you got any feedback? Maybe there's something in your CV that's being perceived as a red flag but ok to you. 600 applications without an offer seems way off.
Are you utilizing your IRL social circle? 100% of the jobs I've had in the last 15 years have come from someone I know reaching out and saying, "hey, the company I work for is hiring and I think you'd be a great fit."
Now, some of that was motivated by referral bonuses on their part, but still.
The old cliche that "it's not what you know but who you know" is still very much a thing.
I'm not the parent, but I can't do that, because, I get shot if I do better than my "friends" so yes, we want you, but you can't be better than me. I try to find other people. But yeah...
> then in the coding exercises you were asked what the O(n) complexity of time/space were
I usually ask people to roughly describe what is meant by computational complexity (sometimes I slot it into the conversation when discussing some code they wrote), or what big O notation is for... assuring them I'm not looking for a formal definition but an understanding and applicability. I probably wouldn't do a great job actually using big O notation to express complexity myself if asked on the spot; however I believe a basic understanding of the underlying concept is invaluable and separates juniors from everyone else.
Is this not considered reasonable these days?
[edit]
To clarify, I think the author was being asked to express their code in big O, I'm just wondering what people think about ask about big O and complexity in general.
I feel like a lot of leetcode grinders don't actually understand big O. Sure, they will produce the correct answers to your questions like a well-oiled Chinese Room, but they lack true understanding. It's almost mechanical: "O(1) is faster/better than O(n) which is faster/better than O(n^2)" etc. O(1) is hashmap, O(n) is a for loop, O(n^2) is a nested for loop, etc.
So if an O(1) solution exists, the candidate will almost certainly converge on it. Yet the part not being understood is that big-O is just an upper bound that you may never see unless your datasets grow to huge sizes. Sometimes an O(n) implementation is actually better or faster than an O(1) implementation or sometimes O(n^2) is better/preferable than O(n). It depends on a lot of things - the size of the data being handled, the expected scaling of the data, who is going to be maintaining the code, etc. A straightforward, highly readable O(n^2) function that operates on small datasets is almost certainly preferable to an unholy O(n) incantation that is unreadable but technically scales better.
Wow, this is really the perfect description of the general understanding of algorithms and computational complexity in the post-leet code era.
I've found that far less people in software understand and are curious about algorithms than there were 15 years ago, despite the fact that almost everyone studies them now for interviews.
I wonder how many people asking questions about computational complexity could tell you what the pumping lemma is, or how a regular language differs from pushdown automata. Or, more important, if they could answer the question "what is Big Omega for this problem?" or if they are really asking "what is big theta?". I'm still tempted sometimes to refresh on recurrence equations to provide the actual answer for these things rather than just applying some heuristic. Of course, in my experience, doing something like that would get you a failing score since they wouldn't know what you're doing and therefore assume you are wrong and an idiot "I can't believe that guy didn't even understand Big O".
> I've found that far less people in software understand and are curious about algorithms than there were 15 years ago, despite the fact that almost everyone studies them now for interviews.
It may explain why no-one succeeds my interview test, but then I wonder what I should test on if I want someone correctly smart.
My interview test is simply to find a string in a string and return true. It takes two for and one if, everyone fails, I generally stop them after one hour when there are booleans scattered everywhere. The way I give the exercise is “Please program a .contains(), without using .indexOf(), and no need to optimize anything, I’m not looking for anything fancy.” A 49 years old java programmer even complained that the test isn’t fair because it’s stressful to program in front of people, so now I take the habit of sitting in the next room, but then people try to overdo it and deal with UTF-8 before having the basic algo working.
I’m pulling my hair wondering what’s this parallel world I’m in, or whether I’m introducing a bias which makes everyone fail (2 interviewees per month for 5 months).
Either you aren't screening candidates that have no obvious coding skills or the job description is wildly off the mark. That's a pretty easy coding test for basic strings.
> ...I wonder what I should test on if I want someone correctly smart.
Why would you want that? Look for someone who can (and is happy/eager to) learn *from you*.
Edit: smart isn't bad, but it's not much of a signal - there are plenty of ways to be smart but not very productive.
Moreover, any test in an interview setting well be extremely limited. Ability & willingness to grow seems a lot more useful (and at least equally well testable).
> “Please program a .contains(), without using .indexOf(), and no need to optimize anything, I’m not looking for anything fancy.”
If that is the statement that was given to me, I would clarify the interviewer is not looking for optimal run-time or anything fancy like handling UTF-8 or right-to-left -- because an interviewer often says "nothing fancy" and then will nitpick the fact the code you wrote on the whiteboard doesn't follow precise PEP-8 standards or use idiomatic Ruby or doesn't adhere to the latest C++-23 syntax -- and then I would write a total of six or seven lines of code C code (variable declarations, return statement, etc), which would be two for-loops and an if-statement. I could probably get that down to just the for-loops if I want to be "fancy" and bury the conditional in the for-loop test itself.
I think the real problem is, we tend, in an interview situation, to overthink what the interviewer is asking for at times. I see this in a lot of take home tests people do when applying to companies, then ask me if they have done enough before submitting to the company they are interviewing with. That said, I've dealt with interviewers that give the take home test, or the white board test, and then complain that the candidate didn't go far enough by adding on un-asked for stuff. "Going the extra mile" as they say. The crux of the problem is the vagaries of interviewing style.
I think a lot could be mitigated if interviewers supplied a take home test and a different example take home test with an answer that showed the format of what they were actually looking for with depth/complexity/testing/etc.
A 49 years old java programmer even complained that the test isn’t fair
And you had to mention their age ... why, exactly?
As opposed to "a left-handed Java programmer", or "a Java guy wearing a Slayer T-shirt"? No -- for some reason, with this candidate -- their age was especially relevant to you.
Why?
But then people try to overdo it and deal with UTF-8 before having the basic algo working.
Because of one too many experiences with live coding interviews, (on appearances) pretty much exactly like yours -- in which one gets flushed (or otherwise dinged) for failing to proactively treat such edge-case details as encoding gotchas, zettabyte-scale strings sharded across multiple time zones, etc.
I’m pulling my hair wondering what’s this parallel world I’m in, or whether I’m introducing a bias which makes everyone fail (2 interviewees per month for 5 months).
In fact, you are introducing just such a bias. There has recently been good, solid research done into the fact that performative (that is: on a whiteboard, in front of a group) "programming" tests are really basically high-pass anxiety filters. That is, implicitly designed not to measure programming ability, but the (studied) ability to ... successfully complete peformative rituals in front of random strangers you've never met.
If you aren't aware of this research (or your capacities for empathy aren't at a level where this is intuitively obvious to you) -- then you shouldn't be conducting these kinds of interviews in the first place. No matter how good you are at programming per se.
> A 49 years old java programmer even complained that the test isn’t fair because it’s stressful to program in front of people, so now I take the habit of sitting in the next room
Whether programmers like it or not, live coding has become a standard for interviews these days. I can see anyone still unfamiliar with this doing poorly, I used to do awful at these until I realized this is just part of the game, but it's not unreasonable to expect candidates to be able to do whiteboard/live coding.
However, you just sitting in the other room, tells me you also have a lot to learn about the structure of live coding interviews. Every major Big Co. that does these has a very well established flow, including providing helpful clues to the candidate. Most companies provide training to all interviewers to make sure this process is smooth, repeatable and fair to candidates.
Common tips are to: first make sure the candidate understands the question, make sure they are thinking out loud the entire time. You don't let the candidate go too far down the wrong path. Most important you have a list of anticipated questions with stock answers to help stuck candidates, as well as a list of stock prompts to help them get on the right track if they are lost.
For example, in your challenge, if a candidate is stuck you might ask as simpler subproblem "so how would you find out if a sting contained the letter 'a'?" and if a candidate starts heading down the wrong path, prompt with "hmmm... I think I see where you're going, but I recommend you back up a bit and rethink this part here"
It sounds like you're in a small shop so I highly recommend you enlist a few friends (especially some that have done interviewing at large companies) to help you work out the kinks in the interview itself.
> ... but then people try to overdo it and deal with UTF-8 before having the basic algo working.
Wait... We all know (?) that Java was conceived before Unicode 3.1 came out and somehow thought that 16 bit chars would forever be enough to hold unicode codepoints and hence Java strings are now a mess of both char and codepoint methods but... What's UTF-8 got anything to do with your question, even after a basic algo is working?
If I'm using Java's charAt(...) on both strings, what's the encoding got anything to do with matching if the substring is present? Who cares that one character may have a codepoint encoded using more than one Java char primitive? It's either encoded the same in both strings or it won't match right?
I'm confused.
EDIT: you said it's not fancy, so you're not looking for people to match combining codepoints in one string matching another codepoint in the other string or things like that right?
Hey! That's my question :-) I've been doing pretty much exactly this for the past 10 years. A common solution I've seen is a single while loop with gnarly logic inside to monkey with the string index, rewind when no match, etc. Then imagine that kind of code in your business critical backend.
If you've just failed ten interviewees in a row, then either your sourcing is broken, or you're doing interviews wrong. Might be both, can't be neither.
Granted, I don't think it's all that hard a problem, and while I'm not at keys to check I think off the top of my head it should be solvable for constant strings in linear time - not like you're asking for sequence alignment or anything like that.
But if it demonstrates something relevant to the role and ten in a row can't hack it, then your pipeline's not finding you good candidates and that needs to be fixed.
And if it's not relevant - which is highly plausible, as who ever needs to or even should reimplement heavily optimized standard library functions, especially for as hairy a type as strings - then why even ask it in the first place?
edit, at keys: Yeah, it's simple to do this in linear time with constant strings (ie no backtracking):
const cases = [
{
subject:
"now is the time for all good men to come to the aid of their country",
searchFor: "n to come t",
expect: true,
},
{
subject:
"now is the time for all good men to come to the aid of their country",
searchFor: "time flies",
expect: false,
},
{
subject: "short skirt",
searchFor: "looooooooong jacket",
expect: false,
},
{
subject: "symbolized as ∆v and pronounced delta-vee",
searchFor: "∆v",
expect: true,
},
];
// TODO cases covering match at start and end, etc
function contains(subject, searchFor) {
let searchIdx = 0;
for (let i = 0; i < subject.length; i++) {
if (subject[i] === searchFor[searchIdx]) {
searchIdx += 1;
if (searchIdx + 1 === searchFor.length) {
return true;
}
continue;
}
// We found a mismatch between subject and search
// strings. Return to the first char of the search string;
// we'll have to try to find a new match
searchIdx = 0;
}
return false;
}
function assertEqual(expected, actual) {
if (expected !== actual) {
throw new Error("Assertion failed");
}
}
cases.forEach((testCase, i) => {
const { subject, searchFor, expect } = testCase;
try {
assertEqual(contains(subject, searchFor), expect);
console.log(`PASS: case ${i + 1}`);
} catch (e) {
console.error(`FAIL: case ${i + 1}`);
}
});
It's trivial in quadratic time too, of course, although I would expect a candidate for a senior role to be able at least to find the linear solution, if not to start there outright.
In entire fairness, I have to admit that we do use problems of similar complexity (both cognitive and algorithmic) for our first tech session, which I frequently administer. In my experience, people tend to handle stuff like that pretty well, even with considerably less experience than it sounds like your candidates have. But - and I think this is crucial - none of those problems involves operating on strings.
As another commenter here suggested, you definitely need to express this in terms of Array<number> or some similar contrived type that's obviously not as complicated as strings, because anyone who's been around for a while will certainly have been burned often enough by string complexity that they're not likely to assume they can treat it purely as an array of bytes iso8859-1 style. I certainly wouldn't assume that!
To be clear, I would ask if I could safely assume that for the purposes of the problem, or more likely I would look at the tests around the problem and see if any of them included obviously non-Latin-1 chars and thus cue me that they need special handling. (If I can't see the tests while I'm writing the code that's supposed to pass them, you'd better believe I will ask about that!)
I wouldn't necessarily ding a candidate for not asking, though. For one thing, this is all pretty basic info, and would certainly be available in "real life" - so if it isn't available in the interview, then the interview isn't a sufficiently accurate representation to produce a clean signal.
For another, and for the same reason, the perceived power differential between panelist and candidate has to be taken into account. You're not going to get a clean signal if you bring your ego into the session, or otherwise give the candidate cause to feel more intimidation than the context naturally inspires.
Some folks are more confident than others, sure - but it's a technical interview, and confidence isn't really of interest beyond the baseline of not seeing a candidate dissolve into a puddle of flop sweat. (And, in any case, if that does happen then it's at least as much my fault as anyone's, because if I'm not able to help people be comfortable enough to even function on my team or in my engineering org, then I'm not doing my job right!)
So yeah, granted, I haven't interviewed with you and I don't know any details beyond what you've chosen to describe, so take this advice for whatever you find it to be worth. But, especially in a language like Java which I gather makes it more necessary to account for utf8 weirdness in strings than the languages I more commonly work with, I definitely think you'll see a significant improvement with just that one simple change of not using strings where you really don't need to in the first place. That might not be the only thing that needs attention - I suspect your pipeline may need some love, too - but I'm fairly confident it's an excellent place to start.
(For what it's worth, my experience with tech interviews extends well beyond the candidate's role; I've been participating in them as a panelist for a good few years now, and lately, by request, have been doubling up my sessions as mentoring/shadowing opportunities for other engineers and EMs who want to improve their own panelist skills. Granted, I've approached this discussion largely from the candidate's perspective - but then too, I'd argue very firmly that if you're not considering how your interviews might go from the candidate's perspective, then that's something you need to work on, too.)
> It's trivial in quadratic time too, of course, although I would expect a candidate for a senior role to be able at least to find the linear solution, if not to start there outright.
I would not call this trivial. The code in your post is incorrect. For example, it cannot find "ababc" within "abababc", since after the first mismatch we skip too much of the haystack.
The real solution to this is Knuth-Morris-Pratt, where we must precompute for every index in the needle the longest needle prefix that fits before it. I would not expect your average interviewee to derive or implement this.
An easier linear time solution (in my opinion) is rolling polynomial hashing. But if you actually expect solutions in an interview you should settle for the naive quadratic algorithm.
Is it, though? I think real cases might frequently be less complicated, in Java at least. As is evident from the candidate experiences that the original commenter describes, there's a lot more complexity in strings than is immediately obvious.
I agree with 'Gunax that that's likely to be tripping people up - as I mentioned in the comment to which you're replying, albeit in a somewhat recent edit, this has not nothing to do with why our own similar interview problems don't revolve around any operation on strings.
> I've found that far less people in software understand and are curious about algorithms than there were 15 years ago, despite the fact that almost everyone studies them now for interviews.
I would argue people who prep with LeetCode aren't studying algorithms at all, they're doing something much closer to memorizing.
I've seen people who I assume did a bunch of cramming like that because they'll be like "oh this is [xyz]" and throw out a solution in a hurry, and then I ask them to modify it in a non-standard way, and it's almost as if the idea that an off-the-shelf regurgitation of the "normal" solution for a problem not being able to handle a modified scenario is something they've never thought about.
Like "oh this is a search problem" -> "what if [something that essentially boils down to the graph potentially having cycles]?" -> [head expodes instead of thinking about, say, tracking what nodes have already been seen]
Well first a lot of software we work on now isn’t pushing performance limits. The long poles in these development projects are requirements and domain understanding.
The software that does push technical limits is likely to push IO, storage, and reliability related limits rather than compute. Distributed systems and big data are topics with a lot of interest in the last 15 years!
We call them “computers” and algorithms are very important for computation, but many commercial applications these days actually use them in their capacity as telecommunications devices and data storage and retrieval systems, with the actual “computing” part being much less ambitious.
> I've found that far less people in software understand and are curious about algorithms than there were 15 years ago
Maybe because so many SW job descriptions these days seem to consist of plugging library into framework, and anyone interested in algorithms would be bored?
Not saying that's what you're recruiting for, but the industry has expanded massively while I'm guessing the number of algorithm heavy jobs has stayed roughly constant.
My favourite approach to big-O questions to to reply O(exp^n) to everything. When asked I point out that whatever it is, exp^n surely bounds it. This'll go either two ways. The interviewer will reflect on whether it is a least upper bound or not (and whether my statement is right) which makes for an interesting discussion about the other types of Landau notation. Or they'll get angry.
Ultimately I'm not convinced based on my own personal experience that many of the people asking the question truly understand either. I see it in a somewhat negative light because I feel it is essentially a cargo culted interview technique - recite a few 0()s, yeah we all did CS degrees, great (or not). If you actually try to get into the weeds...
I also don't think understanding big O notation is a great predictor of success of a software engineer. As well to ask if the series 1/n converges versus 1/n^2. What I'd rather see is that they can actually implement a solution. Take an ORM for example - a junior candidate knows how to use it and maybe how to debug it. A senior candidate might know that ORMs often emit very poorly optimised SQL and have some ideas on how to fix it. Example picked arbitrarily, ORMs aren't even my area.
Even in my actual area of specialty the number of industry programmers who understand say what an elliptic curve with complex multiplication actually is, or even undergrad group theory, is quite limited. And they don't need to - I mean it is ideal if they do, but you can still implement ecc without much theoretical knowledge. There's also a bunch of "not academic" knowledge on various implementation techniques that academics might not know or care about.
Brings me back to my ORM point. I'd much rather the person understands how the tools might fit together and more importantly learns any gaps or asks questions and identifies performance issues in the whole.
That's not to say that time and space bounds don't matter. They do. But 99% of my use of this knowledge has been to answer interview questions.
I suspect that lots of people ask for O(n) when they mean Θ(n) instead which specifies both an upper and lower bound. For example, specifying Θ(n^3) as the running time for a bubble sort would be incorrect whereas O(n^3) would be imprecise but not incorrect.
So big-O implies that the runtime is "dominated" by the term in brackets, or put another way, if I say something is O(n^2) I'm stating that as n->infinity the runtime of the algorithm |R| <= c * n^2, where c is some constant.
This is still true of exp^n, since |R| <= cn^2 <= dexp^n. Or at least based on my analysis background I'd expect this behaviour. It is of course a little pointless to say the algorithm is O(exp^n), but that's a different issue. It is still an asymptotic upper bound.
I just checked my copy of Sipser. Example 7.3 on page 249 if you care. They give an example that f_1 is O(n^3) and state it is O(n^4) also, since n^4 is also an (asymptotic bound) bound.
But this is not the point. I have no formal computer science education at all (my background is mathematics, some logic if that counts, but I've never studied algorithms) but many interviewers insist on this one specific area of CS, and yet if you attempt to engage them on the meaning of the things then unless you are very lucky they will a) make some excuse about how they'd have to check, their degree is a while ago, or b) they're actually only reciting also.
I'm strongly of the view this is a massively cargo-culted interview question of questionable to no value for most software engineering jobs, given that interview time is very limited and there are many more important factors to evaluate.
You seem to be missing the entire point of this kind of question. Yes, you are providing an upper bound. But as you yourself admit, your answer is useless. The point of big o is to put the lowest reasonable bound on an algorithm so they can be compared.
Your approach is basically interview trolling.
I don't use big o in interviews. That's more the domain of big data than the web slots I typically fill. I'm more interested in the depth of understanding they display in the techs they claim to know.
The complexity bound of an algorithm is the worst possible complexity. It needs to be proven (by assuming the worst possible input data), and there exists only one provable bound for a particular algorithm.
Finding the complexity of an algorithm in school is an exercise for understanding algorithms, and gaining a "vocabulary" for talking about them. But, provable bounds don't correspond to practical bounds, since input data is almost never close to the worst-case scenario. It isn't really a practical skill.
Several algorithms have bad provable complexity but can perform well in practice, while algorithms with better provable complexity can perform worse on average input sets.
A follow up. I'm more interested in a devs understanding of memory complexity than time complexity. Every single production performance issue I've seen out side of academic questions had been due to memory management issues.
Most of the value of understanding computational complexity of code is that you get a little voice saying "hey, this is probably going to cause issues on larger data sets" after writing something that passes tests and works on small pieces of trial data. A Chinese-Room understanding of O(n^2) vs O(n) and O(1) is plenty for noticing these, and may actually out-perform a more thorough understanding; what you want is to notice things going quadratic as you rush through a code review or slam out a feature, and that is almost entirely reliant on pure pattern recognition.
It depends on if you want to scale the application, but I wouldn't choose the readable O(n^2) over the less readable O(n). I would just attempt to make the O(n) readable.
There's currently a backlash against LeetCode style interviews, and I think one part of this backlash is that dismissing anything that feels LeetCodey (like asking about time complexity) is considered reasonable.
I abhor everything leetcode (and suck at their puzzles), but I would call O(n) basic foundational theory. Competence in engineering requires an intuitive understanding of at least time complexity. Given that this is software "engineering", it's probably fine if the candidate isn't familiar with big O specifically but they should at least be able to reason about scaling complexity on an interview, I think.
Any thoughts on self taught who, i'd think, has a seasoned understanding of time complexity but lacks meaningful mathematical notation background necessary to use Big O fully?
Which is to say i have no confidence issues in my working knowledge of Big O. I lead a team, i've developed obsessively for 10 years now and despite my many short comings i don't think understanding trivial complexity - the why of "Why is HashMap faster than BTreeMap on lookup? When is it slower?" etc - is lacking. But, i couldn't use Big O notation to any meaningful complexity with any real confidence. My math background is nil.
In general i need to up my interview game, which i think also means i need to up my math game to have a firm understanding of Big O notation itself.. but the complexity is not the issue, for me at least.
Big O is important. I actually have to frequently understand whether my function runs in logarithmic or linear or quadratic or exponential time relative to some value.
I can see an issue if you’re asking for
a weird big O which really isn’t useful in practice, like “oh, we were expecting this weird algorithm which is O(log log n), not something O(log n)”, or having to calculate the big O of one of those weird algorithms.
The emphasis placed on big-O in interviews is weird though. Accidentally quadratic code happens, sure, but the way the industry uses it as an interviewing shibboleth makes it feel like this is a safety critical issue; as if at some point a developer used an O(n log n) algorithm when an O(n) algorithm existed and people died.
Complexity can be insidious, and it can lead to annoying bugs you only discover in pathological data cases, but it is in no way as important in software development as correctness.
Code that runs slow over pathological input is nowhere near as dangerous as code that goes into an infinite loop over pathological input.
Your O(log n) recursive tree traversal is beautifully efficient. Too bad it stack overflows with trivial tree depths.
Even weirder: A lot of companies who are obsessed with big-O and algorithm complexity don't ask candidates even basic questions that require them to think across many orders of magnitude, in terms of time and storage. I'd argue that being flexible enough and able to visualize things across, say, ten orders of magnitude, is a more critical programming skill than knowing big-O.
Even basic questions: Answer with either the word nanoseconds, microseconds, or milliseconds: What's the order-of-magnitude latency of CPU cache lookup? Reading 1MB from spinning disk? Reading 1MB from memory? A round trip packet to a server 1km away? A GPU clearing a 4K screen? A mutex lock? Answer with kilobytes, megabytes, or gigabytes: What's the order-of-magnitude size of a digitized photo? A song? A movie? A graphics frame buffer? Wikipedia? Google's homepage? A typical bootloader? A Windows app executable file? A typical CPU L1 cache? L2 cache?
Too many junior developers can only answer a few of these, even with the answers having three orders of magnitude granularity! But we constantly ask them to belt out the best and worst case big-O complexity of a binary tree.
Yea, thank you. I run backend interviews for my company and while i do want someone to understand the basics of complexity, i am far more interested in how they think about, as you put it, orders. I want them to group data in a simple DB call, not call the DB in a loop - avoiding network. I want them to make 2 DB calls if a join explodes the rows and thus a single call ends up much larger than 2 calls. I want them to understand why iterating a large hashmap can be much, much worse than a data structure more suited for sequential access, etc.
Ironically i suck at Big O notation itself. So maybe i under value it.
> Code that runs slow over pathological input is nowhere near as dangerous as code that goes into an infinite loop over pathological input.
In my experience, these are not actually that different. Even in straightforward web development on smallish data sets, it's pretty easy to write something that runs "fast on my machine" but is so slow on production-sized data that it is effectively infinite.
Yes, as I say, clearly it happens. But when it does the results are no worse than any other bug.
And it’s far more common, and more dangerous, in my experience, to see a loop that assumes it must eventually reach a terminal condition that isn’t actually guaranteed.
I just don’t think the risk of hiring someone who misestimates the time complexity of an algorithm is sufficiently great that it’s worth explicitly filtering for. Why is this the one piece of hard won experience or academic knowledge that we need a candidate to have before they join our company, given that it’s something that can be taught in a single CS101 lecture, and in practical terms, something I can explain to a competent developer in about ten minutes?
It's important but like, it generally boils down to "do you have nested loops" and "are you using a binary tree". A lot of system behavior isn't defined by these kinds of decisions because your N is small. Rather, it's defined by say TCP backoffs or queue sizes, or the broad architecture of the system (must you wait for consensus, do you use Salesforce SObjects as a cache before dumping into Postgres--a real life example--what is your "needs rerendering" trigger). I think it's useful for a programmer to have this kind of basic knowledge of code, but the amount of play it gets in interviews is pretty disproportionate to its importance.
I guess this is more of a "do you know about database indexes" question, but I think if it less of a gotcha and more of a jumping off point into a discussion you can take it in a number of directions:
- time vs. space tradeoffs
- insert vs. select tradeoffs
- Oh yeah they're binary trees also, with those implications
- What's reasonably distributable (downsides of UUIDs)
- at what point might you have query performance issues you can address w/ indexes
But like, again practically speaking I think this is just an experience test question. I think I'd prefer something like "on your resume you have Postgres experience dating back 7 years, tell me what you think about it, what its strengths and weaknesses are, and why you would or wouldn't use it".
---
Maybe you have thoughts about this too, but I'm also starting to develop some thoughts around whether to consider interviews quizzes/tests or conversations. Thinking about it, I've always approached my interviews (on both sides of the table) as conversations--even questions with simple answers. I guess that's why my answer here is "this should be a discussion about databases" and less "table scans vs. index scans in 30 seconds go". It's totally OK to drill down into specifics and be technical, but this is potentially your first interaction with a new colleague, and you should be collegial, not domineering and inscrutable right? I think we get so worried about hiring a faker that we justify anything to avoid it.
This can be a really poor assumption in real world software that can bite both ways. Some "expensive" algorithms in terms of big O terms can be pretty efficient given real world data sizes. Additionally that C term that drops off at infinity can matter quite a lot if your real world problem size is small (meaning theoretically efficient algorithms can have a very high upfront cost).
Reasoning about actual runtime performance is far more important and intersects with the interesting/useful parts of computational complexity theory. Besides, in every interview I've been in they don't really mean "Big O", because I've never been required to produce a recurrence equation proving it, nor have I been confident the interviewer would even understand such an answer.
Understanding performance is hugely important in real world software, but Big O is a tiny part of that in practice.
You don't need a recurrence relation to prove it. You can use a simple algebra where you are able to combine the complexing of algorithms. For example an O(n) algorithm followed by an O(n^2) algorithm will be O(n^2). In an interview I describe how the complexity of these simpler algorithms get combined into my final answer. I assume that the interviewer and I can agree on some basic stuff like looping over an array is O(n), inserting into a heap is O(log(n)), etc.
There’s been a move away from requirements for CS degrees in software development over the last decade or so, but that shouldn’t mean that key concepts like asymptomatic complexity are not needed, only that they are sometimes understood at a more intuitive and less academic level.
The author is a senior engineer, I have no doubt that they could describe difference between a linear and polynomial-time algorithm and the potential concerns with the latter even if they might not use that terminology because of a trend against academic-sounding lingo.
>Firstly, I'm really glad to say that the interviews I did were not the stereotypical tech interviews. As an industry, it's great to see we're getting better, and moving away from whiteboard coding, dealing with super abstract problems like inverting a binary tree, or doing things that we'd generally just use a Search Engine for in our real jobs.
I would expect a junior developer out of college knows data structures and algorithms. That includes knowing what a binary tree is. And if you know what a binary tree is, it isn't terribly difficult to invert it.
Why shouldn't a "senior" developer know what a binary tree is?
While I don't have much regard for leetcode and hackerrank, I wouldn't want to hire someone who doesn't know about algorithms and data structures and thinks he can solve anything with Google.
Sure, many thinks are solvable using Google, but many require knowledge, experience and practice.
>Unfortunately one company - who outsourced the first part of their interview process - had something similar to this, which I wasn't impressed with. There were some arbitrary questions around several topics, and then in the coding exercises you were asked what the O(n) complexity of time/space were.
The author is even outraged he was asked about time complexity, something even junior programmers shouldn't have a with.
> Why shouldn't a "senior" developer know what a binary tree is?
Because it's not about binary trees. You could as well ask why a "senior" developer shouldn't know what:
- a TLB is
- a Trie is
- UDP is
- consistent hashing is
- the CAP theorem is about
- NFS is
- BFS is
- and a large etc.
As you can see, a question like "what a binary tree is" could easily be as well "what BFS is about". So, it's not about "senior" developers not knowing their stuff, but that there is so much to know about, that certain developers may know better about certain topics than others. For instance, I don't know by heart the algorithm for inverting a tree; sure, I can give it a try and may come up with a solution... but I'm sure a fresh grad student who has studied in the last semester how to inverted a binary tree, will come up with a solid algorithm faster than I can come up with my weak algorithm.
> I wouldn't want to hire someone who doesn't know about algorithms and data structures and thinks he can solve anything with Google.
Same can be said about not hiring someone who doesn't know the basics of Operating Systems (e.g., TLBs), or the basics of networking (UDP vs TCP), or the basics of distributing systems (e.g., CAP theorem, distributed transactions)...
I'm not saying "There is too much to learn about! Please don't ask me anything!", I'm saying that at a given point in time, any experienced developer can provide a poor algorithm (and so fail the interview) to invert a binary tree.
What "inverting" a tree means isn't super clear, but the last time this came up on HN it meant reflecting left to right -- right? So the question tests if you can write code dealing with recursive data structures at all. To me it's strange to think of this as a niche concern and not something you may do every day.
>Because it's not about binary trees. You could as well ask why a "senior" developer shouldn't know what:
- a TLB is
- a Trie is
- UDP is
- consistent hashing is
- the CAP theorem is about
- NFS is
- BFS is
I would feel embarrassed if I were a mid level developer if I didn't know what you mentioned. Many of those concepts I've learned in University as a CS student.
It would be unthinkable for me to for a a senior developer or engineer to not know basic CS concepts. Not knowing advanced concepts and very new techniques is ok, but the basics and the foundations of CS?
As for why you need to know those, it's pretty simple: you will need those in your day to day job to make software design decisions, systems design decisions, come up fast with decent solutions to various problems you encounter, as you won't have time to ask a question on Stack Overflow for anything non trivial.
>For instance, I don't know by heart the algorithm for inverting a tree; sure, I can give it a try and may come up with a solution...
As an interviewer, that is all what I want from you. Show me you can come with a decent solution in a decent amount of time.
>I'm saying that at a given point in time, any experienced developer can provide a poor algorithm (and so fail the interview) to invert a binary tree.
I wouldn't consider to fail the interview for failing to invert a binary tree, provided you know what a binary tree is and you give it a decent try.
Also there won't be questions only about CS concepts, but also on language, frameworks, tools, libraries, databases, architectural strategies, systems design and so on. So the overall knowledge matters.
But what am I supposed to say to a guy fresh out of college who applied for a C# developer role and did not know what a class is? "Our developers will take time of implementing business requirements and teach you what you didn't learn in school and software development on top?" I am afraid my boss would not agree to us not responding to business needs in a fashionable time.
Nothing is stopping you from learning these topics on your own. In fact the vast majority of these topics I learned about on my own before encountering them in university.
The problem with asking mainframe questions is that they aren't as relevant in today's landscape. Meanwhile TLB is relevant for performance, UDP is a very common network protocol, consistent hashing is relevant for designing distributed systems, etc. Especially if you are just self teaching yourself you aren't going run into a chance to work on a mainframe unless maybe you use a mainframe emulator, but why?
Memorizing stuff that any reference book can tell you is a waste of time and skill.
Knowing when to use a binary tree is much more important.
Knowing not to write a binary tree and using a library is a delivery saving skill.
At least abstract problems off a whiteboard show candidate problem solving approaches. But dry coding koans are absolutely a waste of time for anyone involved and tend to produce teams that care about knowledge tidbits hoarding instead of, idk, serving the business that pays them producing value.
And rest assured, there is no value in writing a binary tree for the business. As a matter of fact if one of my dev doesn't use off the shelf components for these kind of things they'd get a stern talking about time efficiency, security and the likes. Why would I go and stress that at a interview?
>Memorizing stuff that any reference book can tell you is a waste of time and skill.
If you are ill, would you prefer a surgeon that will search on Google doing surgery, ore or one that knows how to do it?
Would you be happy to fly with a pilot that will search on Google how to land?
>And rest assured, there is no value in writing a binary tree for the business. As a matter of fact if one of my dev doesn't use off the shelf components for these kind of things they'd get a stern talking about time efficiency, security and the likes. Why would I go and stress that at a interview?
Of course, for trivial stuff you won't need binary trees. But you're wrong in assuming all software is trivial and all problems are solvable with library calls.
And even for trivial stuff it's important to know and understand the underlying principles and how software and infrastructure works. Otherwise you will take bad decisions like searching lists instead of hash maps. And bad decisions will cost your employer money. Sometimes a lot of money.
So yes, knowledge matters. And experience matters. And problem solving skills matter.
First of, you don't have the same urgency as a surgeon. Management might want you to think you do, but it's all smoke and mirrors. If you don't have equity and stakes aren't people lives, it's not even close.
Second, surgeon do spend time before surgery to freshen up procedures from references, as they see a lot of different things, and while the gist of everything are in memory, the specifics are reviewed with the team before operating.
Are you doing equivalencies out of TV show knowledge by any chance?
> Why shouldn't a "senior" developer know what a binary tree is?
Well, wait a minute. He didn't say it's unreasonable to ask what a binary tree is. He said he was glad he wasn't asked to invert a binary tree on a whiteboard. There's a big difference between those things. I think your reading is uncharitable.
These specific questions don’t help much in my opinion. I prefer asking questions that I know someone can’t game through studying some leetcode crap.
- What was the most difficult problem you’ve had to solve as a developer? They talk about it. You get some data, and you start asking more detailed questions about it for them to elaborate on. Soon you discover if they’re bullshitting, or at least what’s their “technical ceiling” based on what they considered the most difficult thing they’ve ever done.
- Have you ever had a performance issue that you’ve had to debug. How did you go about finding the root cause?
Etc. Basically nothing with a textbook answer. Just get them to talk and not be autistic about it. Surely if you know your craft you’d be able to suss out if this person can solve technical problems and get an idea about how they go about doing it. I really don’t care if you can invert a tree or have memorised The Art of Computer Programming…
Will: Wood drastically -- Wood 'drastically underestimates the impact of social distinctions predicated upon wealth, especially inherited wealth.' You got that from Vickers, 'Work in Essex County,' page 98, right? Yeah, I read that too. Were you gonna plagiarize the whole thing for us? Do you have any thoughts of your own on this matter? Or do you...is that your thing? You come into a bar. You read some obscure passage and then pretend...you pawn it off as your own idea just to impress some girls and embarrass my friend? See the sad thing about a guy like you is in 50 years you're gonna start doin' some thinkin' on your own and you're gonna come up with the fact that there are two certainties in life. One: don't do that. And two: You dropped a hundred and fifty grand on a f----n' education you coulda' got for a dollar fifty in late charges at the public library.
> What was the most difficult problem you’ve had to solve as a developer? They talk about it.
...and then you get accused of trying to steal secrets from their previous company.
In seriousness, we're no longer allowed to ask questions like this in our current interview process, since it could expose us to competitors' internal secrets. It sucks, because it was one of the best ways of determining what a person was capable of. But there's no winning in designing an interview process--every one has flaws.
Now I come up with a hypothetical problem in a related industry, but it's hard to tell whether the person is just failing to think through the problem, or was too unfamiliar with the domain to have useful ideas.
> Another thing to note is that I ended up not really preparing for the interviews. I feel like this is a bit of an arrogant move by me
Well written article. The only part I don't agree with is this though. If I am applying to a company, I do research what the company (and its product) is about. But that's it. I want to know if in my current "shape" and with my current knowledge, I would be a good fit for them.
For me, preparing for days or weeks for a tech interview feels like cheating: "Recruiter: design a distributed key-value store. Me thinking: yes! I read how to do that in How to Crack the Coding interview! I'm gonna nail it!... Recruiter after seeing my solution: Wow, let's hire this guy!"
This is the modern interview practice though. Realistically - you’re not gonna pass at most of the companies here in SV when you’re getting leetcode hards on the regular like I am. Without a lot of practice, you’re gonna fail spectacularly.
>The only company that gave me any compensation for the interview process was GitPod
>Another thing to note is that I ended up not really preparing for the interviews. I feel like this is a bit of an arrogant move by me
And that's how they get you. You invest into what's essentially a second full time job, without any guaranteed compensation, yet somehow you feel you yourself are the arrogant one for not doing more. That's not even highlighting all the other emotional effects the process had on the author, and the author is by no means "average" in their methodology.
I got the idea for the take-home test from the Remote book by Hansson and Fried and I think what they spelled out made sense:
1) Give them a realistic task to work on - this is what you want them to do if you hire them
2) Give them a reasonable amount of time
3) Pay them for it - why wouldn't you?
We did this for one candidate and although your gut feel as an employer is sometimes, "is this a waste of £1000"? but if you are already quite far on in the process, you probably think they might be good enough and that £1000 is offset against the Recruiter fee that you incur when a hire doesn't work out or the loss of a good person you don't hire because you are not sure.
It also shows good will between employer and applicant. We have done it once so far and didn't take on the person but gave them feedback on the task and because they were paid, they didn't see it as a waste of time.
If it were always paid then one could just game the system taking such take home tests as a second job. Since they're relatively small in scope you'd quickly (if you haven't already) build up a code library containing a cache off pre-solved problems allowing you to punch them out relatively quickly. Heck, you could even do it as a full-time job.
I would love this, but the only reason the bullshit is allowed to happen is because people are ready and willing to put up with it. There are simply too many desperate people, many of them third-worlders [1], who will do anything for a meal ticket.
The world would be better if people developed a "fuck you, pay me" attitude, but so many people are inured to their caste.
[1] "Then, don't. I want to move from my 2000 USD a month (this is a good salary alre... | Hacker News." 8 May. 2022, news.ycombinator.com/item?id=24446562.
> many of them third-worlders [1], who will do anything for a meal ticket.
If your people from 'third world' are your main competition then you fucked up your life by not making something out of your 'first world' privilege and educational opportunities.
> The world would be better if people developed a "fuck you, pay me" attitude, but so many people are inured to their caste.
Even disregarding those weird "third world" and "caste" tangents, there are tons of Westerners too who would literally do anything for a software job at a tech company, especially at a prestigious and well-paying FAANG. And, by anything, I mean suffer through any brutal study regimen, inhumane corporate process and any humiliation. Undergrad and advanced degrees, months of leetcode practice, take-home tests and coding challenges, hundreds of phone screens, a dozen rounds of interviews for a single company, staying half-ghosted on a waitlist for months, sending ping after groveling ping to recruiters for updates. There's nothing that's beneath them, and this willingness to endure pain simply raises the level of pain everyone else has to endure.
I have been trying to find a job for the past 2-3 months, and the psychological toll that it has taken on me is enormous.
I planned on going for a PhD, but eventually got tired of academia and of practically starving. I am finishing my master's in December. I have sent out my CV for review in r/cscareerquestionsEU, I have received good feedback, I have been told that my CV is strong and that I may be suffering from my own successes.
Most of the responses by companies are flat out rejections without any information as to how or why. I have been told that I am overqualified for positions. By others that I was underqualified. I have been given excuses of the form "we are looking for somebody who has more experience with XYZ tech" as if there is some kind of barrier that prevents somebody from learning said tech.
At this point I am practically begging for anything to not starve and pay the bills.
I am really sorry for venting here, but I am at a breaking point.
I too was looking for a job last year and it made me wholly depressed. Rejection after rejection, not knowing whether I'd be ask a leetcode easy, or medium, or whether I'd be grilled on some obscure/gotcha language features (C++ takes the crown in that domain). The randomness of it all, passing the technical tests but failing the interview with the CEO. The wide range of topics on which you might be quizzed on. Frontend, backend, javascript quirks, typescript. You worked with C++ 3 years ago? Then tell me what that piece of code does. Sorry it's undefined behavior according to the page 756 of the C++ standard version 17. You don't know how to answer this question about databases and you call yourself a backend developer? You don't know this very specific feature of SQL? Solve this leetcode problem for me. And then again the next day, and the next day, and the next week. And the week after that. And it's been two months and you've been rejected 10 times. And then you go on HN and you read that the market is hot, the market is white hot! But you, you're ready to snap at the first offer that comes to you because you're emotionally drained. Leetcode in the morning, sending applications in the afternoon, then some leetcode again before going to bed. Repeat everyday, even on weekends.
Hold on and try to resist. Also, try to focus on one language / one position. For example you can chose backend / C#. Or Frontend / React. Or systems programming / C++.
In my opinion, if you already went to a few interviews for the same role, you kind of know what kind of questions you are asked.
Also, I find leet code as a waste of time in preparation for the interviews unless you shoot for a FAANGs.
It took me two year to change job. The expectations are absolutely bonkers right now, the selection process capricious and often even if you jump all the hurdles there's little guarantee that salary on offer comes close to what was in the job listing.
Don't be sorry. If anything, people should be venting more and showcasing the absurdity of the job market. We've normalized the idea of just biting through a really emotionally taxing time for no particular reason and companies are taking advantage of it.
I have previously expressed that I do not mind working more or paying more in taxes if it means that the community around me benefits from it. I see it as a form of mutual aid. It is in everyone's best interest to help our community and make up for each other's bad luck.
You should find a position as a junior developer without much problems. Right now is a big need for developers in many countries.
Try to see what is the best web site for your country / region to find developer work. For me is LinkedIn. Prepare a bit more for the interview. By now you should know the type of questions asked.
You can ask right here on HN for a jobs. Also there are periodical jobs posting on HN, you just have to search and find when.
My skillset is mostly in Machine Learning. I had ML internships, research assistantships, an MLE contract.
I can't get junior dev jobs because they are asking for $tech-du-jour and they told me that, they told me that they don't care that I have a master's from one of the top universities in Europe but they care that I lack experience with a particular tech stack.
Then you have two solutions: apply for ML positions or learn a tech stack needed for other type of position. It shouldn't take more than a few months to learn .NET, Java, Python + frameworks and libraries up to the level needed to be a junior developer.
If you need help identifying a type of position and a learning path to put you on track towards a developer job, taking into consideration what you already know and are comfortable with and also the market, I can help with that.
I'd like to get into backend, it seems that go is the go-to (hah) language for it these days. I have experience with C & C++, and some minor experience with Go so the language is not an issue at all. I am just not sure what the best way to achieve experience with the language is.
> Most of the responses by companies are flat out rejections without any information as to how or why. I have been told that I am overqualified for positions. By others that I was underqualified.
Can't both be true?
You have a part-PhD, hence too qualified for almost all entry-level dev jobs.
You have too little experience, hence underqualified for any non-entry-level dev job.
I was expressing that I am in a situation where I am too specialized for regular SDE roles but at the same time I lack the experience to get anything beyond those.
I don't know what to do at this point to be honest.
The PhD stipend is well above starvation levels and you can go to internships during summer to earn more money and accumulate experience. I have seen many, many people in FAANG with PhDs in SDE/DS roles and they can relatively quickly reach senior levels as well.
I don't know your situation but I while there are certainly ultra-competitive CS programs (e.g., Stanford, MIT, Berkeley, CMU), there are many research-focused universities in the US (R1) that are totally good-enough for doing research and getting a recognized degree. In a lot of less competitive universities, there is no admission committee per se; you just email the faculty you're interested in and if he wants to recruit you, then it's basically done.
There are good research universities in the R2 list as well (RIT, IIT, etc.)
I was right where you are about 18 years ago. Take heart. I still have challenges finding roles even with excellent credentials, patents, open source projects, successful companies, massive successes, and demonstrated excellence. It is always a bit wrenching.
I have a brother in law struggling in a similar position to yours.
Something helpful that I've learned being on both sides of the table many times is how much of a random process it can be. The bulk of the effect has nothing to do with you. I find that infuriating but it also has helped me deal with the petty, arbitrary, and sometimes just evil experiences to be patient for the right fit.
I feel that being trained as a software developer is not enough to find a good job. You have to seriously train in job finding. How to write your CV, where to find listings, to which position to apply, what questions are asked on interviews for the positions you are interested in, what to tell on a interview, what not to tell.
I've changed my job 3 years ago after a long time with a company. I was scared about the process, but after some preparation and a few interviews I began to do well. I kind of knew what I will be asked and replied to interviewers what they wanted to know. After 2 years I changed my job again and it was easy. Now, I am at it again and I doesn't seem too difficult. I do better than many engineers. Probably I am not a better developer than them, but I am better prepared for the interviews. Even the way you talk and how you project your confidence matters. If you "read" the guy doing the interview, tell a joke that he will appreciate, talk about something that you think he will approve, will win you bonus points. Being pleasant, Mr Nice Guy, will help because interviewers are people and they want to have good team mates who they will have a great time working with. This might even be more important than engineering excellence.
I agree that there are factors unrelated to ability to fulfill the role that increase the probability that a person is hired. That is simply a failure that some are more willing and or able to take advantage of. A good process evaluates ability to fill the role.
Compensation for an interview for a job that even poorly compensated would put you in the top 5%? Talk about privilege. I'll happily do the interview on my own time for that potential payout. Push back? I'll be taking your job.
The problem with "letting the market decide" (which is very similar to what you're suggesting - "If you don't want the interview I'll take it!") hides long term (negative) impacts and costs. "Letting the market decide" has made fossil fuels cheap enough that we've got a climate crisis.
"Sure, we destroyed the planet, but for a brief period of time the hand of the market ruled fair!"
That's an awful lot of assumptions. These practices are happening outside the very lucrative tech hubs as well. If this was just the hubs, that'd be something else entirely.
Nor do I believe constantly encouraging more and more competition is in anyway healthy for society as a whole. Companies are already facilitating burnout cultures as is, and it's not at all evident if this benefits them in the long run.
Even if you aren’t in the “very lucrative tech hubs” and you’re making about $140K, a salary you can get in any large metro area in the US within 5-7 years and strategic job hopping, it still puts you in the top 10% of earners
Wouldn't that be more reason to push back against this?
There's an implicit assumption that more sessions -> more security. I've yet to find evidence this session inflation is doing anything beyond making companies feel more secure.
Same goes for a lot of other things related to interviewing. If there's no clear evidence, it should be treated as the bread and circuses it is.
I’ve found that the more people you throw at a candidate the higher the chances that _someone_ is going to find _something_ they don’t like about him/her and burn them in the end, especially when approvals have to be unanimous. I’ve seen engineers give glowing praise for one particular candidate but they got passed on because they made some comment about disliking scrum/agile/jira and that just rubbed the 2nd project manager they interviewed with the wrong way.
I’ve found that the more people you throw at a candidate the higher the chances that _someone_ is going to find _something_ they don’t like about him/her and burn them in the end
I can't emphasize this enough. Successful interviewing is about pattern matching and what this really speaks to is more people means greater risk someone isn't properly calibrated on their pattern matching and their feedback negates someone else who's pattern matching is spot on.
Right on. Never say anything you've not been asked for. You don't need to create traps for yourself.
Interviewing sucks...
The best jobs I had I just started on -trial- or whatever doing good work on their GH and from then i'ts pretty easy to know if we're a match or not.
(Paid) Trialhires should be a more common thing.
Companies should hire and fire more easily. I just don't understand I work mostly as a contractor so they really can fire me with 1, 10, or whatever days in advance...
It's not like I'm an employee with protection to being fired or compensation or whatever...
It's not reasonable to expect a candidate to give up their secure job / salary for a two week trial. It gets more complicated as within the first weeks you're probably mostly ramping up and not very productive yet, so it's both a cost-sink for the company and difficult to judge anyhow.
For fresh graduates this might be more viable, but internships are already a thing.
Once you are in your... 30s 40s 50s etc, maybe family and mortgage... You're not going in for a two week trial hire.
ANd it may not make sense for companies either. A lot of positions I hire for need 3 months to be productive. The level of business and client knowledge, as well as prices and policy understanding required for tech positions is high. That may not be the vocal HN experience which is a lot about interchangeable tech on modern frameworks but I think actually comprises a lot of enterprise IT. Basically we need to invest a lot in you before you are productive and we can truly judge fairly your actual on the job performance.
Heck if you work for public sector, you may not get your laptop and Id in first two weeks at all :-)
>The level of business and client knowledge, as well as prices and policy understanding required for tech positions is high.
Whenever I read this advice, I get "indie game developer" vibes. Indie game developers wear many hats and need a lot of breadth for obvious reasons: they don't have a lot of funds, they don't have a lot of people, they don't have a lot of specialist work you'd need someone for full time, but they do have a lot of different things that need to be done.
Then I compare it to your regular corporate job, and it's the opposite in many ways. Tons of people. Tons of funds. Some people very specialized, some people somewhat generic for flexibility purposes. It makes me question why a developer in a corporate setting would need high levels of "business and client knowledge", or even "prices and policy understanding". Not because they aren't useful in theory, but because there's almost always someone with far more knowledge and decision-making power pulling the strings, to the point having such dedicated knowledge is more a waste than anything. The developer can't get to their level without sacrificing development time, or being with that company for a ridiculous number of years.
And we already know companies in general aren't optimizing around long tenures.
"Prices" was meant to be "process", but too late to edit :(
And "business knowledge" is meant to be at a technical/tactical level, not at a strategic level. For example, an ERP developer implementing a new HR functionality benefits tremendously from being aware of HR law & process; a developer implementing T&L functionality benefits from being aware of T&L processes and business requirements; etc. This makes it a productive conversation of peers between functional and development teams, and they help each other create true and accurate requirements and specs that cover the edge cases.
A developer that ONLY knows the technical aspect, in my world, will virtually forever be a "junior" developer, as I cannot send them to meet with functional teams solo and expect useful requirements to be gathered or correct code to be produced.
The "client knowledge" is for process & procedures. Again, a developer that is junior/new to my project (they may be senior otherwise) will not have sufficient understanding of how our current public sector client needs code created, reviewed, approved, migrated, validated, etc. There's heaps of procedure... I'm not saying that's necessarily a good thing, but it's a fact of life in much of enterprise IT.
Overall point being - 2 weeks trial would not work on any level. Developer would not know process and procedure, and would not have sufficient understanding of client's business and functional requirements and processes, to be productive yet for all but most generic and trivial of tasks.
Finally, to your last point, my project / department / team / org does optimize for long tenures (that is of course empathically not the case in some other business units in same company that I'm aware of have different business plans and methods predicated around fast turnover). Each person is consciously an investment in continued training and support. We are pragmatic about turn over, but we do optimize around and crucially for people sticking around.
>
I think that works great for 1st job.
Once you are in your... 30s 40s 50s etc, maybe family and mortgage... You're not going in for a two week trial hire.
In my country all companies are having a 3 months probation period, when they can fire you without notice or reason, as the laws allow it.
We have a 3 months probation period as well. But we practically never invoke it. Something has to be really truly egregious for that to happen. Again, it's all about investment. On-boarding and off-boarding a full time employee is a major overhead in most companies' business process flow chart. It's far more practical for us to invest another hour or 6 in interviewing, then multiple magnitude of effort more in on-boarding.
I think, to sibling poster's point, there's a massive difference in approach and reality to both company and employee in "hop on, maybe we'll fire you if it doesn't work" (probation), vs "hop on, maybe we'll hire you if it does work" (trial).
I for one am not at a point in my life where I'm even remotely interested in trial hire, either as hiring manager or an employee - FWIW, YMMV :)
Yes, there are often probationary periods with varying degrees of formality. But, in practice, these are mostly reserved for something going really wrong in the hiring process, e.g. someone not being able to do things that they said they knew well.
A trial period could be the same thing but it could also be "We usually extend permanent offers to about a third after the trial period." If it's a formality that may be one thing. If it's an extension of the interview process, that's something else.
In the U.S. that's called at will in most states. They can fire you for no reason as long as it's not one of the limited reason protected by the federal government. It doesn't matter how long you've worked there.
This is contract to hire which is perfectly valid but not something most companies will agree to.
I think it’s due to conflicting goals. The department hiring wants to lock in the employee so they can cross it off their todo list, and fix the cost. They don’t want to train a consultant who’s still lining up other work. Once the consultant has been trained he or she is in a better negotiating position since they haven’t agreed to a salary yet.
Corporate wants to require a probationary period so they can wiggle out of it with least expense in the unlikely event they have to.
Ideally after a probationary period the employee can renegotiate their compensation, but this is seen as bad faith and holding the company for ransom and creates bad feelings.
It’s funny because I literally just a just ran into a friend who owns a restaurant after I posted.
He complained about being short staffed and not being able to handle the cooking work while being sociable with customers (he’s one of those guys who sits down with his customers).
I asked him what happened to his last chef. He said he trained her up and she quit, so now he’s screwed. I asked him if he could have kept her if he paid her more. He looked at me like I was crazy and said she was already being paid too much. I responded, Oh, so you couldn’t afford to pay her more? He said it wasn’t about that, it was just crazy that he should have to pay her more.
I kept my opinions to myself and just said “I hear ya. That’s rough man.” He said “Loyalty is dead”…
A counterpoint to this is that our process generally looks for at least one "Strong Yes" among the interviewers. While they do come up, there aren't _that_ many "No"s in the results, but there are a lot of just "Yes" results.
Not saying it's a perfect process, but just providing a counterpoint that our process actually seems more likely to help someone with the rounded set of interviews we have than we would with fewer.
Depends on the company, but they should. This is a big decision for both the company and the candidate. Both should put a little effort into it to avoid a situation where someone who is hired is unhappy or not a fit for whatever reason.
The secret is to make sure the time invested on both sides is actually increasing signal, and to make it symmetric (ie at any point in the interview process both sides should have invested roughly the same amount of time).
The company is built by investment from VCs from hedge funds from 401k or pensions of real people who not only need to sleep, but on average make less then senior software engineers.
A senior dev role is an income stream of USD n 000 000 dollars a year, that has certain guarantees about payments. In this context it makes sense to dedicate a considerable amount of personal time and effort to capture one.
> … yet somehow you feel you yourself are the arrogant one for not doing more. That's not even highlighting all the other emotional effects the process had on the author, and the author is by no means "average"
Learning techniques for managing one’s emotions and stress levels can pay huge dividends here.
Part of that is stepping back and realizing that the “rules of the game” of resume/interviews/offer were written by employers, for their benefit first. (One technique for addressing this is to beak out of this process, and reach out to hiring managers directly. Professional sales people do this all the time; I’m not sure why selling labor is somehow magically different.)
I suppose that since Jamie is based in Nottingham, U.K. [1] then we should adjust the currency and number of zeros for his particular locale. My understanding is that senior software developer roles in the U.K. are also considered professional-level jobs that pay very well relative to other professional-level jobs in the local labor market, similar to the U.S., and are worth putting in some extra time and effort to get.
I think the same is true about senior software developers in many other countries: They are professional-level jobs that pay well relative to other professional-level jobs in the local market, and they're definitely worth taking some time and effort to get.
Feel free to provide specific examples of countries where this isn't the case.
It's not only that the rate is adjusted for locale but that the disparities in USA are much larger.
In USA a very senior engineer at a FAANG in California will earn 20x times more than a junior engineer at some small midwest company. In UK a very senior engineer in London will earn perhaps 4x that of a junior engineer in Wales.
In USA "pays very well relative to other professional-level jobs in the local labor market" will often mean a compensation that's double or triple of those other jobs; in UK "pays very well relative to other professional-level jobs in the local labor market" would imply a 20% or 30% difference.
(former hiring manager here) depends on seniority of role and candidate. If you are interviewing for an Eng I or Eng II role (or even more junior, if the company does that) at a large tech company you are likely going to get a 'blind interview' (where its yet to be decided which project you will work on) and then if you are successful, assigned a team based on need within the organization.
It's the reality of how large organizations keep their teams stable with employee turnover and also slightly grow them. Yes, teams will work to fill their roles directly too but often the team will show up for work on a Monday morning to find that they have a new member of their team who they've never met but is an 'extra bonus' or the headcount has been filled anyway.
If you are likely to be interviewing for Eng I/II you should not be surprised if parent's option 1) is the route you are presented with - I think it's wrong to say "you only want to spend time on 2)" as it's unrealistic for early career folks and they risk missing out on exceptional opportunities to get a foot in the door.
>It's the reality of how large organizations keep their teams stable with employee turnover and also slightly grow them. Yes, teams will work to fill their roles directly too but often the team will show up for work on a Monday morning to find that they have a new member of their team who they've never met but is an 'extra bonus' or the headcount has been filled anyway.
> I’ve never heard of any company going out of business because one key person left.
Companies don’t die that quickly. It may not be one person but it might be a handful of high performers who leave over time due to a toxic culture. And even then it may take literally years for a VC cash infused zombie company to actually cease operations. One of the problems of having so much cash is bad decisions don’t reveal themselves until much later.
2. recruiters who insist on scheduling on phone call when it can just be an email/text.
3. endless rounds or interviews with all sorts of weird stuff,
1. Take home assignments
2. hackerrank puzzles
3. pair programming on 'real world' problem
4. Open a PR to Open source repo
5. leetcode puzzles with stuff like dynamic programming.
with 2 mediums/ 1 hr speed.
6. 'system design' interviews url shorterner with caching/replication/sharding/consistent hashing
7. 'behavior interview' .pre made answers to what was your biggest mistake. how do you resolve confilict with teammates.
8. Debugging sessions to find bugs in existing code.
9. 'real world case study', 1 hr presentation of challenging problem you've solved in ur career.
10. 1 hr 'life story' interview where you showcase your passion for work and life.
11. product design interviews. how will you improve our shitty product.
This is way more common than you think and it seems like it's a tragedy of the commons.
Companies struggle to hire, yet have crazy demands and interview practices that filter out good candidates with potential, because they're looking for the 'perfect candidate', whatever that means to them.
From my experience, the whole shortage in this industry is mostly companies being too picky, because they're afraid of the small chance of letting in a less ideal candidate. And I'm not even talking about unicorns/FAANGs/big-tech, but regular companies.
What is baffling? OP explains that they didn't have certain things on their CV. If I was hiring for a JS app and the applicant was all Java or .Net, it is no disrespect to them to filter them out at the CV stage.
I can only speak for myself but as a Dev of 20 years, mainly in .Net (but with Java, Obj-C, PHP and JS experience) I wouldn't dream of applying for a JS job because despite the trope, it is not easy for a Senior to switch languages and just pick it up.
> it is not easy for a Senior to switch languages and just pick it up.
This surprises me. I have 15 years of experience in the field, and it was many years ago when I got my degree in computer science. Back in the day, they thought me algorithms and what not using pseudocode (!)... nowadays I can easily pick up any tool (programming language, framework) in, I don't know, a month? Of course I won't be the best developer out there with 1 month only, but pretty much I can be productive. Sure, if one is switching from, let's say Python to Haskell, then the learning curve is higher than if you switch from Python to Ruby or JavaScript. Still, it still amazes me seeing some developers call themselves "PHP developer" or "Kubernetes architect".
Languages are easy, it’s the ecosystem, framework and best practices that take time.
Any developer can pick up Java or Swift in a month. That doesn’t mean you could turn them lose and tell them to write a mobile app by themselves or lead a project doing so in a month.
A “JavaScript developer” is useless as a front end developer if they don’t know the clusterf^# of the modern front end ecosystem
I was a “C# developer” until 2020. That implies I knew the ecosystem, frameworks, corner cases, best practices, what could go wrong at scale if you used the different frameworks incorrectly etc.
What I didn’t have to do - ever in the last 12 years of my career - is reverse a binary tree on the whiteboard while juggling bowling balls while riding a unicycle on a tightrope. I went into smaller companies and got hired based on my expertise.
Even now, I didn’t have to go through the DS&A grind to get into BigTech where I code everyday because I was able to sell myself as an “enterprise developer who knew how to lead projects and talk to customers and I specialize in architecting solutions on their cloud platform”. Does it limit my optionality? Definitely. I’ll be working on that over the next couple of years.
I'm going to rail against this. The far majority of tools are not so obscenely complex you can't learn the majority of it. The far majority of jobs are not so obscenely difficult you need the bleeding edge implementations available in those tools. Looking online, the amount of information available to do what you want is insane. There's almost always someone who has already done things, especially for technologies older than a few years.
This is even more problematic considering this selection is done on framework and library level as well, and many other tools. At the same time, making a tech stack is much like creating an ice cream cone with thousands of flavors, decorations and even cones available.
Language agnosticism and general intelligence should be applauded far more than the industry currently does. Many toolmakers are doing their best to make using their tools as seamless as possible, and they are doing a good job at it.
Sure, and if I may I'll politely rail back as a former hiring manager... :D
I have no doubt that the senior software engineer with plenty of .net/python/whatever experience could pick up the needed JS if they were given the position. But there's going to be extended ramp up time as they familiarize themselves, they won't know the libraries let alone their intricacies and idiosyncrasies etc, they won't have a lot of language specific fresh approaches and experience to inject into the team (which I'm looking for in a senior+ role). I would rather just hire someone who already has the deep bench of JS experience at the same level.
Language agnosticism and general intelligence should be applauded far more than the industry currently does.
The reason for this is because I'm not hiring for the craft of software engineering, which your perspective aligns with, I'm hiring to achieve business objectives quickly, efficiently and to a high standard. Not realizing that most hiring businesses are optimizing for the latter and not the former is what trips a lot of career software engineers up. You see yourself as a craftsperson, the employer sees you as a resource to achieve their business objectives.
>I'm hiring to achieve business objectives quickly, efficiently and to a high standard
Don't misunderstand, I do understand the point of view from hiring managers. But in the current job market, where people change jobs rapidly to actually obtain said knowledge while at the same time technology continues to change rapidly (often repeating the cycle rather than actually innovating), surely it should be evident this isn't going to be efficient if not sustainable in the long run.
If anything, you're giving people the exact arguments why we shouldn't trust companies to act for the good of the industry long term.
I’ve been actively using .Net since 2008. Sure it changes slowly with the biggest change with .Net Core and ASP.Net Core and EF Core. But it didn’t take that long to learn the differences.
>The reason for this is because I'm not hiring for the craft of software engineering, which your perspective aligns with, I'm hiring to achieve business objectives quickly, efficiently and to a high standard. Not realizing that most hiring businesses are optimizing for the latter and not the former is what trips a lot of career software engineers up. You see yourself as a craftsperson, the employer sees you as a resource to achieve their business objectives.
You put it in an interesting way. But FAANGs and big tech are businesses, too. They would want to achieve their business objectives, too. Still they hire someone who is not proficient in a particular language / framework if he is a good developer. Maybe the time it takes for them new hire to ramp up is worth.
> I would rather just hire someone who already has the deep bench of JS experience at the same level.
I love frank advertisements. Just put your real requirements up front and don't interview anybody who doesn't (claim to) fill them. Then it's fair to call bullsh*t.
No complaints about the salaries you have to offer or the thin pool of applicants, though. It's all a tradeoff.
I guess I'd like an evaluation as a hiring manager: does it work? Are you able to hire the people you want? If it's working none of this HN bellyaching matters.
That's quite correct. You want an expert in X, you should pay the high price he will ask. Unless you settle for an expert in Y and give him time to get good in X.
Generally there is an onboarding period for engineers regardless of seniority. I think this tends to be a lot longer than the time needed to pick up a new language.
There are also a lot of valuable skills that transcend writing code. I'd argue these are probably more useful in achieving business objectives quickly instead of just having another warm body to write code.
Given the above reasons, it seems odd to me that you would discount an engineer solely because they don't have experience with the stack. I guess it depends what you're looking for though. If you specifically want a JS expert who will bring best practices and new approaches to the team then it makes sense, but otherwise I don't see it.
> But ... they won't know the libraries let alone their intricacies and idiosyncrasies etc
triggered a related thought (also closely related to recent "how do you learn effectively?" and "I'm exhausted/burned out, what do I do?" HN threads):
In my most recent job-search, I found this type of expectation/requirement (specifically regarding deep (down to idiosyncratic) library (aka framework) knowledge & experience) to be the most off-putting. The likelihood that I will have used a specific library in the ecosystem your team/company has chosen in its pursuit of "teh hotness" is (to put it mildly) low, but I'm certain that my resume will be discarded, or worse, an interview process spun up but doomed because I'll be unable to regurgitate library documentation chapter and verse (much less idiosyncrasies (many of which may be version specific).
The proliferation of libraries/frameworks seems to be exponential; how would I ever acquire deep knowledge of the complete set of same that are considered "today's hotness" (both today and of the past N years) in an language ecosystem which I have extensive experience and familiarity with? My current employer/team has made its language and framework choices, and I'm bound to them for (typically) years, and I focus (for years) on being productive in that context. Am I expected (in the context of my next job) to have spent my non-working hours gaining/maintaining knowledge of both the contemporaneous competing frameworks (which current employer/team didn't choose, but came in close second, etc.) as well as each "new hotness" that comes along? The alternative appears to be that my future employment possibilities are continually being reduced/narrowed as the set of libraries/frameworks in popular use expands (exponentially) while my knowledge remains tightly focused within the domain. Even if I was willing to make an investment in self-study to learn a new library/framework well, given the above-described circumstance, what would be my criteria to make a wise choice? And if presented with the same question 6 months later, what is the likelihood I would make the same choice? I'm pretty sure the answer is not "100%".
In practice, I simply did not apply to the vast majority of job listings which I would have considered myself otherwise a good fit (i.e. could immediately grow into), due to this factor.
If my company is using a standard tech stack - React/Angular on the front end, Java/Spring or C#/.Net Core on the backend or some similar popular framework - I can throw a rock at a recruiter and they can find me plenty of “good enough” developers who can “hit the ground running” well enough to do your standard full stack CRUD app
On the hiring side, why should I invest time for you to “grow” and do negative work in the beginning just for you to leave for another job?
Yes, I realize it’s the company’s fault for not offering competitive salaries to incentivize you to stay. But often as the (hypothetical) manager, that’s out of my hands.
> I can throw a rock at a recruiter and they can find me plenty of “good enough” developers who can “hit the ground running” well enough to do your standard full stack CRUD app
But those developers might cost you quite a lot. My current employer has trouble hiring new people. Speaking with recruiters and hiring managers from a few companies (as I'm in the process of changing jobs) they told me it's hard to fill their positions.
Whenever I interview I present myself as a developer with more than a decade of experience that wants $X / year and willing to go a bit lower for the right company.
Whatever other categorizations they might have for me, is on the company. Ultimately I don’t really care.
Well, ditto. The most meaningless job title I ever wound up with was "Senior Systems Architect" - really only something they could put on my business cards so they could sell me for consultancy gigs. Bah!
It's not what they call you, it's what they pay you - call by reference versus call by value, I guess.
>The most meaningless job title I ever wound up with was "Senior Systems Architect"
hah, when I was employed by the Danish under ministry in charge of standardization (called IT og Telestyrelsen at that time) management people came through one day and asked what titles we wanted, and for various amusing reasons another guy and I said we want to be called "XML Architects".
> It's not what they call you, it's what they pay you
This is correct because if I'm writing checks, the one making the most is generally my "senior" person.
I suppose this doesn't scale well though, especially when you start talking about niche skillsets where being objectively "good" gets conflated with "useful at the moment."
>Whenever I interview I present myself as a developer with more than a decade of experience that wants $X / year and willing to go a bit lower for the right company
I present myself as someone with plenty of experience in both writing code and software architecture. Someone they direly need and will help their business achieve its goals for at least X amount of money. Which would be a great deal for them even if it doesn't sound cheap in the beginning.
Many told me it's too much. But a few have said yes.
You should think about the largest amount you think you can obtain. And add 15 - 20 % on top. You will be surprised in finding that someone will say yes.
Yes, it's meaningless among developers, but not among recruiters. Since I work first and foremost in exchange for money, I make it pretty clear to recruiters that I am "a very senior software architect with knowledge in X, Y and what not under my belt"... and so, I get more offers and got more money when negotiating an offer.
Among my colleagues, or when someone (not a recruiter) asks me what I do for a living, I say: I'm a computer programmer.
If we can all start making progression ladders a normal part of a dev team then we recruit for a rung on the ladder rather than an arbitrary title. Then us Devs will be less precious about "That person said I wasn't a Senior", instead we can try and convince our prospective employer that we can e.g. "Consistently produce high quality code", "Is a thought-leader in new frameworks etc."
It also allows conversations about salary to be more open since we pay a range for a specific level and not a massive range of 20-100K depending on how good somebody interviews or how much gall they have asking for more than they deserve!
? I found the label to be highly useful as an adjective descriptor. At the highest level it is a way to distinguish between Intelligence and Wisdom. Wisdom requires experience, but experience doesn't indicate Wisdom. A senior role has to be someone who can mentor junior roles and has fairly well developed soft skills. I can put a senior in front of a customer.
When choosing between two candidates for a senior role:
Candidate A has: Int 16 Wis 10
Candidate B has: Int 14 Wis 12
It was a D&D reference. I figured any geek would grok it. I was just making the point that intelligence alone does not make a good hire for a senior position.
Of course the specific methods of evaluation are complex, but I would argue that it is easier to evaluate wisdom by asking experiential questions.
>Knowing that I had two offers, and that I had gone through a very long process with them and having received an offer, I knew that I was a candidate they'd like to hire. This is the perfect time to get that extra worth, as you hold a lot of the chips, especially with two offers.
This has always been really hard for me to do, particularly if I actually am happy with the offer. It could be imposter syndrome, where I often feel like I don't "deserve" it.
I would try to disassociate my work income from my personal worth as a worker. We always leave some money on the table, but can always do all the steps we can to reduce how much we are leaving on it.
In case I have an offer that I'm actually happy with, personally I'm the opposite. I already reached my expected range, failing to negotiate for more doesn't worry me so I can do it more confidently, which may kind of help me in a way. Don't ask for too little tho, they may notice they can get you less than what you are asking by holding firm.
I've always found system design interviews to be a bit... weird. Designing a complex system generally takes at least a few days (at smaller places) up to weeks or months at larger places. In addition, the solutions always seem to be biased towards solutions that fit with existing technology/knowledge (which is good).
It's not very easy to encapsulate domain knowledge and research heavy questions into a small interview slot so some of these can feel quite contrived.
If you've done complex system design for a long time then it is possible to breeze through these interviews almost on autopilot. The key is not the "design" per se but asking questions that rapidly constrain the design space and understanding the implications of second-order effects. If you do this regularly, like I do, it feels like a straightforward mechanical process rather than something that requires hard thinking. Muscle memory. System design is largely independent of a specific app or tech stack.
I tend to burn through these interviews so quickly that we have time leftover. It was always the easiest part of the FAANG interview process for me.
The thought of these questions, and engineering more generally, boiling down to intelligent dialog trees hit me like a ton of bricks a few months ago. I've been investing time into deeply thinking about these trees, and it has been one of those things that have made me feel like I've 'leveled up' in my career journey. It's very validating to read your comment, and it makes me feel like I'm on the right track. Aside from plenty of practice, do you have any good reference material or advice to share on improving this skill set?
Yeah, dialog trees is a good way of describing it. Every answer to a question directs the subsequent questions. After a long while, you've more or less memorized the common branches of the tree. I benefitted, accidentally, from working in wildly different systems engineering environments, which gave me intuition for large parts of the phase space e.g. exotic silicon supercomputers, massively parallel clusters, federated systems, cheap-ass computers, etc for various workloads. It gives you a better appreciation for the tradeoffs. This also requires understanding how silicon actually behaves, not idealized abstractions.
The other complementary skill is resource accounting -- knowing what everything costs in terms of bandwidth, latency, storage, compute, etc and how they interact. This allows you to look at any combination of hardware system and software workload, and quickly identify the resource bottlenecks. Again, if you do it long enough it becomes very intuitive. Old hands can accurately predict the performance characteristics of a software design on given hardware before a single line of code has been written, even if the design is novel, just through resource accounting. The application of these resources involves tradeoffs i.e. you can trade an excess of one kind of resource for another resource that is scarce with clever algorithms and architecture (e.g. classic space/time tradeoffs but more so).
Unfortunately, I don't have any reference material. I learned by doing over a very long time.
Computers are closed finite systems, use of resources is a zero-sum game. You cannot optimize aspects of the system design in a vacuum because they are all competing for the same set of resources. Resources applied to the optimization of one thing is the pessimization of something else. You have to apply them where they make the biggest net impact.
A concrete example is cache replacement algorithms for storage. The ideal metric is cache hit rate i.e. the percentage of the time that the storage you were looking for is in the cache -- higher the better. Literature is full of academic algorithms that focus on improving cache hit rates under a variety of workloads.
In many real systems, the cache replacement algorithm is in the hot path. Most "efficient" algorithms in literature either have poor CPU cache locality or thrash the CPU cache, causing significantly worse performance than is offset by the marginal gains in cache hit rates. Knowing this, good cache replacement algorithms are explicitly designed to minimize CPU cache locality/thrashing problems, at the cost of slightly lower cache hit rates because it has higher throughput in real systems. In this case, allowing the CPU cache to work efficiently is more important than a better disk cache hit rate.
In complex systems, the optimal algorithm in isolation is almost never the optimal algorithm in a system. There is a global resource budget. By "second-order effects", I mostly meant understanding how subtle design choices for one part of the system will tacitly interact with the performance of other parts of the system by virtue of how they use global resources. More broadly, this is the discipline of accounting for the hardware resources available to the software at any point in time and identifying conflicts for those resources.
Yes thanks, I took it to mean understanding what are likely to be the bottlenecks in a particular system and how your design assumptions might shift those bottlenecks, which seems to dovetail with what you said above. Having said that your example above is interesting, I hadn't thought about conflicts between the cache algorithm itself and the cached data in memory.
That comment made me think of things like data relations that would require indexing or lookups on foreign keys/IDs. Or bottlenecks in components that perform hefty transformations due to the design of the data structures or unbalanced data sources, like where you need to merge infrequent but large chunks of data with smaller but much more numerous chunks from another async source.
> Designing a complex system generally takes at least a few days (at smaller places) up to weeks or months at larger places
That's designing it completely. In the interview, you're not expected to produce the final result; more importantly, it's not even about the result, but about the thought process and conversation.
It's a maximally open question which turns into a guessing game where you are trying to match what the interviewer has on their mind at a given point. Some of them just want you to collect requirements, which makes them feel smart because they didn't go too much into details in a short time, others want you to actually describe how you'd implement that something and you have to come up with an imaginary users, imaginary infrastructure and all the world around it just to ground your concocted solution into it.
Some (big tech) companies tell you to prepare for the test, because they try to standardize the system deaign open ended question. They end up selecting those that dedicated weeks of time learning for their version of the test. For the others it's a psychological game trying to predict what is on the mind of the person asking the questions.
This is a very negative view of what an interview is. Most interviews, however carried out, couild be described as "trying to predict the mind of the person asking the questions" but most interviewers are trying to get a realistic view of the applicant with very little objective information.
The bigger the company, the more likely people have "trained" up to try and give themselves an advantage over others. I don't think companies are necessarily looking for people who have dedicated weeks of learning, but that learning can certainly make the applicant look smarter than they might be.
Please. I’ve been asked why I didn’t use specific features of kafka in my solution and “because I’ve never used it before only these other pubsub systems” was not the right answer.
Without the context, it is hard to know what this means. If they are a company that heavily uses Kafka, then there could well be an expectation that you would have researched it and at least learned enough to have an informed discussion.
Other employers might expect someone who is "Senior" to know about what different languages offer. As others have said, the title "Senior" means different things to different people and not all skills are transferable.
As others have said, if they don't do interviews well, don't sweat it, you probably don't want to work there anyway!
As someone who does “system design” for a living - I specialize in application development, but I get pulled into the architecture side also - if you give me a set of requirements including your requirements for scalability, high availability, disaster recovery, do you need immediate vs eventual consistency, networking requirements etc, I can usually walk through and diagram an ugly (not aesthetically pleasing) whiteboard solution relatively quickly. I can get you a good diagram in a half a day. Most of the time, the actual implementation is not too far off my initial design.
Knowing how to do system design is no different than knowing how to do DS&A (which I’ve never had to do at any developer interview between 8 jobs over 25 years). It’s all about recognizing patterns.
What really amazes me about the software engineering interview process at larger companies is that they are given theoretical system design scenarios instead of asking them to walk through their real world experience.
Both in the latter part of my interviewing in the real world at small companies who needed someone with experience to help them scale and my interview for my current cloud consulting position at $BigTech, they wanted to make sure I had real world experience and understood the consequences and trade offs of my choices.
System design is the blind leading the blind. An interviewer whose never written and wouldn't recognize a "scalable architecture" before asks a candidate to design one in front of them. The candidate pretends to write a scalable architecture, and the interviewer pretends to know when it's correct.
System interview skills are best taught with a class on how to use "Microsoft Visio".
as with other things: it helps to understand the format and to know what to expect.
also, when I am asking a system design question I am not looking for a perfect design or even a design in particular. at the end of the interview I ask myself the question: given enough time could this person evolve what they have into a design that would work in the wild?
> This other company, however, gave me feedback that "if this was how you worked on a team, it'd be perfect, and we love it. But in an interview, that's not what we want"
The tech interview process is still so completely broken in my book. Nobody really knows what anybody wants or how to show it 1 hour blocks (for both parties - applicant and employer)
It's such baffling feedback. I can't even comprehend what it's supposed to mean or why someone would say it. Are they trying to look for a rock-star interviewer who is a total disaster for the team?
It's possible they had a rubric for the interview which implicitly assumed a certain way of answering. Since the whole point in that case is to strictly follow the rubric to lower bias they had to reject.
Are they trying to look for a rock-star interviewer who is a total disaster for the team?
That's one interpretation. Another is that they're scared shitless and have no idea how to go about this other than to cargo-cult as many filter questions they can from other people's process, and then, well, see what happens.
Just sent two-week notice last week. ~30 applications, 3 offers. I was interviewing with both tech and "non-tech" (software engineer/research role at traditional STEM companies). The stark difference is that for tech companies the track record carries little weight (me with 10+ years dev experience, proprietary and open-source), while in "non-tech" companies the decisions almost solely based on my experience (projects, publications, etc). For the latter all I needed to do is either give a presentation or a round of 1-1s chatting about my work. The tech company interviews gave me an impression of being replaceable: passing these tests then we'll welcome you as a screw of our well-oil machine. What gets me most is that I was still got asked behavior questions like "do you think you are a team player?". (I decided to be snarky on that FANNG interviewer and told her "I like being left alone". I was put off by the fact that she's wearing a mask in our 1-1 zoom meeting anyway).
Not particularly - in London, or with a lot of high-funding startups it's more common, but across the country no.
Makes it much harder for local companies to try and compete, even if they're very big. If you see my salary changes over the last year, it's a considerable jump.
Either way, I'm aware I'm gonna be working quite a bit for it :D
Thanks. Yeah that's why my salaries/compensation detail are all public, so I can try and help nudge the needle a bit towards at least having ranges available everywhere.
A comment on the CV. At quick glance it looked like you only worked at places for a year or two then changed. This is generally a red flag for me. But because I saw the salary history I knew there was a Lon time at Capital One. However this was harder to spot on the resume. It might be better to group your experience at a single employer together so your loyalty stands out.
I’m curious if employers ever saw your salary posts and responded.
It seems mainly driven by the funding of the company. A large bank or oil company in the city can easily afford to pay Devs a large salary which is less than their investment bankers which generally means London.
Others like Just Eat made a massive VC raise and had money to burn so why not offer 20% above everyone else and get the pick of the best? They were advertising for Team Leaders in Bristol for around £130K, way more than most people across the country could hope to get.
Of course, with the salary comes the burden of perhaps being part of a much larger team, which might mean more variation, things not scaling or feeling lost in the machine, not making a difference in the big picture.
I applaud everyone who makes their experience and salary public, I think it's super helpful. Based on that info, I am shocked that a "senior developer" with 5-6 years experience would get around 100k gbp total compensation, while in the bay area I personally know at least two people with this level of experience making around $250k usd. Seems hard to believe that immigration law, reluctance to immigrate and / or time zone difficulties are that significant so as to allow such a differential to exist without getting arbitraged away. What am I missing? Even if you assume that the UK jobs get 6 weeks vacation and the US (sf bay area) jobs get 2 weeks, that still only justifies around an 8% difference. And one of those two friends have "unlimited" vacation
The cost of living in the bay area is basically the highest in the world. So after rent, taxes, and food, $250k there is more like $100k almost anywhere else in the country.
The UK has single-player healthcare instead of the US system where nearly all health care dollars go to private companies incentivized to charge as much as the market will bear (how much would you pay to keep from dying?) PLUS a whole insurance industry sitting in the middle and taking an enormous slice of the pie. So healthcare costs in the US are a huge fraction of a US worker's paycheck, even if they are perfectly healthy.
The US tech industry is famous for its 60-80 hour work weeks, especially among the FAANGs, and those companies are willing to pay high wages in exchange.
And at the trailing edge, it's just a different culture and job market all around.
> The cost of living in the bay area is basically the highest in the world. So after rent, taxes, and food, $250k there is more like $100k almost anywhere else in the country.
I have my doubts that cost of living explains the high pay in the Bay Area.
1. Median one bedroom apartment in the Bay Area is about $1.2-1.5k/month more than Seattle, Chicago, Nashville, Orlando, Sacramento, Austin, Fresno for example. That justifies $14-18k/year of pay difference between the Bay Area and those other places.
Also, the median household income in San Francisco is $119k. That's household income, not individual income. That suggests that an individual making $100k should be able to do fine in San Francisco.
2. The average monthly spending on food in San Francisco is about $150/month more than the US average. So that's another $1800 of pay difference you'd need for the Bay Area. Although maybe with the long hours at many tech companies people don't have time to go home and cook, so let's assume that a Bay Area worker needs to eat out all the time. According to budgetyourtrip.com tourists average $32/day to eat in San Francisco, so tech workers should be able to do fine on that. That's a little under $12k/year, so let's be generous and say Bay Area salaries need a $12k boost for that.
3. The marginal state income tax rate in California is under 12% for most tech workers. So maybe that means a company might have to pay another $12k or so compared to what they'd have to pay someone in a state with no income tax.
So far all together that is, with the generous estimate for food, $42k. That's a lot less than how much Bay Area pay is above so many other US cities and thus I suspect something more than just rent, taxes, and food is going on.
That shouldn't always matter for someone arbitraging it though... companies could hire UK-based developers (themselves pretty expensive by European standards as far as I understand) and pay them less than SFBA developers, and that would continue until the salary difference is somewhat sane. If the displaced SFBA developers then coudln't afford SFBA prices, they would have to move and/or prices would have to come down.
Why don't they? Are timezones/regulation/culture/... really more costly than $100k+/developer-year?
Don't get me wrong, as a developer in Seattle I like the gravy train, just wondering when it will end, why it doesn't end, and if I can save enough to retire by then ;)
Other replies have focused on cost of living. I believe that's one factor but everybody underestimates the reluctance to relocate and willingness to relocate factors. After accounting for cost of living, you're still _far_ better off as a software engineer almost anywhere in the US or Canada vs. the UK or anywhere else in Europe.
Remember bay area rates are double to triple what they are in most of the rest of the U.S. as well. There are a few other areas, like Manhattan and Seattle that have inflated rates, and a few specialties, like finance, that have inflated rates, but even in the U.S., $250k is remarkable.
The median is around $100-$130k for a senior software developer. In less-expensive areas, and especially in saturated specialties like web development, $75k is not uncommon.
Salaries in SF are so high because the cost of living is so out of sync with the rest of the country. I live like a king on 120k usd in Philly but would need roommates in the Bay
HN deludes people into thinking these multi six fig salaries are normal and the main thing stopping one earning it is one's choice not to be in a "hot spot". In reality it's not happening for 99% of is whether we are there or not
Hunt often! If you aren't in love with your current job, just keep looking. A good pace is to apply (to more interesting and overall better jobs) every month.
Interviewers react either dumbfounded or almost offended somehow. Most respond by telling me that this is their standard process and they cannot make exceptions, to which I reply that if they want to know if my code is kosher, they can either call any of my former managers, or check my GitHub out.
It has worked out for me so far, though.
Besides, why would I take a job as a senior software engineer, if their threshold to assess my skills is some college level assignment? It just doesn’t make any sense.
hahaha booking.com, I got rejected after screening call.. they must be swarmed with geniuses, or they are probing the market for current salaries, or they're looking for someone ready to relocate to Amsterdam for 65k EUR. What an enigma.
There is a lot of questioning and helpful back-and-forth in this thread, so I’ll toss myself in:
I have been working as a high school English teacher since 2012. Without a doubt, large parts of this job reinforce and feed my core values. I am acutely aware that my job, and the relationships that I develop, matter in a meaningful way; however, my engagement with the job has shifted over the last three or four years, and I recognize that it is time for me to step away from the classroom.
I am not jaded, burned out, or coasting on my commitments. I am merely looking for the next door to open come June.
If anyone is willing to connect about UX/UXR, Product Management - my email is in profile.
> company [···] gave me feedback that "if this was how you worked on a team, it'd be perfect, and we love it. But in an interview, that's not what we want"
What a weird feedback. That sounds like a miscommunication that the interviewer would be responsible for.
The US by far leads the world in profitable software companies and venture capital funding. The competition for talent in Silicon Valley combined with the huge amount of money generated/raised ends up increasing US engineer salaries even outside California over time.
There are other quality of life factors too, that salary will get you a large house with a large garden, at least 30 days annual leave (on top of sick days/maternity/paternity etc) and very rarely is there overtime or crunch
My salary in Germany (€60K) and apartment in a not great neighborhood was €900 a month.
Here in the US, I pull $150K and spend ~3K a month on a studio. I think my standard of living in Germany (besides desperately missing air conditioning) was roughly the same.
I make about €48000 after taxes in Romania. And while the standards of living might be the same, it only matters while we are not competing for the same goods. You can afford a better car than me, better electronics, nicer trips in foreign countries, and so on since those kind of goods tend to have the same prices no matter where you live.
Wow, that's insanely impressive. Can I ask how that's possible? I'm making that *BEFORE taxes, in Austria, Which nets me significantly less than you in take home pay and savings.
> I thought back to something a friend of mine says, "channel your inner middle-aged white man who'd feel entitled to ask for more". (Note that this is a statement said in jest, based on research that men are more likely to ask for raises, and doesn't have any racist undertones)
While I take the joke and sentiment at face value, as a member of said demographic, the word I think they were looking for is "dignity," and while it's a rare quality nobody has a monopoly on, it is precisely the value that institutions try to grind out of you, and what you need to negotiate effectively. It's the x-factor in leadership, the quality that causes dogs to stop barking, the dishonest to froth, women to swoon, children to feel safe, young people to seek mentoring, customers to sign with enthusiasm, staff to be loyal, trades to do a bit extra, service workers to feel elevated, antagonists to cease their hostilities, and yes, employers to give due consideration to whether they have made their best offer.
It was a funny aside in a valuable article, and self-deprecation is a peculiar UK/CAN thing, but I didn't get the impression the author knew enough to make a joke about it, and they should be more confident in the value and integrity they can provide, as they've done some really cool and fasctinating stuff and should own that.
If you need to go through the “mediocre white male” rigamarole to justify to yourself a better wage, so be it. This MWM is happy for you. I’d maybe go with something more like “I’m worth it” or “having confidence in myself is a good thing on its own” but again, whatever works.
> "channel your inner middle-aged white man who'd feel entitled to ask for more". (Note that this is a statement said in jest, based on research that men are more likely to ask for raises, and doesn't have any racist undertones)
Here's a heuristic I've found useful -- if you replace the race, age, or sex signifier and it ends up sounding racist, ageist, or sexist, turns out that your original statement is in fact also racist, ageist, or sexist. Frustrating inclusion in an otherwise interesting article.
"Please don't pick the most provocative thing in an article or post to complain about in the thread. Find something interesting to respond to instead."
I found the comment both slightly racist, and harmlessly humorous. Some stereotyping can be funny and acceptable.
I would’ve found it similarly both racist and harmlessly humorous if the author was going to a party and said “I channeled my inner Jamaican and tried to dance.”
Or if she was going to the interview and said “I channeled my inner German and got there exactly on time.”
Like, it’s fine. Good-humoured stereotyping is fine. Self deprecation is fine. We don’t all have to be passive aggressive all the time just waiting for people to screw up so we can dunk on them.
This gets said all the time but it’s just not applicable. Making fun of rich people is certainly punching up: by definition they’re rich and obviously very privileged, privileged enough to offset constant verbal abuse perhaps, we’d all be happy to trade places with them in a heart beat (take the “being rich” and mean comments - a great deal!).
With being white it’s not so clear here. Being white doesn’t definitionally come with clear net privilege because it’s such a diverse group: your life is likely much better than some devestatingly poor white person in Appalachia, or even just the majority of white people if you work in tech.
As a test for privilege, ask yourself: “would I trade places with a random white person and accept these racist comments”? Is that a “good deal” like with the rich person example? It’s not clear and probably not worth the risk you end up trading places with the many white people in crappier circumstances than you. That’s exactly the proof: many many white people don’t have so much privilege that you’d happily trade places and take all the racist comments too. In other words: it’s really NOT punching up in many many of the circumstances, many of the white readers who see your comment, it is just exactly punching down for them.
Not that the above should even have to be argued, being racist isn’t ok even if it’s punching up, just as sexism against rich women isn’t ok, or homophobia targeting rich gay men. Jewish people are exceedingly successful as a group along dimensions like income and wealth, so it’d be “punching up” in some sense, but does that justify antisemetism? Of course not. Trying to justify racism with “it’s punching up” just comes across as “I want to be racist but don’t want to be seen as a racist”.
I’d prefer I’d no one was punching anyone. Just because a person belongs to a privileged group doesn’t mean that they should be subject to any harassment.
We’re smart enough to convey our viewpoints without having to insult. It only helps with our righteous self-indignation at the expense of making inroads towards actual, positive change.
My god. They are doing you DIRTY. 8 years of experience and only making 90k euros??? My first job out of college i was making $105k. OP should be making AT LEAST $400k by now.
Reading his compensation history is making me depressed. What a waste of a career! I would take this page down and switch jobs ASAP. You could easily make 3x your current income. https://www.jvt.me/salary/
I hope you're joking about the senior 30k euro salary. I'd switch careers entirely if I was making that little. My father makes double that driving a bus part time.
If what you're saying is true, the european market is fucking abysmal.
First, only 8 applications! That’s fantastic - I likewise am starting a senior software eng role… but after 6 months of unemployed full time interviewing, and around 80 applications. FE, not BE, though.
In terms of content, I think every coding round required time/space complexity analysis, and (as an FE!) most had me doing things like building recursive binary tree checkers, solving medium Leetcode problems, etc.
> I made a point of challenging it and asking whether it was representative of the role
Yes! Love this. I had a systems design round, which are usually my time to shine, that focused exclusively on designing an app’s database. A DBA I am not, and I essentially flunked. I brought it up to their CTO on a later call, as I really didn’t think that was a fair assessment of me.
That wound up being the place that hired me :)