6 ms·
All I do at work is fix bugs by changing a few lines of code and glue together API's to send data from A to B. I don't regularly search BST's using DFS/BFS algo
by csnewb 9y ago
All I do at work is fix bugs by changing a few lines of code and glue together API's to send data from A to B. I don't regularly search BST's using DFS/BFS algorithms or find the kth shortest string in a merged unsorted linked list or some shit like that. Preparing for these technical interviews is like a part-time job after my full-time job.
- andrewprock 9y agoFor the most part these interviews are not meant to evaluate the quality of a candidate, rather they are meant to evaluate candidate interest.
- csnewb 9y agoI'm EXTREMELY interested in finding a new job at literally any company outside of my own. Maybe interviewers don't think I'm interested enough when I can't crank out a 100% correct and optimized algorithm in 15 minutes? /s
- busterarm 9y agoAre you in NY, perhaps? I have a couple of leads for you if so.
- rainbow_12 9y agoI am in NY, can you send me your contact info?
- gknoy 9y agoYou'll need to put your contact info in your HN profile's About field, as the email field is hidden to normal users.
- aphextron 9y ago>evaluate candidate interest. As well as screening for social class/culture/values fit. FAANG companies don't want nonconformist people outside of the kool-aid bubble regardless of their abilities.
- ageek123 9y agoHow does being able to implement standard algorithms and solve programming problems screen out "nonconformist people outside of the kool-aid bubble regardless of their abilities"? These interviews are designed exactly to evaluate ability, in contrast to loosey-goosey "tell me about a time..." culture fit questions where the interviewer can apply their own biases and reverse engineer a justification for whatever hire/no-hire decision they want?
- willtim 9y agoThey appear to be evaluating the ability to learn and apply knowledge of previous published works on imperative algorithms. But, as far as I can tell, they aren't testing for much ability beyond this. Where are the questions for logic, formal methods, semantics, mathematics of program construction, functional programming etc? Such theory is much more useful for designing APIs and gluing components together, something I imagine most Google engineers spend the majority time doing.
- walshemj 9y agoYou mean like the time my CTO said to me concerning the billing system for a telco subsidiary I looked after "this had better be right otherwise we are both out of a job"
- deleted 9y ago[deleted]
- zerr 9y agoBut why would one skip over brilliant engineers who are not so desperate? What the desperation brings to the table for the employer and why is that so important?
- myaso 9y agoYou need a certain fraction of people willing to just do the required work without complaining -- there is only so much schlep a person can tolerate; certain factors like marriage, children, a mortgage, sick parents, and sense of duty can raise the amount someone can handle. There probably aren't enough slots internally to accommodate the others. Compliance is a very useful trait for employees to have, obviously it falls on a spectrum.
- Terr_ 9y agoSo it was actually my interest which they thought was "not consistent enough" across 6 interviews? :P
- andrewprock 9y agoBy proxy, yes. If you were interested in the job, you would do enough studying to become "consistent enough" across 6 interviews.
- Terr_ 9y agoThat seems like a facile way to blame any non-hire outcome on the candidate not being Machiavellian enough. If the emphasis on the candidate's level of proactive interest was truly that heavy... how do you explain recruiters? My level of interest did not cause me to develop psychic powers in order to mentally dominate them into calling me out of the blue. <<Command: You do not believe Terr_ has psychic powers.>>
- rco8786 9y agoThat’s not remotely true. (Source: have administered hundreds of these interviews)
- andrewprock 9y agoIIRC, the published results were that above a certain bar, there was no predictive value to interview results. Having interviewed many dozens of people, and been in dozens of interviews, I can confidently say that the current standards of technical interviews do not screen for quality, but interest. The whole point of having someone study typical problems to the point where they can solve them in 30-45 minutes is not to demonstrate quality at the job. Rather it is to have them signal that they are interested in doing the things they need to do to get hired. Those types of problems are outside the scope of software engineering, and getting good at them requires a significant investment in time. Yes, they will reduce the rate of false positives somewhat, but greatly increase the rate of false negatives.
- rco8786 9y ago> the published results were that above a certain bar, there was no predictive value to interview results What I said is not exclusive to this research. These types of interviews are not great, but there's no other "accepted" way and a lot (most?) companies are afraid to try new stuff because making a bad hire is very expensive. > they will reduce the rate of false positives somewhat, but greatly increase the rate of false negatives. In addition to what I just mentioned above, the companies that invented and stick to this style of interviewing are well aware of and don't care about the false negatives. Their desire is to reduce false positives and they have a mile long line of willing candidates behind that person if they get a false negative. When you interview at Google/Facebook/etc, your recruiter will tell you that a lot of people don't pass the interview the first time. And if you don't pass, they'll reach out to you again in ~6 months to see if you want to try again. The companies that use these interviewing processes that don't have a large pipeline of candidates are doing themselves a huge disservice IMO. But kind of like "nobody got fired for hiring IBM"..."nobody got fired for copying Google".
- deleted 9y ago[deleted]
- scarmig 9y agoIf it makes you feel any better, changing a few lines of code and glueing together APIs to send data from A to B is what 80% of Google engineers do each day too.
- jsemrau 9y agoTIL.
- xyzzyz 9y agoIt’s called “proto to proto” in google slang, and yes, googlers definitely complain that their jobs consist mostly of proto to proto work.
- oblio 9y ago"Protocol to protocol", I guess?
- bhaavan 9y agoProtobuf to Protobuf.
- dekhn 9y agoprotocol buffer to protocol buffer. PBs are a foundational google tech, going back to pre-2000, that are used to store nearly all structured data at google. So, most applications are PB transformers (user request comes in, the user's proto is retrieved, the fields are accessed to produce a new record that is sent as a request to a backend, etc).
- anonytrary 9y agoSounds lame.
- oblio 9y agoSounds like real life. For every idea there's an awful lot of trench digging to do...
- debatem1 9y agoFWIW, I worked there and used this stuff. I think my interview was a good but incomplete window into what I would need to know to do the job.
- Maro 9y agoThat's exactly what I did for a FB interview 2 yrs ago, I essentially had a +4 hour session every day after work to practice programming questions. I thought it was fun, a nice break from the everyday "fix code and do 1:1s".
- dajohnson89 9y agohow did that work out?
- somethingsimple 9y agoI understand what you're saying and I generally agree that algorithmic/coding interviews are broken. But you know what? Sometimes you need the fancy stuff. I once stumbled upon a problem at work that, after some thinking, I realized could be modeled as a graph problem and solved by performing a topological sort. It was a good and elegant solution to the problem. But what if it hadn't landed on my plate, and instead on someone who didn't know a thing about graphs? The problem might not have been solved (which would mean great pain for our customers, since it was on a feature that customers directly interfaced with), or worse, someone else might have turned up with a horribly messy, spaghetti-like solution. So I think companies should actually hire people who know their CS fundamentals, even if 80% of the time they'll be doing trivial work that someone less qualified could do. What matters though is having people that are ready for the hairy stuff when it comes up.
- tabeth 9y agoWhat was the problem?
- deleted 9y ago[deleted]
- fho 9y agoI bet on jobs with dependencies. That comes up alot.
- kiliantics 9y agoMost real world problems don't have elegant solutions though. There might be an elegant concept behind the solution but usually the end implementation gets pretty dirty. The dirty stuff ends up being most of the work and is what counts for the most in the end product. Companies should be hiring on the ability to take care of the dirty tweaking and tuning. But this experience is something that can only be seen in past projects and that's too much work for a hiring manger to be bothered with.
- zgljosh 9y agoI actually had the same experience as you. Finding a solution using topological sort. I agree that familiarity with basic data structure and algorithm is a must for engineer. But for interviews that solely depending on fancy coding algorithms that must be done within 15 minutes is insane. Combining grasping of algorithm with problem solving with real project experiences and willingness to learn new tech would be more effective in interview.
- newusertoday 9y agowhile i am not fan of algorithmic interviews every six months or so i come across text book algorithmic problems in my routine work which is nothing fancy just maintaining legacy code.Recently there was a library given by one of the big four's which had to be integrated into our system. It was working fine on pc but the moment it was brought into embedded system it started corrupting the stack, turned out that it was constructing the tree via recursive call which was blowing up the stack. We had to convert it from DFS to BFS to get it working. So i would certainly not discount value of having good knowledge of algorithms.
- dekhn 9y agoyou know that you can make any stack-recursive routines use their own stack (dynamically allocated), right? I would have started there...
- newusertoday 9y agoyes, i do :) that still did not solved the issue as before the intermediate stack could unwind it was already going out of the memory budget.
- nsnick 9y agoYou can also do DFS without using the stack.