27 karma · joined May 15, 2012
Recent experience was in value added services for cellular networks involving SMPP protocol as well as streaming software.
Have also been a free lancer for many years writing high performance applications and a good deal of open source software such as VLC, dnrd to name a few.
I know they said they applied to anything - but still anything for that profile might be a bit more broad - entry level IC to FANG may be which pays better or a role that is open to leveling or start up or any other combos.
If you are applying for a principal or higher engineer role and your job involves coding, you are asked coding questions. May be not just focused on a complex bookish algorithm only, but rather more close to a real life distributed programming / synchronization problem etc. for example.
That being said, ability to solve coding problems efficiently (not necessarily spit A* graph algo in sleep), but a decent close to real life coding challenge is fair game.
http://stackoverflow.com/users/88656/eric-lippert
containing a lot of answers, worth reading even if you are not exactly looking for solution to the problem at hand.
A classic one http://stackoverflow.com/questions/6441218/can-a-local-varia...
So the whole line of reasoning is irrational to me. Never tried saying systems programming is more main stream then web or desktop or enterprise.
Talking about renowned, Yes people who have written kernels, operating systems, network stacks / protocols - there is huge list of renowned ones. Do you want me to spell the names out starting with Torvalds or Stallman?
How about a gateway device receiving some minor 3-4 millions subscribers traffic and processing like 40-50Gigs per second. I suppose worrying about hashing those ips to access individual records is a waste of time, and a simple list should work? right?
The scenario is not as common as may be building a website. But it a whole industry and a whole bread of programmers exist who do this all day. You should go out more :)
Ah... yeah for the design statement :) i can't say much beyond that for most of the companies with established practices - you have to write a design document, often down to the level of writing data structures and function names - run through debates with others to justify your choices BEFORE you can even start to write first line of code.
I understand this partially because of being in Embedded, C/C+ domain where you can literally shoot yourself in the foot due to wrong choices and often product models are different.
E.g. at one place that i worked, code reviews and conventions were very rigid, some what more than say Linux kernel, because the product was an RTOS and associated stacks, which were sold to companies WITH SOURCE since the customers were actually developers developing end applications using our APIs. So even one comment not written according to company's coding convention often won't pass a peer code review - but i believe this is a pure exception rather than the norm.
I accept the point that over optimizing is the root of all evil and the rest of the philosophy along those lines. But knowing algorithms and data structures inside out, because where and when you have to choose what - i doubt one can be called a programmer without all that.
And i would say again, i am yet to find some body renowned, who has made their mark as a programmer, and doesn't regard all of this stuff high enough.
Having said all that, if you work in a high level language and develop client facing / application layer desktop/web related stuff - and not involving too much scaling, you won't need these things most of the times. But if not, you can't live with out these.
Lastly, since college and probably since learning to program, the best of the breed usually were the guys who went on to acm and top coder kinda stuff. It is true that building products is not synonymous, but it definitely plays an undeniable part albeit i must agree that it is slightly over valued, nothing else.
Although not too often (compared to factors mentioned already), but it depends upon the domain too. I worked in embedded for the most part where the liberty of using frameworks, libraries - is far scarce, so it matters which area / programming environment are we talking about in general.
Also, i am yet to run into a good interviewer + programmer (whether more experienced or junior) who doesn't value these things as a good predictor of some one's coding ability.
And we are not talking about only scale of companies like Google or Facebook and in my humble opinion, those might get a bit tooo algorithmic as well.
But you should be able to recognize that a design you did won't scale when you have say 100k or more packets (instances) of inputs thrown at it. It won't be a problem ONLY UNTIL your list of traversal, get big enough, and frankly any software worth being discussed - gets big enough at some point.
Or that your linear traversal should dramatically improve if you could code and use a hash table instead.
Ah - and yes, loved the idea of 'can do serious work for at t least four hours a day', but wonder if there is a way to determine that.
a) I used to work on deep packet inspection software for a multicore network processor. It was kind of c but with restricted api's and some unique concepts related to multicore. Among the concepts was, same binary being run on multiple cores to process packets, but still no hardware locks, because there was an implicit tag - a kind of a hash computed on 5 tuple (src/dst ip, ports, protocol) to ensure only one core gets packets from one session / 5 tuple.
So the scenario was a protocol parser whose job was to parse some other info along with ip, call an external api to add a subscriber. When this parser was ran for like 10-15 minutes on live setup, it used to seg fault after processing some 60-70 million packets. The behavior was reproducible, but was not occurring at the same time, nor in the same piece of code.
Narrowing down didn't exactly work, since it stopped occurring with either of the subscriber addition api call OR the parser was commented. But each worked perfectly on its own.
Finally, after a couple weeks of long debug cycles and notes, it turned out to be AN IMPLICIT tag switch inside the subscriber addition api. Since we were not locking through apis, the tag switch would lead to same packet being sent to multiple cores, and any where along the line in the follow up code, an allocation (which turns redundant) or a shared mem access or deletion (free) it could turn into a seg fault.
Now implicit switch of locks in the subscribe api was also a documented and needed feature of hardware. Just that it should have been DOCUMENTED in BOLD on the api, which was not the case.
b) In the same dpi product, once we added two fields to look for in the incoming traffic which should not have matched but were still matching in results. Unique thing was, they only fail when those were together and would work fine independently.
Going deeper in their code, showed a strncpy which was intended to use as a safety against strcpy, but with MAX_STRING_SIZE. So basically when the actual string was much shorter, it would just wipe off the entire length with padded zeros in the buffer, there by over writing the originally appended fields to look for. The author seemed to have missed the following comment in strncpy's definition.
"If the end of the source C string (which is signaled by a null-character) is found before num characters have been copied, destination is padded with zeros until a total of num characters have been written to it."
Since then, i have been really careful in choosing to use strncpy instead of strcpy as often mistakenly advised in general.
a) For one, giving enough time to come up with a project estimate is often rare. Usually people try to ask for those upfront.
b) Usually we try to add a general buffer for any unseen issues. However, the deeper you go and list tasks against time, the closer to realistic is the total.
c) Often it is just a customer giving a requirement needed at date x, or a management guy setting goal for a date y. When all you can do is to cut features but have to deliver by a given date.
d) No matter what we say, but at the back of our minds, we are not enough prepared to defend a timeline when giving it in the first place. Implementing feature x needs a week? gosh boss would say it should take a day. Latter it turns out the assumption was based upon a library which for just internal implementation reason (that you only discover upon learning it enough through actual code) is completely useless and it should actually be planned for 3 weeks at least.