"When you're junior, coachability is what gets you hired. How quickly can we train you to be effective?
When you're medium, technical chops get you hired. Can you do useful work right now and quickly fill gaps in knowledge?
When you're senior, your experience and opinions get you hired."
Thought this was pretty good. Hard to make that mental transition over time since we all start on one end. The default behavior is to continue interviewing the same way as your career progresses.
Not necessary, interviewed for a Sr Engineer role where I clearly impressed the CTO, but didn't do that great on a stupid coding exercise. And that was not even a requirement for the job, and I told them that was not my strongpoint. I'd done my homework on the company, they had bottlenecks, which I suggested a solution for, and they were pretty blown away. But like other folks here pointed out, all companies want are folks who can crack the coding exercise, everything else is a hogwash.
I think my instinct for this and my relative lack of interview experience have been at odds. When I’m already on the job, I have no doubt that my experience and opinions show my value. I don’t even worry anymore about demonstrating value: it comes out of every action I take, and if it’s not manifest in the interaction I can either demonstrate it with outcomes or retrospectives. But that translates poorly to an interview environment where the person on the viewing side of a whiteboard might not even have the instinct to hear “this is a problem I would solve by choosing a technology that already addresses it” or even “this is something I would google because it’s not the core problem I’m solving, just a detail”.
Ive found that good interviewers / potential colleagues recognize this and I've found success in calling that sort of thing out and having a short conversation about it.
Most tech companies which have a monopoly don't care about the usefulness of a person's skills. They only care about arbitrary puzzle-solving abilities and other random abilities which have nothing to do with productivity. When applying for a job at these companies, the criteria are so arbitrary that you're basically a beggar. You just have to try to figure out what they want to hear, what they want to see then you basically have to tell them and show them exactly that; all while simultaneously using your face muscles to project a sense of enthusiasm. Just like a beggar who does backflips or plays the ukulele on a banjo; you just have to do whatever random crap will impress them enough to toss a few coins your way.
I can confirm this with recent interviewing experience. I interviewed at a top tech company and got asked puzzle coding questions I wasn't prepared for. Testing whether I can find the longest palindrome subsequence of a string optimally via a tabular or memoized dynamic programming solution in 20 minutes has practically zero ability to measure how effective I am on the job. That said, after that interview I studied the algorithm and am now slightly prepared for the next big tech company I interview with, I guess.
In contrast, at another interview I got given a take-home assignment that I almost didn't want to do because it felt like the kind of work I would do in my day job and I didn't want to do that in the evening or my time off. That task, on the other hand, probably measures infinitely better how effective I am on the job.
Testing whether I can find the longest palindrome subsequence of a string optimally via a tabular or memoized dynamic programming solution in 20 minutes has practically zero ability to measure how effective I am on the job.
Not just "practically zero" - but like, "for sure zero". As in, there is absolutely zero chance you would need to solve a problems like this (or Sudoku, etc) in the course of actual engineering work.
Generally, interview puzzles have almost zero applicability to real world work. It's similar to many colleges: the hardest part is getting in. One coding test involved a math formula I hadn't seen in 20+ years. It was simple, but if you "forgot" that, you were stuck.
You're better off giving someone a more realistic take home test and have them walk you through it during the interview. You'd get a better feel for what their "real" code looks like when they're under less pressure, how they communicate while presenting their solution, etc.
I don't think that's accurate - your example is closer to asking a programmer to take a typing test and hire them based on wpm. Both are hitting keys on a keyboard after all.
I agree that, if you're hiring someone who will primarily be managing others or, maybe, architecting some systems, without doing the actual implementation (which, btw, I think is a suboptimal way of doing things), then you shouldn't test their coding. But if you're hiring someone to code, you need to check they understand how strings, memory, dynamic programming etc works.
I don't agree, of all the jobs I had, I've never had to do anything close to a typical coding puzzle. There are much more real-world scenarios you can test people on.
I think it depends on where you are located, the culture, how competitive the current market is, etc. In the early 2010's, it seems the US had a shift towards these sorts of "puzzle" interviews. Before that it was more laid back, maybe a take home test as part of the filter...
We might be arguing besides each other. The puzzles I'm arguing for are e.g. simplified toy versions of problems solved in the existing code base. That solves a real-world problem, so it fits your requirement.
It's probably because these companies have so many good applicants, and they're big enough that a "great" junior engineer can't do much more vs a "good" one. So they're not looking for top engineers, they're filtering out bad ones and then basically choosing at random.
Unfortunately, if there are many more potential employees then you're going to be a beggar no matter what. If you're applying to companies who only get a few applicants per position, then you have leverage and the companies actually have to look for quality.
> If you're applying to companies who only get a few applicants per position, then you have leverage and the companies actually have to look for quality.
Unfortunately, a lot of smaller companies simply cargo cult on BigCo hiring, as that's all they know. I see smaller companies who have unfilled positions for 12 months or more, because they apply the same method to hiring as the company with hundreds or thousands of applicants.
Tech giants do have some broken hiring practices, but I think even they will notice a difference if a job applicant believes in their own value and in their own abilities. Nobody wants to hire someone who doesn't. It's an unattractive quality, and it suggests they won't succeed as an employee.
And interviewing at a very selective company doesn't need to negate your belief in your own value. If you could be the top applicant at some other company but you interview at a company that might not even hire you, then applying there should be a choice that you're making because the trade-off is somehow beneficial to you. Your value within the overall job market remains, and you can always walk away.
I think that changes rapidly when you interview past the mid- code monkey positions. I doubt a VP of engineering would be interviewed on anything but opinions and experience.
When that shift happens depends on the company and what the team is hiring for.
So much this. Networking(where you went to school and work) and luck(your country, your nationality, your ethnicity, your skin color, your looks, your accent, being at the right place and the right time) are worth more than your CV and side projects but this is rarely mentioned in this field as it's always touted that tech is a pure meritocracy.
One can often read sour vents on reddit on devs who lose hope, get depressed and burn out after being unemployed or stuck in dead end jobs for so long while they keep grinding leetcode and churning projects on github because the internet told them that SW development is a meritocracy and the key to success is putting enough hard work in your free time even though there's devs coasting on six figure jobs who haven't written a line on github in their life on their free time.
Nope, it's definitely no meritocracy, the tech world is just as unfair as the rest but has much better PR about it: watch Silicon Valley TV series made by the satire comedy genius Mike Judge(Office Space, Idiocracy) where billionaire tech magnate Gavin Belson would always sugarcoat his hostile business decisions with talks of buddhist spirituality, endangered animals and making the world a better place while his true motivation was only the accumulation of more fame, wealth and power.
In my most recent job hunt, I interviewed three times. In the first two loops I tried my best, but I could feel I wasn't really connecting. In my third, they asked questions about the kind of thing I had just spent six years building and I connected perfectly. It was like the sensation of hitting a homerun in the third loop, compared to foul balls (or strikes) in the first two.
In a way, this is luck. How lucky for me that the third job fit what I knew about and was comfortable talking about. It was lucky that they asked the kinds of questions that were things I was very experienced in. I was the same candidate in all three interview loops, just unlucky in the first two that what they were looking for wasn't a good fit for what I knew, and lucky in the third that it was a good fit.
That said, there's also a way in which this isn't luck. That is, I had to have some area of knowledge and skill or else I would have been flailing around forever without connecting.
Any individual interview is luck, but hard work and experience can increase the size of the target you're hoping to hit.
1. Reach out directly to key managers (found on LinkedIn), referring to the job listing. The key here is showing both initiative and an interest in working for the company beyond HR's rapidly growing pile of resumes
2. Read as much about the job and the company as possible, then use that context as a starting point to write a cover letter explaining how your skills will help them
This is patently false. The following are all ways you can stand out for a junior position:
- Attending a university that is hard to get into and has a strong CS program
- Having an impressive GPA
- Winning academic or software-related awards
- Having commendable accomplishments in software-related "extracurriculars", such as hackathons etc
- Whiteboard coding ability
I've done numerous junior interviews for FANG companies. They are extremely liberal in handing out interviews, and doing well in these interviews will guarantee a job offer. "Connections" has almost zero correlation to how you're graded in these interviews. Being unlucky can trip you up every now and then. But if you get rejected from every single FANG company, I guarantee you it's not because of luck.
Now you’re taking about FANG as if those are the only companies in existence. There are many many other places to make a living. I’ve personally never inverted a binary tree on a whiteboard and my career is doing fine.
Now you're assuming that what I said applies only to FANG companies. I've also worked and gotten job offers from many non-FANG companies, across multiple industries, and they were all using the above data points to make entry-level hires. I only brought up FANG because they are the biggest and most well-known employers.
I've already read that article and I don't see the relevance, unless you're trying to imply that I'm a prestige-chaser just because I've worked at FANG companies
In technical subjects? Cooperative Engineering is a big deal. This puts you way ahead of the pack.
Sure, a 1st term coop is useless--just like junior engineers. Most of the 3rd term coops, however, are almost on par with the first promotion from junior.
> My girlfriend got a business job at Visa last year and later found that 5000 applied for her role. She stood out because she read the job description and highlighted relevant experience. Yeah, that's the bar.
I know about different bar - not in customer service business, in software engineering. You're given a task to write a parser in 15 minutes - literally, you solve it, it mostly works - for some simple inputs at least, you don't have time to test it thoroughly. You don't pass - the bar is different.
Your experience tells that the startup is too early to think about scalability problems. They can keep things simple for a solid another iteration of the product. You explain that to them, they listen, but they are doubtful - they've heard that scaling is crucial, and even though they have like a hundred of customers, they want that - so your advice is considered wrong. You don't pass that bar.
They tell you they need somebody senior to coach and mentor a bunch of more junior engineers, somebody who'd steer the whole technical stack. In remaining minutes of the engineering interview they ask you to write Rabin-Karp implementation, or AVL balancing. You don't pass the bar if algorithms don't work first time.
Wow nice of you to assume it was a job in customer service. She’s a core part of the team scaling a multi billion dollar product to global markets and shooting to do trillions in transactions within a few years. Thankyouverymuch
And trust me the interviews for that are just as grueling as they are for engineering. Solid 7 hours of on-site followed by business case studies for homework.
But unlike engineering, you can’t skirt by as a pure code monkey who can leetcode. You have to actually know how to do the job in a real world context.
Hahaha you think technical business interviews are more challenging than se interviews. Do an interview for Jane street or two sigma :) I have all the cracking the case interview books by people who go ran mckinsey and other firms, it’a a joke
You really think they are similarly challenging in any way? I have a brother who is a VP at a big consulting firm and have first hand knowledge how the interviews are conducted and how candidates prepare for them. The level of skill that is required for a candidate in Software Enginering at a similar company (fangaa) is immense and the competition is ruthless. It’s disingenuous to say the interviews are similarly challenging in any case. If you can provide some points or thoughts on how they are similar in level of challenge I would greatly appreciate it.
I'm an SRE/SRM in the mid six-figures range, but I've had some experiences like anyone else.
I love it when they give you "homework" that they just forget about. They asked me about numerous technologies, and I went to explain them, but wasn't given a chance. The CTO poo-pooed my résumé like it was difficult to read. He must've felt threatened and so sabotage my shot. They ushered me out the door almost like throwing me out by security; so incredibly rude. I didn't get the job obviously but they later asked me to interview again but I told them to "fuck right off." No, you don't get a second chance to unprofessionally dis me, and I won't work with or for such narcissistic slave-drivers. I didn't care about my rep in this instance because they're clowns who would never amount to anything. Don't be unprofessional, even if someone else is.
A few weeks later, I got a $10k/week consulting contract for a funded startup already in acquihire talks.
Don't settle for BS or bend-over backwards for jerks because it will just get worse. It's not worth your mental health.
Homework was already the signal - you can't expect better treatment from the places that start with it.
Note: i'm not arguing about efficiency of homework - it is probably higher than that of short puzzles, yet there is such an asymmetry in it, that any minimally respectful place wouldn't do it despite the supposed higher efficiency.
I taught myself for a long time before breezing through a reputable EE/CS program. I always did both software dev and sysadmin. I worked up at numerous big-name shops and universities in multiple fields, starting at 15.5 yo. (I should've lied about my age at 15 to get an IBM Almaden dark matter paid internship job offer, but I was too honest.) I worked on a nuclear reactor simulator, industrial embedded navigation systems, biomedical informatics, HPC, app virtualization startup with a guest driver, email startup, numerous web/internet companies, and sales engineering and consulting.
The most important part is to never get lazy by always keeping skills current, never accepting something is impossible and roll up sleeves to dig deep. Do what other people won't, i.e., confirm/refute root causes with evidence rather than shrugging.
When you're medium, technical chops get you hired. Can you do useful work right now and quickly fill gaps in knowledge?
When you're senior, your experience and opinions get you hired."
Thought this was pretty good. Hard to make that mental transition over time since we all start on one end. The default behavior is to continue interviewing the same way as your career progresses.