|
raminasi posted:There's no catch. The worst that can happen (and it usually does) is that you waste your time, but nobody's trying to trick you into anything. If it's an internal recruiter (i.e. someone informing you about positions at the company they work for), then definitely follow up if the positions look interesting. If it's an external, and they named the companies whose positions they're shilling outright, and the positions seem to match your background, and you're looking for a new job, then following up is probably worth the effort. Nice, thanks. This is good info. I'm in full-on search mode now so in my best interest to at least follow up. I took it as at least a hopeful non-shady sign that they named both the company and the position titles. Of course I'll know for sure if I get back to them and they're like "Oh well those have been filled, but we have these others you'll love..."
|
#
?
Feb 6, 2019 21:31
|
|
|
|
| # ? May 19, 2024 07:36 |
|
|
Pie Colony posted:No, I'm saying it's fine that people fail FizzBuzz. But it was an exercise literally designed for testing the very bare minimum of competence in coding. If someone passes it, okay, you just spent time establishing they are at least the very bare minimum competent at coding. Why would you not want to ask a problem that is at least closer to the minimum of competence you are looking for in the position? I don't literally ask FizzBuzz, but my interview questions typically involve a "warmup problem" that should be trivial for anyone who knows what they're doing and which then feeds into the greater part of the problem. For example, one of my questions has as a warmup "can you find the grid distance between these two points", which is just abs(a.x - b.x) + abs(a.y - b.y). Anyone who knows remotely what they're doing can knock that out in two minutes and we can move on to the rest of the problem. Some people have to derive the grid distance formula from first principles because they don't it offhand, and that takes a bit longer but they'd need to do that anyway to solve the rest of the problem. And then there's the interviewees that spend half an hour on that one part. As for why you don't start out with questions targeting your minimum competence threshold, my main reason is because I don't want to crush the interviewee's morale by presenting them with something that they're completely incapable of handling. Ideally by the end of the interview, the interviewee feels that they've solved as much of the problem as they knew about. What they don't see is my evaluation of their abilities, which e.g. includes that we only covered 20% of the problem and needed a lot of hinting to get to that much.
|
|
#
?
Feb 6, 2019 21:35
|
|
|
Pie Colony posted:No, I'm saying it's fine that people fail FizzBuzz. But it was an exercise literally designed for testing the very bare minimum of competence in coding. If someone passes it, okay, you just spent time establishing they are at least the very bare minimum competent at coding. Why would you not want to ask a problem that is at least closer to the minimum of competence you are looking for in the position? A few reasons: - Start with stupid-easy questions to get a conversation going and warm up. Something that should be a gimme helps boost confidence. - If someone completely chokes on the gimme questions, I can pivot the interview to be less painfully awkward and embarrassing. - Often, the whiteboard coding is not the goal of the interview. I'd like to focus on system design, architecture, patterns, etc. The basic coding questions are a sanity check that you can demonstrate the simplest of fundamental concepts in a concrete way. There a lot of "high level" bullshit artists out there that can't actually implement anything to save their life. Also this Doom Mathematic posted:People will stop asking FizzBuzz when people stop failing FizzBuzz. It should be a waste of everybody's time, but here we are. Conducting interviews for senior positions is a real quick way to cure your imposter syndrome
|
|
#
?
Feb 6, 2019 21:44
|
|
|
Guinness posted:
I find you get as many non fizzbuzzers in senior positions as junior ones, it's just that you don't expect that
|
|
#
?
Feb 6, 2019 21:49
|
|
|
bob dobbs is dead posted:I find you get as many non fizzbuzzers in senior positions as junior ones, it's just that you don't expect that Yeah, it's pretty jarring when someone walks through the door claiming 10+ years of experience and then can't write an if statement or for loop in their language of choice, let alone anything more complicated. We're not talking some graph traversal algorithm or dynamic programming questions, not anything even nearly like it, as much as I would like to ask questions like that. Literally problems as simple as fizzbuzz that require a single for loop or a couple of if/else statements. But it happens so often.
|
|
#
?
Feb 6, 2019 21:51
|
|
|
Getting FizzBuzz right: +0 points Getting FizzBuzz wrong: -∞ points
|
|
#
?
Feb 6, 2019 22:08
|
|
|
Pie Colony posted:as hopefully most candidates passing your HR screen do, I've seen upwards of 75% of candidates fail FizzBuzz, which is why yes, I actually do ask it. It's been a few years since I interviewed for straight developer positions, though. These days, I'd change it up a bit to something less universally recognized, but of similar difficulty.
|
|
#
?
Feb 6, 2019 22:24
|
|
|
Pie Colony posted:as hopefully most candidates passing your HR screen do I wanted to focus in on this bit too. Have you ever worked at a company small enough for "HR" to be less than one person? Or working with a contracted external recruiter who's specialty is outside of software? Getting to this point took a lot of time and effort, treating it as solved is blowing past a lot of situations.
|
|
#
?
Feb 6, 2019 22:29
|
|
|
GeorgieMordor posted:Nice, thanks. This is good info. I'm in full-on search mode now so in my best interest to at least follow up. I’ve never heard of anything like that happening. Your negative recruiter outcomes, in decreasing order of likelihood, are:
|
|
#
?
Feb 6, 2019 23:03
|
|
|
raminasi posted:but is actually surreptitiously pumping you for information about specific past jobs you held so they can sell that infuriation to someone (this is very rare but does happen)
|
|
#
?
Feb 6, 2019 23:13
|
|
|
Do you guys do any really simple code screens for candidates? Even if you let in someone that straight up cheats and looks the answers up you should be able to filter out people that can’t write, say, grep in an interview situation. I’ve never seen a code screen simpler than “write a binary tree search” but my experience there was substantially better technically than almost every other company I’ve been in that did only white(water)boarding. I’ve definitely seen a good number of candidates that can’t code for poo poo but I first ask “do you know FizzBuzz?” before I possibly insult them by asking them to do it. I ask this even for non-developer interviews - anything that touches code including making stuff talk to each other requires some vague programming experience IMO. Just filling in check boxes, yaml files, and filling in URLs without concepts or foundational knowledge to back it is what I filter out because they’re typically useless the instant something slightly has an error and they can’t troubleshoot without asking for help. Heck, even among developers Iike to ask how they troubleshoot errors reaching services (timeout v. active refusal of connection v. hostname lookup failure).
|
|
#
?
Feb 6, 2019 23:14
|
|
|
Pie Colony posted:No, I'm saying it's fine that people fail FizzBuzz. But it was an exercise literally designed for testing the very bare minimum of competence in coding. If someone passes it, okay, you just spent time establishing they are at least the very bare minimum competent at coding. Why would you not want to ask a problem that is at least closer to the minimum of competence you are looking for in the position? I got to review my own paper a while back, and I was quite proud of my fizzbuzz effort - I wrote unit tests and documented it dammit. The interviews I don't get are the ones where they sit you down and ask you to actually code something at some dudes computer. I once got sat down and asked to write something at a strange computer, with a strange IDE, with an unknown OS (ok, Windows, but I'd been at a series of Linux/OSX based places for the last half-decade). It takes me 1-2 days to setup a happy funtime development environment from scratch, what the hell is expected of me in 30 minutes? I also once got given an online multiple-choice test on my knowledge of the language using a version that dated from 2001 (this was maybe in 2015?). Apparently I got the highest score out of all the candidates, but that's not a recommendation dammit, it just means I've managed to scrape my memory for how the language worked back in the dark ages.
|
|
#
?
Feb 6, 2019 23:41
|
|
|
Pie Colony posted:No, I'm saying it's fine that people fail FizzBuzz. But it was an exercise literally designed for testing the very bare minimum of competence in coding. If someone passes it, okay, you just spent time establishing they are at least the very bare minimum competent at coding. Why would you not want to ask a problem that is at least closer to the minimum of competence you are looking for in the position? FizzBuzz is meant to be a 1 minute question. It's not like there's a real interesting discussion that would ever spring out of it other than "Great now I have to awkwardly tell this person the interview is over and to GTFO". I do not literally ask FizzBuzz in interviews, because everywhere has done homework first. If that wasn't the case, I might.
|
|
#
?
Feb 7, 2019 00:05
|
|
|
FizzBuzz take: who the gently caress cares the industry has been talking about it for like a decade now and apparently gotten nowhere job search update: Negotiation game started today. Nashville hesitated on calling me this morning, saying they had a few details to work out. It was enough info that I was able to email seattle to say "hey i have another offer coming in, can we speed this up?" I got a call a few hours later once the west coast had woken up. I'm flying there next week. I'm going to take the four hour flight out in the morning, interview, four hour flight home, then drive straight to work and act natural. loving kill me Guinness posted:Conducting interviews for senior positions is a real quick way to cure your imposter syndrome In interviews I constantly have to fight this sense of "how are these people taking me seriously, I am entirely improvising". But I've been 'entirely improvising' for eight years now so I guess that's what impostor syndrome is. I'm not hot poo poo, I know I'm not hot poo poo, I can't code fancy-pants tree traversal algorithms without a textbook and many hours. Yet I'm well on the path to getting exactly the kind of job I want for what is frankly to my hobunk-midwest-upbringing mind a completely insane amount of money. My Grandma wasn't joking when she told me the world is crazy. Careful Drums fucked around with this message at 03:18 on Feb 7, 2019 |
|
#
?
Feb 7, 2019 03:13
|
|
|
Ok fair, I've never worked at a company without technical recruiters, I'm sure some of the stuff there is different but I don't think FizzBuzz is one of them.TooMuchAbstraction posted:As for why you don't start out with questions targeting your minimum competence threshold, my main reason is because I don't want to crush the interviewee's morale by presenting them with something that they're completely incapable of handling. Ideally by the end of the interview, the interviewee feels that they've solved as much of the problem as they knew about. Okay, I definitely don't think you should be a jerk to your candidates, but my point is your bar is set at the wrong place. Why not ask them to write a hello world program just so those 75% of developers failing FizzBuzz can feel like they got something right? Guinness posted:Often, the whiteboard coding is not the goal of the interview. I'd like to focus on system design, architecture, patterns, etc. Ideally this should be in a separate interview from the coding one, but if you have even less time to ask coding questions, why ask one that gives you so little insight as to how good of a coder someone is? Mao Zedong Thot posted:FizzBuzz is meant to be a 1 minute question. It's not though. If the candidate hasn't heard of the problem before (if they have, your test is useless anyway), there's a minute or two actually understanding the problem, a couple of minutes actually writing it out by hand on a whiteboard, maybe then running through it because it would be embarrassing to get such a basic question wrong. And once you're done, that's it. You can't really expand on the problem (unless you want them to write Enterprise FizzBuzz, which I guess could be fun). You have to start over with a completely different problem to actually start seeing if the person could get the job, and you don't really have time to ask all that many different coding problems in an interview.
|
|
#
?
Feb 7, 2019 04:05
|
|
|
cynic posted:The interviews I don't get are the ones where they sit you down and ask you to actually code something at some dudes computer. I once got sat down and asked to write something at a strange computer, with a strange IDE, with an unknown OS (ok, Windows, but I'd been at a series of Linux/OSX based places for the last half-decade). It takes me 1-2 days to setup a happy funtime development environment from scratch, what the hell is expected of me in 30 minutes? That's pretty bad. In my last job search it seems like a lot more companies asked me to bring my own laptop in, with which I would join a coderpad link. I liked that a lot more than whiteboarding and wonder why all places don't do that, it was just so much faster and easier to write code. (You'd also have to have the option of lending a laptop to candidates as well I guess)
|
|
#
?
Feb 7, 2019 04:10
|
|
|
I'm honestly surprised that so many people see such low pass rate on fizzbuzz. Of course there's the first level of surprise that it's amazing that many people could be employed without being able to answer it, but I'm saying this from my own experience interviewing as both a hiring manager and technical interviewer over the years. Perhaps it's due to variance in role needs and applicant pool, but that's not my experience at all. I've got to wonder how much it's due to how screening is done at earlier stages; we don't ask fizzbuzz or something else as simple, and I can count on one hand (out of hundreds) the number of people who made it to a technical screen and performed as poorly as people are describing a majority of candidates. We aren't a big company with a ton of recruiting resources, nor do I think we have any unreasonably high technical bar for screening. Maybe because we aren't a high profile Google we aren't getting the volume of garbage applicants that some others do?
|
|
#
?
Feb 7, 2019 06:40
|
|
|
Steve French posted:I'm honestly surprised that so many people see such low pass rate on fizzbuzz. Of course there's the first level of surprise that it's amazing that many people could be employed without being able to answer it, but I'm saying this from my own experience interviewing as both a hiring manager and technical interviewer over the years. huge differences based on location, too, ime
|
|
#
?
Feb 7, 2019 06:53
|
|
|
FizzBuzz is great. Once they solve the immediate problem you start asking them how to abstract it and distribute it and serve it at scale and productionize that service and voila the sky is the limit on where you can go.
|
|
#
?
Feb 7, 2019 07:10
|
|
|
Pie Colony posted:No, I'm saying it's fine that people fail FizzBuzz. But it was an exercise literally designed for testing the very bare minimum of competence in coding. If someone passes it, okay, you just spent time establishing they are at least the very bare minimum competent at coding. Why would you not want to ask a problem that is at least closer to the minimum of competence you are looking for in the position? AbstractSingletonFizzBuzzProxyFactorySimpleBeanFactoryAwareAspectInstanceFactory
|
|
#
?
Feb 7, 2019 09:35
|
|
|
Steve French posted:Perhaps it's due to variance in role needs and applicant pool, but that's not my experience at all. I've got to wonder how much it's due to how screening is done at earlier stages; we don't ask fizzbuzz or something else as simple, and I can count on one hand (out of hundreds) the number of people who made it to a technical screen and performed as poorly as people are describing a majority of candidates. It's totally a variance in applicant pool. The difference I'm seeing (in these posts) is that everyone expressing incredulity is working at a company large enough to have internal recruiters, HR, or earlier screenings. In the times I've been privy to these discussions it was at companies small enough where we were doing all the screening ourselves, and just cutting the interviews short if they weren't able to explain a for loop. If you don't have a good recruiter relationship, or are putting out public job postings, the signal to noise ratio is super low.
|
|
#
?
Feb 7, 2019 15:12
|
|
|
vonnegutt posted:It's totally a variance in applicant pool. By "applicant pool" do you mean the people who make it to the tech screen? Or all applicants? Because it means the latter to me, but your post makes most sense if the former. Either way, my experience is at a smaller but not tiny company (~100), with an internal recruiter but that is not typically involved that early in the process: engineering managers do resume screening and initial calls before tech screens. This includes over a year of doing both of those myself, and shepherding candidates through the rest of the process (in other words: full awareness of every candidate through the pipeline), and have actually talked to very few people who would have bombed a tech screen question that simple. That's why it seems like it must the the people who are applying in the first place, or the resume screening being too permissive?
|
|
#
?
Feb 7, 2019 16:29
|
|
|
The times I got candidates that were FizzDuds they were for large companies where I was told I had a candidate to interview. It was as if they had a minimum number of candidates we had to interview whether or not we needed someone, and even my managers hadn’t talked to them until that day of. With smaller companies we’ve been forced to put up code screens as early in the process (stuff like Codility and engineers making a quick pass at the question making sure they can solve them in 30 min) but ultimately the more traditional persons seem to want to review resume first, do a quick 30 min BS phone call (why this is done now is beyond me), and then the on-site where we waste three senior engineers’ time probably. My feeling here is that sometimes management is more antsy about not hiring anyone than hiring someone under skilled for the position. I think applicant volume makes a difference as well and most really low skill workers may be dissuaded from going to a smaller company where they have to pull their weight more. I haven’t had a job in a long time where I wasn’t expected to start shipping production impacting stuff within a few days and where we fire someone within two weeks of they’re not completing tickets with very minimal guidance but for huge companies you can take weeks before you even get a login to do anything.
|
|
#
?
Feb 7, 2019 17:14
|
|
|
Steve French posted:That's why it seems like it must the the people who are applying in the first place, or the resume screening being too permissive? It's been a few years, but this was my experience at a small company in the NYC metro area, but not in NYC: We had a smaller applicant pool because NYC-based companies recruited a lot of top talent. So we were left with applicants who A) couldn't get a job at any big name NYC companies, and B) people who didn't want to commute to NYC. Our screening was done largely without HR intervention. Our screening weeded out at least 75% of the applicants. The problem we encountered was applicants who - Looked great on paper - Were able to talk intelligently about software development patterns and practices and their accomplishments during a phone screen - Failed miserably when given any sort of practical problem to solve on a whiteboard or on a laptop My conclusion is that many of the applicants had strong rote memorization skills but lacked problem-solving and software development fundamentals.
|
|
#
?
Feb 7, 2019 17:22
|
|
|
New Yorp New Yorp posted:It's been a few years, but this was my experience at a small company in the NYC metro area, but not in NYC: Do you think they were lying in bullet point 2 there? Because you can't rote-memorize your way to actual accomplishments. e: To expand a little, the two most plausible explanations for your experiences I can think of are:
raminasi fucked around with this message at 17:38 on Feb 7, 2019 |
|
#
?
Feb 7, 2019 17:29
|
|
|
raminasi posted:Do you think they were lying in bullet point 2 there? Because you can't rote-memorize your way to actual accomplishments. i unironically think #1 is about as likely as #2
|
|
#
?
Feb 7, 2019 17:45
|
|
|
raminasi posted:Do you think they were lying in bullet point 2 there? Because you can't rote-memorize your way to actual accomplishments. I think that they worked on teams that were responsible for those accomplishments. There is an entire subset of programmers who do so primarily by copy/pasting snippets from Stack Overflow and massaging it until it works. This was observed when candidates were given internet-connected laptops, an array of development environments, and told "implement <FizzBuzz-equivalent>. Feel free to search the internet, we don't write code in a bubble".
|
|
#
?
Feb 7, 2019 17:48
|
|
|
raminasi posted:Do you think they were lying in bullet point 2 there? Because you can't rote-memorize your way to actual accomplishments. I beg to differ on that point. I had to read through a six-page resume and listen through an hour-long phone interview as a candidate told us all about all the projects they worked on. I came away from the phone call suspecting that the person had mostly managed the projects and not actually developed them, but everybody else on the panel was impressed enough to give their thumbs-ups. We hired this candidate and they were terrible and gone after six months. So this person's thirty years of experience and resume bullet points translated into no actual skills at the keyboard. I wish we could have given them an in-person interview with some coding exercises (company was probably too cheap to pay for transportation) and found this out ahead of time!
|
|
#
?
Feb 7, 2019 17:53
|
|
|
New Yorp New Yorp posted:I think that they worked on teams that were responsible for those accomplishments. There is an entire subset of programmers who do so primarily by copy/pasting snippets from Stack Overflow and massaging it until it works. This was observed when candidates were given internet-connected laptops, an array of development environments, and told "implement <FizzBuzz-equivalent>. Feel free to search the internet, we don't write code in a bubble". It's this, nearly 100%. You can often tell when they often refer to "we did this" and "we did that", and if you try to pin them down to what they individually contributed or some significant problem that they solved they start to falter (or lie). There's a lot of people that barely scrape by getting carried by their team. I just interviewed a guy last week that came out of the gate talking about all the cool ML projects he worked on and slick user interfaces he created for training them. When I dug in deeper asking about how those components actually worked or were designed, it came out that "well, I didn't actually work on that part..." I struggled to get him to tell me what he actually did work on. They have enough casual familiarity of the products the team built from being adjacent to them, so they can high-level bullshit you all day long.
|
|
#
?
Feb 7, 2019 19:44
|
|
|
Guinness posted:I just interviewed a guy last week that came out of the gate talking about all the cool ML projects he worked on and slick user interfaces he created for training them. When I dug in deeper asking about how those components actually worked or were designed, it came out that "well, I didn't actually work on that part..." I struggled to get him to tell me what he actually did work on.
|
|
#
?
Feb 7, 2019 20:13
|
|
|
New Yorp New Yorp posted:I think that they worked on teams that were responsible for those accomplishments. There is an entire subset of programmers who do so primarily by copy/pasting snippets from Stack Overflow and massaging it until it works. This was observed when candidates were given internet-connected laptops, an array of development environments, and told "implement <FizzBuzz-equivalent>. Feel free to search the internet, we don't write code in a bubble". npm install --save fizz-buzz
|
|
#
?
Feb 8, 2019 00:44
|
|
|
cynic posted:npm install --save fizz-buzz I would consider this a legit answer and definitely second interview material - ask them how they reviewed the package for suitability, ask them how they'd deal with needing to change the code so it was FizzBonk instead - you'd learn a decent amount about how they deal with common real world coding scenarios, and there is a place in a lot of teams for someone who is just skilled at choosing the correct tools and plumbing them together in a sensible, maintainable manner.
|
|
#
?
Feb 8, 2019 00:51
|
|
|
I'm looking to potentially relocate to NYC from where I currently live in the near future (~5 months). I'm thinking about applying to the larger and popular tech companies, i.e. Google, Microsoft, etc. What should I expect from their technical interviews as someone who has a fair amount of experience? By the time I'll apply I'll have close to nine years of experience in roles of increasing importance ranging from entry level up to my current role as a senior software engineer and technical lead. I would say that I am very comfortable with the syntax of my language of choice and can code whatever is needed on a whiteboard and explain it, assuming I know how to solve the problem in the first place. My concern is really more about the expectation of the algorithmic knowledge. I'm (begrudgingly) grinding LeetCode and CtCI and can solve most easy/medium problems pretty quickly. Is this enough, or is there an expectation that someone in a more senior position would be able to solve the more difficult problems (k-sums, partitions, etc.) as well? I haven't done problems of this difficulty or had to even approach problems like this since I was back in an actual algorithms class in college. My hope is that the expectation for the hard problems would be lowered a bit and made up for with questions regarding design, scalability, architecture, language specifics, etc. What are the thoughts of someone who has gone through this, or knows of someone who has?
|
|
#
?
Feb 8, 2019 00:52
|
|
|
Pie Colony posted:I can't help but think this is all some elaborate troll. You guys don't actually ask FizzBuzz, do you? Or worse yet, sit there while the candidate writes out a solution? Describing the problem and having the candidate write it out might take 10 minutes, which in an hour-long interview where you also want to talk about their background and have them ask questions is a significant amount of time. And if they do end up solving it, as hopefully most candidates passing your HR screen do, it's a completely useless signal for determining whether the person is actually a good coder. There are so many better softball questions to ask, I can't help but feel anyone asking FizzBuzz shows zero value for their own time. I always ask Fizzbuzz, for these reasons:
That’s it. Nobody gets asked Fizzbuzz on site. I don’t ask hard problems on the phone screen, but very few people finish all of them, and nobody ever like scrapes by and barely solves all 4 in an hour. People either don’t finish the first 2, or they burn through all 4 in 30 minutes and then we have time to bullshit.
|
|
#
?
Feb 8, 2019 01:26
|
|
|
In my experience, they treat all incoming candidates the same regardless of whether they're supposed to be senior / junior / whatever. I did interviewing for one of the Big 5, and my co-interviewers never bothered to read anyone's resume first. It's generally a waste of time anyway, because people inflate or outright lie so much. As an interviewer, your task is just to pick a random problem from whatever area you're supposed to focus on, lead the candidate through it, and write a report. No conversations about "so, you worked on Blah, tell me more about that". The Big 5 process is still much the same as it ever was: phone screen, followed by all-day onsite back-to-back interviews consisting of 5 areas. There's a break in the middle for lunch, but they're also looking at how you socialize with whoever is designated to babysit you. All the problems are CtCI variants, typically designed in a way where there's a naive slow answer which can be evolved into a scalable / fast solution. As with all these places, the lead time from first contact to hiring is often at least 3 months, so they don't know which department you'll be working in. So they won't be asking about specific technologies; they're looking for people who can learn quickly.
|
|
#
?
Feb 8, 2019 01:28
|
|
|
New Yorp New Yorp posted:This was observed when candidates were given internet-connected laptops, an array of development environments, and told "implement <FizzBuzz-equivalent>. Feel free to search the internet, we don't write code in a bubble". Did you monitor and review the internet activity? Feels like it would be a good way to see how they go about solving the problem. Eg: Looking up standard lib documentation to see if it has a remainder operator vs just copy paste and answer from stack overflow.
|
|
#
?
Feb 8, 2019 01:54
|
|
|
RedZone posted:I'm looking to potentially relocate to NYC from where I currently live in the near future (~5 months). I'm thinking about applying to the larger and popular tech companies, i.e. Google, Microsoft, etc. What should I expect from their technical interviews as someone who has a fair amount of experience? By the time I'll apply I'll have close to nine years of experience in roles of increasing importance ranging from entry level up to my current role as a senior software engineer and technical lead. I would say that I am very comfortable with the syntax of my language of choice and can code whatever is needed on a whiteboard and explain it, assuming I know how to solve the problem in the first place. My concern is really more about the expectation of the algorithmic knowledge. Most of these companies do not lower the level of coding questions in pretty much any normal case. The people interviewing you generally will have their pet question and it's what they'll ask if you're entry or senior. The design question is the most important question in regards to leveling. On that note, if level is important to you, then you need talk to your recruiter at the start about it as many of these companies will under level you. No one cares about language specifics unless you're either being hired to design a language or the person interviewing you is an rear end in a top hat.
|
|
#
?
Feb 8, 2019 02:19
|
|
|
minato posted:In my experience, they treat all incoming candidates the same regardless of whether they're supposed to be senior / junior / whatever. I did interviewing for one of the Big 5, and my co-interviewers never bothered to read anyone's resume first. It's generally a waste of time anyway, because people inflate or outright lie so much. As an interviewer, your task is just to pick a random problem from whatever area you're supposed to focus on, lead the candidate through it, and write a report. No conversations about "so, you worked on Blah, tell me more about that". It's hilarious that this poo poo flies as a valid interviewing strategy anywhere that has people with a pulse. Guess the supply side of candidates makes up for it.
|
|
#
?
Feb 8, 2019 04:03
|
|
|
Amazon has like a 72hr SLA on telling you the results after your on-site if that helps. My process there was technical phone screen -> onsite-> offer and pretty much all the delays were due to my schedule and it being the holidays (and they had the results to me within 48 hours every time). This was for sysdev (their version of SRE) though, not software eng e; I was also interviewing for a very specific team, though
|
|
#
?
Feb 8, 2019 04:07
|
|
|
|
| # ? May 19, 2024 07:36 |
|
|
asur posted:Most of these companies do not lower the level of coding questions in pretty much any normal case. The people interviewing you generally will have their pet question and it's what they'll ask if you're entry or senior. The design question is the most important question in regards to leveling. On that note, if level is important to you, then you need talk to your recruiter at the start about it as many of these companies will under level you. I don't care about level, I'm more interested in total compensation. Looks like it's back to the drawing board (literally) to grind more algorithms then.
|
|
#
?
Feb 8, 2019 05:09
|
|