Why are interviews such bullshit?
>le lol why is le manhole cover round :DDDDD
Well, it says a lot about a programmer if he can't reverse a binary tree when he's developing software. I mean he probably didn't even take the effort to attempt reversing the tree, and while I'm not a programmer by any means, and I've no idea how to do it, I imagine it involves traversing the tree and swapping leaf nodes, in which case, if he knew how to program, he should be able to come up with pseudocode to achieve this even if he's never done it before.
I've interviewed many people for software development positions.
I just ask them to demonstrate some projects they've done, and talk about some of the frameworks they or we use.
When I'm unsure I ask them to submit some code for review.
Am I doing it wrong?
I'm not a professional HR person, I'm just a fellow developer.
"Professiona HR" people are the worst. They really shouldn't have any say in the hiring process at all, because they don't know what the hell anyone around them is talking about. All they know is legal shit and wonky "personality metrics" and other bullshit like that. Only the former justifies there even being such a position.
Yeah that's pretty cool. If the idea is to figure out if the candidate in question can actually code then you can usually figure it out just by asking them casual questions, such as "Which is faster, while(1) or while(2)?"
I just did a bunch of google (and other company) interviews. They haven't really been as retarded as "why are manhole covers round" for a long time.
At Square/UBER/Microsoft/Google/watever they are all designed by the individual engineer that interviews you, not some retarded idealist.
In a 4-6 interview day there are typically only 2 or 3 interviews that test algorithms skill. Other interviews ask scalability/previous projects and sometimes personal bullshit.
Interviews are hard, because picking good engineers is really hard, but really that guy is just salty.
Same here, I've followed this approach for building the webdev and mobile dev teams at my office.
However, we're very picky with which resumes we follow up on. We are in an geographic area with lots of government/gov contract workers that will satisfy some of the HR buzzword filters, but have often spent their careers 10-15 years behind what the private sector is using to develop software. It's a minefield, since some of those folks are just looking for better pay, while others legitimately want to change career paths to avoid becoming dinosaurs
That has to be the easiest interview question anyone's been asked for a position at Google. All the other questions I've seen have been way more intricate. The interviewer probably gave him a softball because he assumed he knew what he was doing. Imagine his surprise when this retard can't even solve such a basic problem.
>turn up for job interview
>cant complete required tests
>cant demonstrate knowledge for the position
>WOW FUCK YOU, I CAN DO , Y AND Z THO U FUCKING ASSHOLES!!!
Seriously it's like being butthurt over not getting a bakery job because you cant make bread then complaining on twatter like "yeah well I can make good instant noodles, what a shitlord employer!!!"
>tfw asked to do FizzBuzz for an interview
>tfw <40 char one line Ruby script
>applied for Java dev.
>said they didnt specify the language
>they lost their cool
>hired the guy who wrote pseudocode
Congrats, you're a normal decent person.
Actual HR is the scum of the earth. It doesn't help that they're much less likely to know what it is the people with real jobs at the company actually do. They're completely high on their own supply.
>They're round because pipes are round
It's a fucking manhole and it's only purpose is to server as an access point for maintenance.
The manhole doesn't have to be round.
While the manhole cover does in order to prevent some dumb negro from throwing it inside.
>why is le manhole cover round
Maybe in nigger countries.
And the manhole is round because a square one would crack much more easily with time and much smaller forces.
It's not difficult to build a square manhole with a cover than can't fall in.
>why are manholes round
because the creator didn't have OCD and didn't give a shit about people with OCD
>tfw whipping out my ultimate optimized haskell fizzbuzz that I've practiced for 6 months and the dumb HR bitch doesn't understand it because it's not a copy paste of the Java code on her papers
I'm pretty sure you never did a whiteboard test before: it's like asking some nerdy boy to pee in front of you, the poor guy will try and try but nothing, not even a single drop of urine, will pass through.
Either you know someone who will get you in, or you'll have to be super smart to even make it past the phone screening.
Pretty much what its like for anyone not white, for every other place you apply for. Except google is full of indians, so the script has been flipped on white boys. Hence you seeing white boys crying on tweeter about, bawwww you didn't like me.
How's the butthurt from getting rejected, anon? You should put some icyhot on that, you wouldn't want to be sore while you're sitting on your ass all day crying.
>>le lol why is le manhole cover round :DDDDD
What did they do when people pointed out that their question made no sense?
>you're too dumb to even finish 1
I've heard some horrible things about working at big tech companies. You're practically under the microscope from day 1. If you're Key Performance Indicators (KPI) fall for a quarter you're put on probation, and fired if your KPI does not improve by end of the next quarter.
If you want to wear the google/apple/yahoo/facebook badge it comes at a cost. In reality you can make just about the same, if not more (google can undercut you cause 'lol we're google and can get 4 indians on H1B visa for the price of you'), working in other business sectors.
As a majority partner in a startup, I'll always vote to hire the former.
Optimization >>>>> readability. We aren't a fucking kindergarten. It's one thing if comments and macros and multiple lines allow you to read something fast, it's another if you just plain can't read a program if it has none of those things.
It's always the ones who graduate from college with no portfolio or experience to speak of who do retarded shit like write psuedocode and expect to get hired, too.
>It's not difficult to build a square manhole with a cover than can't fall in.
It's not important that you solve it perfectly in an interview, it's a test in which you show your thinking and explaining capabilities.
The guy in OP's pic probably just acted high and mighty and didn't even try to solve it.
This. Tired of retards not being able to understand simple shit like anonymous functions. These same idiots later compose 400-line functions and think it's the same thing as a clever optimization.
Organizing code and writing the function bodies themselves almost seem like two different jobs.
99% of programmers are dumb as shit and should be organizing code and never writing the implementation of a function.,
Seriously, I thought about for three seconds and came up with a cheap, easy to implement and reliable solution. I'm sure some engineer can come up with something even cheaper and easier.
>Optimization >>>>> readability
that depends entirely on your needs. If you're implementing some wacky shit like a 3d shader on an arduino, then yeah, optimization is going to be king. But for most cases where performance isn't utterly critical (which is a lot of things), readability should be the most important. Besides, writing fizzbuzz on one line, and writing it in 12 lines are probably not going to have any performance difference. Fizzbuzz is fizzbuzz. There's only so many ways you can do it without getting redundant.
>It's always the ones who graduate from college with no portfolio or experience to speak of who do retarded shit like write psuedocode and expect to get hired, too.
>pseudocode is retarded
Oh I get it, you have no idea what you're talking about. ya got me.
Nice answer, but the actual reason is that they connect to round access areas of similar size. It's rare to find a manhole that opens into a rectangular opening.
The access areas are round so that their are no flat areas that would bulge from the pressure load pressing on outside diameter. Further round shapes have the highest volume for least amount of surface area.
But keep telling retarded HR people that it's so you can't drop it.
The unfortunate reality is that anyone who can make sense of undocumented/uncommeted code are generally not cheap, and those who can't are.
It will literally take you no more than a minute to add a comment to that gee-wiz one-liner code snippet, and the company can then hire 2-3 junior 'programmers' to help maintain that code for what they pay you.
I understand the reasoning "optimization > readablity" but from an operational perspective its not always the wises decision.
I'm not looking for babby's first coder who's only code to his name are a few pulls to a shitty Byond space game on Github and 2 college projects. Any coder worth his salt will prioritize performance first, because it's about the principles of coding. It doesn't matter that "modern computers are powerful enough for it to not matter" if you aren't going to apply yourself and write the best code if only for the fucking interview process, you don't need to be payed $150k and can fuck off to someplace more your speed. I have no time for codemonkeys who never learned to read a language like an actual language and not just a slightly abstract chart.
Any fucking 12 year old who watched a youtube video on BASIC can write psuedocode, it tells me absolutely nothing about your skillset and just shows you marginally know how to solve something in an abstract way.
Which is great and all, but writing it in the actual language shows not only that you can solve it in an abstract way, but that you actually know how optimize your code. You and the rest of the failures can sit at the bottom of the foodchain and wonder why you never got that well paying job while you hack away your life writing sloppy "readable" code that is designed so a fucking braindead "lol I'm such a GEEK" webdev can understand it.
You don't lose any optimization gains if you use more than one line, since everything is compiled. However, in terms of readability it show's a lot how your code will look like if you made unreadable fizzbuzz code.
And you still don't realize that clearly and easily showing how to solve a problem using pseudo code or whatever is much more important than language specific knowledge which you can learn in minutes.
Maybe you'll realize than team compatibility is more important than difficult looking solutions when your startup will fail.
One line of code does not mean that it's more optimized.
We crossed the Valley of Death 8 years ago, buddy. Riding on some contracts and maintaining a small staff is the key to success.
And anonymous shitposting about your fluke success, because what good is blind luck if you can't brag about it?
I believe in a small staff of highly skilled people over a large staff of poorly skilled people. Also helps if you pick up guys who have impressive portfolios but no college degree, because most big businesses won't touch them and most firms will stick them doing some shit webdev job.
After you get your team together it's important to set the right environment. You want deadlines, but let them be unproductive until they need to be productive. These are artists and they know it, you have to let them run wild and overpay them to hell and back. But when you do, they'll make you very happy and very rich.
That's enough shitposting for one day, I have some shit to look over before I'm out for the day. Feels good to be the boss and leave whenever you want.
You can write a great clever optimized algorithm in pseudo-code.
Nobody gives a shit about language-specific micro-optimizations you use while implementing a dumb algorithm with awful runtime.
I bet you're the kind of fag who'd use a xor-swap in an interview.
It was more meant like you shouldn't call your company a startup after 10 years, since a startup usually implies that you probably didn't even reach break even and work too much for no money because you may go bust tomorrow.
[spoiler]I lied I never left but for real this is the last post[/spoiler]
If you ever run a startup, prepare to work all days of the week. My cofounder is busier than I am (he handles most of the financial shit) and when we first started 10 years ago we were losing a lot of sleep because we were working so long.
This. I'm in the game to make as much money as possible and then retire without ever having to be a wageslave in my life.
I don't care about a legacy, I just want to be able to build a race track in my back yard and work on my nice cars.
You'd be surprised how much money you can make if you keep yourself a small, highly skilled firm. Probably not possible in a place where CoL is super high like San Fran, though.
> Optimization >>>>> readability
This right here is the reason 90% of startups fail, they put their short-term blinders on. Should you ever make it to the point where BigCorp X comes along to buy you up, this will be one of the things they assess before they make a decision.
Which one of the these things do you think is higher risk to a large firm: Well-written code that is too incomprehensibly dense to make changes to, or well-documented code that needs incremental improvements?
After 8 years I would consider it a small business, not a start-up.
The best artists didn't wank around on reddit/twitter until inspiration hit them. Think about Ernest Hemingway, who would wake-up at 5 in the morning while no one was up, just so he could get his work done. Or Michaelangelo, who took years to create the Sistine Chapel. Great art is about discipline, hard work, and working through the low-points until you get it right - not undisciplined "I'll get to it when the inspiration hits me".
If you're building small portraits for gift shops its cool, otherwise you're gonna need to buckle down and get shit done.
the last job i had (i since quit [but not because it was bad]) i got partially because of the way they did assessment. basic aptitude test + you had to give a 10-minute presentation on a technical project you'd worked on (of your choosing), followed by a short Q&A. the Q&A had were technical questions but they were in a more meaningful context.
idk why so many companies think solving abstract textbook problems makes any sense for interviews. you're not hiring someone to solve whiteboard problems. if you really have to do that shit, have an aptitude test, it's a waste of a fucking interview that you could be using to find out something more meaningful
The only acceptable answer when someone tells you to invert a binary tree is "Why?"
Being a code monkey incapable of thought doesn't have much use unless you work at a place with the same level as India
Yes. I've heard of a genius interview trick that might interest you though. Ask a very simple question that has to do with your development environment. Say you're looking for a sys dev and your derpartment uses Linux; "if you open a xterm window and type "ls", what happens?"
He's going to say something like "it lists the contents of the current directory". Then you ask him "yeah but what h a p p e n s".
"Oh, hum, the shell attempts to interpret it, notices its not syntax, checks the $PATH variable for where to find executables, runs the ls program in the first folder it can be found from the left" yadda yadda.
Then you egg him on and milk him for what he's worth. It's a nice opportunity to find out what he knows, how he can express his knowledge, whether or not he makes bullshit assertions (and if so, whether or not he acknowledges he might be wrong) and whatever else you can think to look for.
Doesn't matter what the question is just as long as it's pertinent.
Not him, but high-level programmers are basically inhumanly fast at coding.
for referance, I'd consider Terry Davis a 6 on the programmer powerlevel hierarchy. Legacy Carmack is about a 8, Neo-Carmack is a 5.
You're probably one of the few people who saw Whiplash and thought the bald teacher cunt was a swell guy. People like you kill art wherever they go. That's why jazz is dead and it's also why classic literature is dead.
You need to stop worshipping obsession. It can be a valuable asset and it can easily be a polarizing, poisonous character flaw. That, and "obsession" and "hard work" are not freely interchangeable terms.
In addition to that, your constant need to validate your worth through your stale ready-made tastes, in order to compensate for your inability to produce anything authentic or worth appreciating, inspires nothing but pity. "Great art" will continue to spring in every location where you aren't, as it always has.
/g/, I'm scared
has someone told /b/ about that?
>All trademarks and copyrights on this page are owned by their respective parties. Images uploaded are the responsibility of the Poster. Comments are owned by the Poster.
you are free to sue them
The only shape that can not be manipulated to be smaller down the hole, ie. You can not drop the cover down the hole..every other shape in some form or fashion that can happen too
He did do it, using a standard algorithm alongside a statement that you would use whatever library was in your project that was most tested and appropriate for it rather than roll your own every time.
They rejected him because his algorithm wasn't up to Google's standards of optimization. They then apologized and tried to bring him back after he went elsewhere instead.
>new guy has to take over
>spends majority of his time deciphering what the fuck is going on
you aren't a majority partner in fucking anything, why lie on the internet?
>drills make round holes
Only if you use a round drill. At any rate the manhole doesn't have to even be drilled. If you build up over the manhole it can be literally any shape (often square or rectangular)
If shows your textbook knowledge of algorithms and data structures. Which depending on the type of work you do might be useful or not.
It's definitely not a good test of capability or problem solving skills.
It's not interviewers - its the concept of interviews themselves.
Hiring a new employee is a huge risk for a business because the employee has to be trained, paid and accounted for, for at least a couple of months minimum.
There is absolutely no way in a 30 minute interview to gauge the ability of a candidate, no way in an exam to test the ability or knowledge of a knowledge worker and no way in an assessment center to test the value of a team member.
Literally the only way to ascertain whether or not someone is going to be competent is to take them on a temp contract for a few months. Companies default to interviews because there is no other way.
I work for a mid sized company that recently decided to formalize it's hiring procedure. They now have a test and an assessment center. I know that I I'd have done the test and assessment center I would not have the job I have now. The strange thing is that I'm actually incredibly good at my job. The software product that I architect is a valuable asset and the decisions that I've made have increased that value.
I pointer out that despite being a 'rockstar programmer' within the company, I'd have no chance of passing their interview test and they just shrugged.
he multiplies the string, string * 0 gives "" which evaluates to false so the expression after or is evaluated, if it's * 1, it's just the string which evaluates to true, so the expression after or will be ignored
While (1) compiles to While (true), provided the language you're working with can cast 1 && 0 to true && false.
While (2) is impossible as 2 would correspond to a third boolean state.
>I pointer out that despite being a 'rockstar programmer' within the company, I'd have no chance of passing their interview test and they just shrugged.
Sad, but don't have any other choice do they? With hundreds of applicants, you can't just keep everyone on as temp and expect they will turn out to be the candidate they were looking for. Otherwise you do it all over again, which takes a lot of time.
A similar process exists, which involves hiring people not as temps, but as interns, and then choosing the one who performed the best.
But only freshers apply for internships so that way cant be used to hire experienced people.
>At Square/UBER/Microsoft/Google/watever they are all designed by the individual engineer that interviews you
I've done day long interviews with Uber and Facebook and this just isn't true for them. They literally pick from the same pool of stock standard algorithm interview questions you find online. I've never had a question I that I hadn't seen in preparation, Facebook especially give you so much preparation material it's almost retarded to complain the questions are unfair.
Knowing the answer beforehand is sometimes a hindrance though, I've told interviewers before I already knew the optimal solution and had one of the interviewers at Facebook tell me they often have people who clearly are just typing a solution they know line by line beforehand and they'll just complicate the problem grill you harder on analysis.
Generally it's all pretty fair, Unfortunately I just get huge anxiety and despite normally being able to solve what they ask my brain refuses to work.
I just wish that companies understood that good Software Engineering almost entirely consists of solving non software related problems such as communication and perspective.
If I asked a second year CS student how to reverse a binary tree they would probably try to remember a lecture they had the previous year in CS101. If I asked a senior software engineer the only acceptable answer is 'I'll look that up on google' because a very experienced programmer is only very experienced at finding and processing relevant technical information, actually remembering equations is immaterial.
Companies that want 'the best' candidates think they have to go to 'the best institutions' and ask 'the most difficult questions'. That's fine if you're hiring lecturers for a research based university department but poisonous if you're hiring for a business.
Lets put it this way, if you can't look at the sampe inputs and outputs of a binary tree inversion algorithm and write your own then you have no business going anywhere near a programming job
I like it. I had one interviewer ask me the difference between an interface and an abstract class. Mind you, this was about 2 years after I had taken a Java course. This doesnt excuse my lack of knowledge, but the way you go about it is fine. Asking people to memorize computing terms and regurgitate them is *NOT* critical thinking, which is what programming is all about.
memorizing rote bullshit does not make you a good programmer. 99% of the time, when I had an issue in my code, I would google it and go to stack overflow. And so would my coworkers!
My last interviewer askedme me that question, along with a bunch of other things like overloading vs overriding, the principles of oop etc.
I literally read a page on the internet a day before and kinda bsed my way through. I've never really implemented interfaces, abstract classes and used the paradigms intentionally lmao, I just know what they are. Got the job offer but turned it down anyways.
>apply for Java dev
>write some unreadable code in Ruby
Who could've see that coming?
>want to install sshpass
>brew install sshpass
>'We don't believe in this software so we removed it from our repository'
That really made me upset, who are they to tell me what software I can or can not use?
No, it's a little more like getting an interview at a bakery and flunking said interview because they expected you to know how to build a hand-crank grain mill.
Interview quests should be position-appropriate. A baker should know how to bake bread. A programmer should know how to program for his target platform. If that platform happens to be vanilla C for drivers/kernels/embedded systems, sure, some of those tech interview questions make sense. For anybody programming anything higher level (and most are), they're nearly pointless.
One of the reasons to go for (somewhat smaller) defense companies if you are technically capable and like to work on legacy stuff. At least no we have 4 curry niggers to replace you mentality.
Yep. Only actual programming experience makes a good programmer. While theoryfags are sitting in the corner trapped up in shit that probably won't make any difference and producing convoluted code, seasoned self-taughts have developed a gut feel for what does and doesn't work well ages ago and is pumping out functional, readable software.
Of course, the real god tier is those who have experience in addition to CS book shit, because they know where to apply CS theory and where to just trust their instinct, unlike theoryfags who will try their hardest to cram everything into little overengineered boxes.
A square manhole cover would also mean a square manhole, because you can't just make a square cover for a circular hole. The reason for that is because the only way to make the square cover fit the round hole is to make the square much larger than the hole, where the corners of the square overlap the hole. The overlapping bits would cause parts of the manhole cover to raise up when the opposite corner is pushed on by a vehicle or something similar. This would contribute to wear and tear and also possibly cause the manhole cover to be lifted off the manhole, exposing the hole to everything above. These issues wouldn't exist if you just made the square manhole cover fit a square manhole like a normal manhole in the first place, and I assure you a square manhole cover can fall into its square manhole.
There are multiple reasons why manhole covers are round.
for one, you don't have to worry about the orientation of placing a heavy chunk of steel.
also, they can be rolled into place.
and the way a square manhole cover falls into a square hole is diaganolly.
[/] <-- like this
ok fedoraman now check pic related for a possible design of a square cover that would work
So, what you've just done is add a bunch of unnecessary material to an object that was already really heavy and difficult for a person to remove or replace due to the size, material, and thickness of the object. You also made replacing the cover more complicated by requiring it be oriented a certain way to fit the hole. You've also further complicated the production of a manhole by requiring the topmost portion to be cut into a square rather than a circle like the rest of it in order to fit the square cover and the seat for that cover. Perhaps it could be done if you wanted to, but...
This is why not.
You guys realize it's a trick question, right?
They just want to see if you go on and on about irrelevant manholes, meaning you failed the test.
Correct answer is: "I'm not here to discuss sewer systems, I'm here to talk about software - let's get on with it".
>Someone drives over manhole
>manhole subject to forces trying to make it slide due to the vehicle driving over it
>sharp corner of the manhole cover is pressed into the corner of the seat
>the corner gets flattened a little by the force
>this continues to happen as more people drive over it
>manhole cover corners get more and more squished
>some of the metal sticks up from the now rounded corner
>the shape of the metal sticking up from the cover causes it to dig into tires and damage them
>ruined tires everywhere
>Any coder worth his salt will prioritize performance first, because it's about the principles of coding
Wrong as fuck. Better to write something that works first before worry about all the little bits and bobs to optimization. You'll end up wasting more time worrying and contemplating all the minor things you can do to squeeze performance out of something before you even have a working product. Which in a business, having something working is paramount.
Google employee here. Nobody uses Homebrew to set up OS X machines, it's a shitty package manager. We have our own package manager we use to push updates to OS X developer machines (although they can technically install brew if they want, but we don't install it) and we also use puppet.
Anyways yeah if you can't write a basic algorithm then you're not good enough to work here. How hard is this to understand? Hiring a new employee is a huge risk. Starting salary is $100k+ out of college and $130k+ if you have previous experience. Add in signing bonus, relocation bonus, annual bonus, annual stock grant, and 401k matching and it's a costly endeavor. Now consider the fact that it takes time to determine whether an underperforming employee just needs a kick in the pants or is simply not good enough (meaning he's still going to be collecting all the money I mentioned for potentially a few years), it's going to be expensive to just take a chance on every idiot who failed data structures and algorithms 101.
That said, we never want to miss the opportunity to hire someone who is good, which is why we extend interviews to people even if we aren't 100% sure they're up to par. When reading your resume, we err on the side of calling you. But when making a hiring decision based on the interview, it's not so simple. In OP's pic, maybe the guy had a borderline resume and we called him anyways and he arrogantly thought he was a shoo in.
because they want you to demonstrate a fundamental knowledge of the theory of computational science.
if you cant do something that simple, then it shows how lazy you are, deep down.
how would a billion dollar company exist for much longer if they hired a bunch of lazy NEETs? protip: they would become yahoo
The future of the world is a TRUE meritocracy where social awkwardness or autism dont matter. It will be kinda sad since socialization will lose importance but it will be objectively more fair.
Until that happens, bullshitting, being le cool guy, a spoiled normie or an "unprivileged" mexican whose family earns 300k$ a year are all that matters.
>having something working is paramount
This is what some people fail to realize. Getting the product into users hands is the most important thing, and then just making incremental feature and performance changes is secondary.
The equivalent would be if Henry Ford would've waited until he had the equivalent of a luxury car before going to market. When in reality the average consumer was more than happy to have a Model T (crank starter and all).
I guess this approach explains why the poster is still (as he claims) in the start-up phase despite being 8 years in business.
>it's a shitty package manager
lol. based on the guy's tweet, i figured his software had to be important shit, like some underlying technology that google built it's software on top of.
yahoo takes lazy neets?
i want to work for my autismfu
>future of the world is a TRUE meritocracy where social awkwardness or autism dont matter
Hate to break it to you sunshine, nothing is changing. Just poor people playing musical chairs with other poor people.
i dont give two shits """""""""""""""SUNSHINE"""""""""""""""""", i learned how to interview already so now this unfairness only holds other candidates back in comparison, which is always good.
in might seem like nothing is changing but in large scale i believe that discrimination based on likeability will eventually end, giving way to all those cringey autists that actually have interesting skills.
>i learned how to interview
I didn't know people needed "learn" how to interview. Did your dad sit down with you and tell you to gloss over your MLP collection and Minecraft hobby?
>i believe that discrimination based on likeability
So, you think people are going to want to with you just because you're such a great talent but you're an absolute pain in the butt to work with?
>giving way to all those cringey autists that actually have interesting skills.
>>because they want you to demonstrate a fundamental knowledge of the theory of computational science.
>>if you cant do something that simple, then it shows how lazy you are, deep down.
It does nothing of the sort. It displays practicality and a tendency toward maximum return on reward. Are these not qualities that are prized by companies?
Personally I'd take the guy that can get a stable, maintainable product out to market in 6 months vs the guy who'd deliver a technically correct and theoretically sound product in twice that time.
that's actually not how it works and not how the processor sees it.
so lets take a trip to x86 assembly land...first and foremost, there is no boolean this close to the hardware and 2 doesnt need to be converted to anything.
while(1) and while(2) are both the same cmp eax, ebx instruction. The processor is actually performing a subtract on the 2 registers and flagging whether or not they're equal/greater/less/etc
>adding a statement to your answer calling the interview bullshit
>throwing a fit on twitter about not getting hired
Sounds like he would have been great to have around at the office
His comments are spot on though. The main facebook iOS app is better than it used to be though still lacking, but their other stuff like Messenger is rock solid.
He's right about google stuff too. Google iOS apps are built in Java and translated to Objective-C with an automated tool and it shows really badly.
>condensing logic into as few characters as possible vs using more statements more clearly with equivalent semantics
>not adding comments
maybe if you're trying to optimize the size of your program
otherwise you're just jerking off and looking for more people to jerk off with
I interviewed with google last year. Took me way too long to solve a simple question and although the interviewer couldn't tell if I passed or not you can just tell by their voice.
Don't get butthurt. Literally just move on and get better.
I did this for a couple years, but I got bit by a couple bad hires who could talk convincingly about projects they had been a part of previously, but were actually astoundingly poor programmers. I've now added a couple questions a little bit more difficult than fizzbuzz just to weed out people who really can't do anything, of which there are a surprisingly high number.
I've been to countless interviews. The thing about interviews its that they are a two way street.
You should use interviews as a gauge of the company and the people you'd be working with. Normally I ask about compensating training programs/certificates/books/conferences/et cetera, ask technical questions around their infrastructure (you know thing you'd have to support if you got the job), upcoming and current projects, the userbase, number of users/systems, type of users (sales, developers, execs, et cetera), and ask what is the best/worst thing they like about their jobs (chances are you'll have similar experience). If the interview allows it, also ask the interviewer technical questions, get a gauge for their level of expertise - you'll have to put up with their incompetence or snobbery if you get/take the job.
The thing about bombing an interview, it gives you an idea on your key weaknesses and things you need to improve as a professional. What are your technicl weaknesses? Weak communicator? Need to improve on self-promiting/selling? So on and so forth.
why are people so hell-bent on performing some kind of test during an interview? just talk and present common issues dealt with daily and see how they are handled. this is not complicated and it is not open to controversy. but apparently people want to fizzbuzz test into the next century.
The whole purpose of the interview is to give a defensible reason not to employ you.
HR people have long ago realised that they have no idea what other people do in their jobs so they have no hope of fitting someone to any particular job.
So they work on exclusion. If they can't find a reason to refuse you then that's a defensible reason to hire you.
>I find that you often understand the the problem through the act of trying to implement it
You must be kidding? This is actual not bad advice and I have hired a few people because of their interest in the company. Guess what? They still work for me and I hope they never leave, best employee's I've ever had.
>Nobody uses Homebrew to set up OS X machines
ookay bud, but that's not what he was saying.
Probably 90% of everyone who's used numpy/scipy on a mac have installed homebrew at some point, so basically he's more or less correct. But yeah, anyone who uses homebrew on the reg is probably a total memester
Yes. As crazy as it may seem, people in the industry are employed for their ability to produce a working product>>52339624
>But yeah, anyone who uses homebrew on the reg is probably a total memester
Questionable. I keep it around for easily installing+updating libraries and various FOSS stuff. It's lighter and faster than the monster known as MacPorts, and isn't Fink just dead? I feel like there was a third package manager, but I can't remember its name...
I don't understand how you got 'I can produce a working product' from a group of posters so insipid that go as far as questioning if someone is allowed to 'use the goto statement'. Not to mention the original poster saying "I don't understand the problem. Fuck it I'll just start 'coding'."
To be fair though, I can probably produce a 'working' product by patching 10 random libraries together. Albeit it will probably be complete shit the first few releases, and I'm not even a professional programmer.
>mfw my dad makes 70k a year driving a bus like 6 hours a day
>mfw a friend of his retired with 3 million in their pension
>not being able to invert a binary tree
What the fuck? Obviously this idiot hasn't written any code for homebrew. Most package managers utilize a lot and various more complex data structures to a simple tree, namely the the DAG (see topological sort), which is often used in dependency resolution. If you don't know how to invert a simple tree, which any CS2 script kiddie can do, you're honestly retarded.
I just spent the last week refactoring a Step 7 STL file that some retarded preschoolers wrote from a different branch of my company. Instead of using something "scary" and "hard to read" the dumb niggers copy and pasted the same 300 line blocks of code 20 times and wrapped them in fucking jump instructions, because using 3 basic commands is "easier to read" than using indirect fucking addressing and condensing it into a 50 line file. If you think it's easier to debug and enhance a 6k line file compared to a complex 50 liner then you're fucking retarded and you need to fucking kill yourself.
Retarded oversimplification by noobs and shitty unreadable code by fedora "ninja" coders, are both bad.
You need to find a balance in between.
You don't need to trade off readability with performance if you know what you're doing. And even if you have to, you must be able to gauge the performance gain vs long term maintainability.