|
I didn't read that statement as a judgement for your situation as much as commentary for others. I've seen plenty of decade-long projects with terrible code exited successfully because the executives were well-connected enough to get the company sold to a sucker buyer somewhere. I'm including very well known tech entrepreneurs supposedly known for "quality", not just some small-time whatever software companies. I've seen companies with at least 4 total re-writes of the flagship software manage to plod along after small fundraising rounds and/or lobbying, too. If companies like Theranos can survive for years with basically a non-functioning product we can only guess how long useless companies can survive from our vantage points as employees far from the C-suite or board of directors. Edit: to contribute a coding horror, I didn't realize until after I got off a whiteboard I wrote out a coding horror... O(n) space algorithm, O(n log n) time. It could have been done without pre-sorting anything in O(1) : O(k), k being a small constant. Ugh necrobobsledder fucked around with this message at 23:04 on Oct 14, 2016 |
#
?
Oct 14, 2016 22:59
|
|
|
|
| # ? May 14, 2024 15:17 |
|
|
1337JiveTurkey posted:edit: It'd be an amusing Goon Project to get those characters in wider use. My favorite use is in the IRC Server RFC that nobody uses: https://tools.ietf.org/html/rfc2813 quote:Optionally, the user status (channel modes 'O', 'o', and 'v') on the Of all the separator characters they could have chosen, they chose an ASCII bell...
|
|
#
?
Oct 15, 2016 00:03
|
|
|
Constant factors aren't shown in big-O notation so if k is a constant then it's just O(1). The real horror is people who believe that understanding big-O implies an understanding of how to analyze performance in the real world.
|
|
#
?
Oct 15, 2016 00:48
|
|
|
A bit old but it popped up in my Twitter feed today and it seems relevant: http://gwan.ch/blog/20160405.html (Coding interview horrors.)
|
|
#
?
Oct 15, 2016 01:07
|
|
|
fleshweasel posted:Constant factors aren't shown in big-O notation so if k is a constant then it's just O(1). This. Please claim traversing Linked Lists are O(n) on a modern processor. 
|
|
#
?
Oct 15, 2016 01:32
|
|
|
UraniumAnchor posted:A bit old but it popped up in my Twitter feed today and it seems relevant:  I remember those screener questions, I remember the time taken question because Google just published a paper stating how context switches are the slowest now; I also said SIGKILL when the interviewer wanted SIGTERM; the better answer to bit counting is using the POPCNT x64 assembler or compiler intrinsic, however also not on the interviewers answer sheet.
|
|
#
?
Oct 15, 2016 01:35
|
|
|
Simulated posted:This. Please claim traversing Linked Lists are O(n) on a modern processor. I am claiming this, with the caveat that the N in question has an eon for a coefficient.
|
|
#
?
Oct 15, 2016 02:37
|
|
|
Simulated posted:This. Please claim traversing Linked Lists are O(n) on a modern processor. It is O(n). It is also O(1).
|
|
#
?
Oct 15, 2016 02:40
|
|
|
sarehu posted:It is O(n). It is also O(1). Can you explain the latter?
|
|
#
?
Oct 15, 2016 02:52
|
|
|
Fergus Mac Roich posted:Can you explain the latter? All computers have finite memory+storage, therefore the time it takes to traverse a linked list is bounded above by a constant, therefore it's O(1).
|
|
#
?
Oct 15, 2016 02:55
|
|
|
Fergus Mac Roich posted:Can you explain the latter? Modern processors only have 64 bits, and it's O(64), which is O(1).
|
|
#
?
Oct 15, 2016 02:55
|
|
|
The algorithm is run once (1) each time it sorts a list. Thus it is O(1).
|
|
#
?
Oct 15, 2016 03:00
|
|
|
vOv posted:All computers have finite memory+storage, therefore the time it takes to traverse a linked list is bounded above by a constant, therefore it's O(1). Does that mean if we can prove that the universe will end one day, all algorithms are O(1)?
|
|
#
?
Oct 15, 2016 03:05
|
|
|
UraniumAnchor posted:A bit old but it popped up in my Twitter feed today and it seems relevant: From what I remember this dude used to shill his software on webhostingtalk and a few other forums with socket puppy accounts (or had his friends do it), and also had quite a bit of a god complex (bit of an understatement), especially when people asked him to support FastCGI for PHP on his webserver, that was a hilarious response
|
|
#
?
Oct 15, 2016 03:49
|
|
|
taqueso posted:The algorithm is run once (1) each time it sorts a list. Thus it is O(1). I'm loving the idea of Donald Trump coder as a gimmick Twitter account
|
|
#
?
Oct 15, 2016 03:54
|
|
|
Coffee Mugshot posted:Keybindings discussions might as well be plane on treadmill discussions tbh. So there's one objectively right answer, but nobody can agree on what it is?  (Sounds about right)
|
|
#
?
Oct 15, 2016 04:15
|
|
|
necrobobsledder posted:Close, there is one list being sent to the algorithm, so its input size is constant. https://twitter.com/isotrumpp/status/786015255910428672
|
|
#
?
Oct 15, 2016 04:17
|
|
|
Fergus Mac Roich posted:Does that mean if we can prove that the universe will end one day, all algorithms are O(1)? Also, every program halts.
|
|
#
?
Oct 15, 2016 11:17
|
|
|
Fergus Mac Roich posted:I am claiming this, with the caveat that the N in question has an eon for a coefficient. Interestingly enough, assuming linked list with nodes scattered randomly across the memory, its closer to N log N, because you get hosed by virtual memory <-> physical memory mapping. Obviously assuming real CPUs for analysis and not the idealized RAM.
|
|
#
?
Oct 15, 2016 12:35
|
|
|
Xarn posted:Interestingly enough, assuming linked list with nodes scattered randomly across the memory, its closer to N log N, because you get hosed by virtual memory <-> physical memory mapping. That's a different N, though. That's N with the size of whatever index is used to look up memory locations.
|
|
#
?
Oct 15, 2016 13:38
|
|
|
UraniumAnchor posted:A bit old but it popped up in my Twitter feed today and it seems relevant: This guy is so smug it's painful to read.
|
|
#
?
Oct 15, 2016 14:12
|
|
|
UraniumAnchor posted:A bit old but it popped up in my Twitter feed today and it seems relevant: Me:  Interviewer: Wrong, it's 2 Me: 
|
|
#
?
Oct 15, 2016 14:56
|
|
|
To be fair, he did get some answers right and the screener was all "NOPE it's gotta be a perfect text match to what I got written down!!" If it was an actual technical interview with a skilled interviewer he probably would have done a lot better.
|
|
#
?
Oct 15, 2016 15:35
|
|
|
The interviewer reads like someone going through the motions, who really doesn't want to hire anybody but has to look like they tried. Maybe afterwards they rollerskated away in a huff and couldn't quite get out the door.
|
|
#
?
Oct 15, 2016 15:52
|
|
|
Spatial posted:The interviewer reads like someone going through the motions, who really doesn't want to hire anybody but has to look like they tried. I was totally expecting the "I'm late... for business" meme.
|
|
#
?
Oct 15, 2016 16:41
|
|
|
Spatial posted:The interviewer reads like someone going through the motions, who really doesn't want to hire anybody but has to look like they tried. It reads like a recruiter doing the "Sorry, we couldn't find any qualified applicants for this posting in America" H1B dance, but apparently in Switzerland. Storysmith fucked around with this message at 19:14 on Oct 15, 2016 |
|
#
?
Oct 15, 2016 19:11
|
|
|
Fergus Mac Roich posted:That's a different N, though. That's N with the size of whatever index is used to look up memory locations. This. If you're going to add a log K factor to account for virtual memory resolution, you need to add a log K factor for copying pointers around. And literally every algorithm ends up with that factor. It's a pointless formalism unless you really need to model it, e.g. if you've got distributed memory.
|
|
#
?
Oct 15, 2016 21:09
|
|
|
xzzy posted:To be fair, he did get some answers right and the screener was all "NOPE it's gotta be a perfect text match to what I got written down!!" Most of his answers are non-answers, or make unwarranted assumptions about the question just to show off his specific technical knowledge. "There's an array of 10,000 16-bit values, how do you count the bits most efficiently?" and he starts talking about 64-bit words for some reason? Maybe they want to run this algorithm on a Motorola 68k for all he knows. Even in his followup he starts talking about 8-bit lookup tables being too small and 64-bit lookup tables being too big, when clearly they wanted him to make a 16-bit lookup table. Sadly he's too "clever" and didn't even consider that option apparently.
|
|
#
?
Oct 15, 2016 21:25
|
|
|
rjmccall posted:This. If you're going to add a log K factor to account for virtual memory resolution, you need to add a log K factor for copying pointers around. And literally every algorithm ends up with that factor. It's a pointless formalism unless you really need to model it, e.g. if you've got distributed memory. And log n is bounded above by n log n
|
|
#
?
Oct 15, 2016 21:31
|
|
|
I get that, he'd fail any interview on personality, but there's a valid argument for an interviewer to accept more than an exact string match.
|
|
#
?
Oct 15, 2016 21:32
|
|
|
That guy is so angry and insufferable that I'm not sure its wise to give him the benefit of the doubt on his presentation of the interviewer's attitude.
|
|
#
?
Oct 15, 2016 21:35
|
|
|
xzzy posted:I get that, he'd fail any interview on personality, but there's a valid argument for an interviewer to accept more than an exact string match.
|
|
#
?
Oct 15, 2016 21:45
|
|
|
If you're thinking in "gotcha" C questions mode "those functions return error codes" isn't too unreasonable a trap to fall into. I'm sympathetic because half of my recruiting calls with google itself used some sort of god awful VoIP system that cut out half of every sentence. I still passed, but primarily because I had a coding screen using a shared google doc and communicating through text did work. hobbesmaster fucked around with this message at 21:53 on Oct 15, 2016 |
|
#
?
Oct 15, 2016 21:51
|
|
|
Volte posted:Maybe, but none of his "valid but not valid" answers struck me as particularly uh... valid. I'd give half marks at most if I were a TA. His answer about an inode being an index is particularly wrong, since an inode is a data structure. His semantic quibbling about whether stat() "returns" an inode doesn't help. He also had to drop that he wrote a custom libc for his product, as if that bestows any validity upon his answers. He doesn't even answer the quicksort question (merely states that the question is invalid), overanalyzes yet still manages to be wrong about the lookup table question, and gives an arcane answer to the TCP question when a simple one would have sufficed. These are all things that give hints as to what kind of developer he would be: stubborn, narrow-minded, gets bogged down in details, can't see forest for trees. Possibly, but again, at the phone screen level where an interviewer is expecting answers off a sheet, it's implausible that they're screening for complex personality factors unless the tone was way more aggressive and unpleasant than what was conveyed - which may well be the case. Maybe I'm wrong. I think this is such a controversial topic because it seems like both sides were a bit off, if you take the transcript at face value. I think more likely, and as one Google employee has already suggested on reddit, we have an unreliable narrator. Anyhow, the guy obviously thinks he's way hotter poo poo than he is. If his poo poo was indeed so unpleasantly warm, why is he being brought in at the phone screen level? Why doesn't he have a dozen contacts who will vouch that he's experienced and great to work with? speng31b fucked around with this message at 21:56 on Oct 15, 2016 |
|
#
?
Oct 15, 2016 21:52
|
|
|
Taking his presentation of the interview 100% at face value: his answers about inodes are correct, and the interviewer might not fully understand the concepts involved. An inode is a filesystem object which is hard-linked into various places in the directory tree. It has metadata (and that metadata can indeed be thought of as a collection of attributes), but it is fundamentally more than its metadata: it's a thing with its own identity independent of any process. You can't really return an inode in its proper sense any more than you can return a person or a server. stat returns the current copy of some of the metadata from an inode as well as an (unsafe weak) reference to the inode represented as a integer. Now programmers, as human beings, often gloss over the difference between "the thing" and "a reference to the thing" when they're talking. This is totally reasonable and understandable and okay. A candidate who can't just roll with it is failing to communicate effectively; it's a failing that's pretty common among people who are, let's say, quite a ways out on the spectrum, and while that might justify a bit of patience and understanding, it's also a failing that does actually seriously and continually impact their ability to work with other people, so it's not really unfair to take it into account. Anyway, I would expect a candidate to understand this question as "what syscall returns a reference to an inode given a path", for which the answer is indeed "stat". But then the interviewer's comment about "the inode contains all the metadata" really makes it sound like they don't understand that the inode is more than just the stat struct, and that's a pretty big red flag — assuming, again, that his presentation of the interview is 100% faithful.
|
|
#
?
Oct 15, 2016 23:02
|
|
|
hobbesmaster posted:And log n is bounded above by n log n I have no idea what you're trying to say here. Xarn said that walking a linked list is N log N; Fergus correctly pointed out that it's N log K, where K is the size of the address space; and I added that if you're including this "size of the address space" factor, you need to apply it to everything instead of singling out linked lists. Indexing into an array is O(log K). You can try to make a locality argument to drop this factor because of translation caches, but now you're talking about a sequence of operations, because reading a single array element at a random index does not in fact have some sort of inherent, magical locality. And if you're walking an entire array, you are still going to have to translate a linear number of pages at O(log K) per translation, even if you're only falling into that O(log K) expensive case 1/whatever-th as often as you would if you were walking a linked list. rjmccall fucked around with this message at 23:20 on Oct 15, 2016 |
|
#
?
Oct 15, 2016 23:17
|
|
|
On HN and Lobsters there are two different people who remember that guy from two different forums/situations (I think) saying, yeah, take this story with a grain of salt.rjmccall posted:But then the interviewer's comment about "the inode contains all the metadata" really makes it sound like they don't understand that the inode is more than just the stat struct, and that's a pretty big red flag My understanding from what I've read is that this isn't a dev, it's some idiot recruiter phone screening you for the actual phone screen.
|
|
#
?
Oct 16, 2016 00:18
|
|
|
The other thing to consider is if they are interviewing for a Director of Engineering, it's even more obvious he's not going to work out. Makes me want to ask a SRE interview screen just to see how people deal with the different expectations. That's not the person you want owning multiple groups of engineers...
|
|
#
?
Oct 16, 2016 00:29
|
|
|
Fergus Mac Roich posted:That's a different N, though. That's N with the size of whatever index is used to look up memory locations. My original post was trying to point out that Big-O often doesn't explain actual performance and you should be careful when using it as a proxy for performance. A data structure with theoretical O(N) performance can be easily beaten by one with O(log N) performance if the latter makes better use of cache. Summing the elements in a linked list and summing the elements in an array are both O(N) in theory; they should both execute around the same number of instructions. In reality the array will be faster and the larger your dataset (or the more spread out the linked list nodes) the faster the array will be. For a 1 GB dataset the array can absolutely kill the linked list, in some scenarios by an order of magnitude. How useful was knowing they are both O(N) if one takes 10x as long to execute? I wonder if the most practical benefit of thinking about Big-O is avoiding the exponential algorithms.
|
|
#
?
Oct 16, 2016 00:33
|
|
|
|
| # ? May 14, 2024 15:17 |
|
|
Simulated posted:My original post was trying to point out that Big-O often doesn't explain actual performance and you should be careful when using it as a proxy for performance. A data structure with theoretical O(N) performance can be easily beaten by one with O(log N) performance if the latter makes better use of cache. This is why a common interview question is to explain when you shouldn't use quick sort.
|
|
#
?
Oct 16, 2016 00:42
|
|