4 ms·

I'm in my 40s in the SF Bay Area and recently landed a new software development job. The process took several months. My initial interviews were disastrous; i

I'm in my 40s in the SF Bay Area and recently landed a new software development job. The process took several months. My initial interviews were disastrous; it had been many years since my last job search and I didn't know I wasn't prepared for the "leetcode era". Drilling on "leetcode medium" problems with a time limit got me to the point where I was at least in the game that's being played nowadays. It wasn't pretty, but eventually I got around to progressing and getting an offer instead of getting "nope'd" at the early stages. The job-interview repertoire has definitely changed in the last 15 years though, and it takes some work to get conversant with it.

scarface74 6y ago
Pro tip: get out of SV....
WrtCdEvrydy 6y ago
Yeah, SF is probably the problem here... get out to a cheaper state... come down to florida and sling some code for insurance companies... it will be boring but alcohol exists.
xzel 6y ago
The leetcode grind is very real these days. My advice for people is pick a language you want to get more familiar with but have a decent understanding of already. It will help you learn some of the standard but not always used libraries. For example I’m doing some in Python now and had never used the defaultdict class, even though I’ve been using python for 10+ years.
pc86 6y ago
No appreciable percentage of employers outside of SV, and maybe NYC, give a shit about LeetCode or probably even know what it is. SV is an outlier among outliers in almost every respect, even among other large metro areas with big tech industries like NYC, Chicago, or Austin. To the point where advice should always clarify whether it pertains to SV or non-SV, because it's usually one or the other. Edit: typo
Osiris 6y ago
I'm 40 and a developer for 15 years and didn't make it past Amazon's initial code assessment. One of the problems was a floodfill algorithm, which I've never used before. Couldn't quite figure it out on my own, but found the answer in Google in about 5 minutes, which is what I would do in real life faced with this problem. I don't understand the purpose of asking people to memorize a bunch of algorithms they will probably never use in the job and could research if needed. I don't see it as any reasonable evaluation of my engineering skill.
- grogenaut 6y ago
  While I will say that flood fill is probably too hard for a screener question, I have used it multiple times at work. Sometimes incorrectly, but knowing it helped me realize it was incorrect. It is true that I use a hard algorithm maybe 8 times a year. But I need my coworkers to be able to understand them when we do. So that's one part of it. Another major part is having you go into detail about complexity and tradeoffs. Believe it or not most of my co-workers can derrive these things on the fly, not memorized. Others require a little think. The third is algorithms boil down to simple interviews where only a few things can go meta wrong. There are other types of question but they have a lot more failure modes and are even harder to train people to give.
  - Osiris 6y ago
    If the questions are relevant to the job then I think that's fine. In this case, the code assessment is provided even prior to being able to apply to a specific position. From what I gathered, this assessment applies to everything from a team lead/management position to a front-end developer to a firmware engineer. I understand that for a big company they need something standardized to process a large number of candidates.
- nickff 6y ago
  Those tests aren't really about engineering skill. The interviewer is checking to see how much you want the position, how hard of a worker you are, and how smart you are. If you really want the position, you will put a lot of effort into researching what the interview will entail. If you're a hard worker, you will intensively study for the interview. If you're smart, you'll be able to apply the material you studied to the problem, and you'll probably realize the game you're playing. None of these things is about 'engineering skill', which is much more difficult to discover, and only really valuable if the person is a smart, hard worker, who sticks around. *edit: I am not saying that I like this style of interview, and when I interview job candidates, I never engage in this type of 'test'

scarface74 6y ago

Pro tip: get out of SV....

WrtCdEvrydy 6y ago

Yeah, SF is probably the problem here... get out to a cheaper state... come down to florida and sling some code for insurance companies... it will be boring but alcohol exists.

xzel 6y ago

The leetcode grind is very real these days. My advice for people is pick a language you want to get more familiar with but have a decent understanding of already. It will help you learn some of the standard but not always used libraries. For example I’m doing some in Python now and had never used the defaultdict class, even though I’ve been using python for 10+ years.

pc86 6y ago

No appreciable percentage of employers outside of SV, and maybe NYC, give a shit about LeetCode or probably even know what it is. SV is an outlier among outliers in almost every respect, even among other large metro areas with big tech industries like NYC, Chicago, or Austin. To the point where advice should always clarify whether it pertains to SV or non-SV, because it's usually one or the other. Edit: typo

Osiris 6y ago

I'm 40 and a developer for 15 years and didn't make it past Amazon's initial code assessment. One of the problems was a floodfill algorithm, which I've never used before. Couldn't quite figure it out on my own, but found the answer in Google in about 5 minutes, which is what I would do in real life faced with this problem. I don't understand the purpose of asking people to memorize a bunch of algorithms they will probably never use in the job and could research if needed. I don't see it as any reasonable evaluation of my engineering skill.

grogenaut 6y ago
While I will say that flood fill is probably too hard for a screener question, I have used it multiple times at work. Sometimes incorrectly, but knowing it helped me realize it was incorrect. It is true that I use a hard algorithm maybe 8 times a year. But I need my coworkers to be able to understand them when we do. So that's one part of it. Another major part is having you go into detail about complexity and tradeoffs. Believe it or not most of my co-workers can derrive these things on the fly, not memorized. Others require a little think. The third is algorithms boil down to simple interviews where only a few things can go meta wrong. There are other types of question but they have a lot more failure modes and are even harder to train people to give.
- Osiris 6y ago
  If the questions are relevant to the job then I think that's fine. In this case, the code assessment is provided even prior to being able to apply to a specific position. From what I gathered, this assessment applies to everything from a team lead/management position to a front-end developer to a firmware engineer. I understand that for a big company they need something standardized to process a large number of candidates.
nickff 6y ago
Those tests aren't really about engineering skill. The interviewer is checking to see how much you want the position, how hard of a worker you are, and how smart you are. If you really want the position, you will put a lot of effort into researching what the interview will entail. If you're a hard worker, you will intensively study for the interview. If you're smart, you'll be able to apply the material you studied to the problem, and you'll probably realize the game you're playing. None of these things is about 'engineering skill', which is much more difficult to discover, and only really valuable if the person is a smart, hard worker, who sticks around. *edit: I am not saying that I like this style of interview, and when I interview job candidates, I never engage in this type of 'test'