15 ms·

>> Third, try programming for a day without Googling. Then two days, maybe a week. See how it feels. Remember that there was a time we programmed without copyin

• dozzie 10y ago
  > [...] there is no freaking way I can remember all the details of linux, python, bash, regular expressions, flask, elasticsearch, redis, haproxy, postgresql, mongodb, Google Cloud Platform, kubernetes, logstash, kibana, Java... that's a real list from my last project. Sounds like badly written thing (probably not designed at all). And you do know that there are archaic things like documentation and own notes, right?
  • d23 10y ago
    Why does that sound like a badly written thing, you having no knowledge of the specific domain he's referencing? Perhaps it's a web frontend in flask, load balanced by haproxy, uses redis heavily for caching, postgres for structured data, and mongo for analytics (yeah yeah, we can gripe about how bad mongo is). These applications run via kubernetes on GCE, the logs of which are forwarded to logstash, stored in elasticsearch (running on the JVM), and viewed via kibana. > And you do know that there are archaic things like documentation and own notes, right? Yes, hence his mentioning that he needs to Google to reference them.
    • markbnj 10y ago
      A nearly perfect description, from someone who has obviously built similar systems :).
    • dozzie 10y ago
      > Why does that sound like a badly written thing, you having no knowledge of the specific domain he's referencing? I don't have the knowledge, that's why I didn't claim the system was badly written, I only expressed my impression it was. I know, it's a subtle difference easy to be overlooked, especially if somebody is invested in similar architecture. And it still sounds like a bad idea to tie oneself to specific log transport and log storage, and to a single load balancer at a project time. Use of MongoDB when already using PostgreSQL (or vice versa) doesn't add much soundness, either.
      • CydeWeys 10y ago
        Why would you admit to not having knowledge of the domain in question, and then, right in the same post, continue making speculative disparaging comments about the technology stack in use, which you self-admittedly know little about? Knowing when your opinion is valuable to others, and withholding it when it is not, is a useful skill. > Use of MongoDB when already using PostgreSQL (or vice versa) doesn't add much soundness, either. Come on, they're entirely different kinds of databases. PostgreSQL is relational, MongoDB is not. It's very reasonable to use both kinds together in a larger project, each for the type of data that it is best at. I have worked on multiple software projects that combined some variant of SQL (e.g. MySQL, PostgreSQL, MS SQL) with some variant of NoSQL (e.g. MongoDB, DynamoDB, Datastore). Trying to shoehorn everything into a single schema would have been worse.
  • markbnj 10y ago
    You think that list of technologies is unusual? It's not. And while I keep plenty of my own notes, I am not sure why you think trying to replicate the online documentation that can be quickly found through search tools would be a better strategy.
    • dozzie 10y ago
      I'm aware it is not unusual. It is not unusual for software to be badly written, too (being wide-spread is no sign of being a proper way of doing things). For a single project (and OP said it was one project) depending on that many specific tools coming from that many fields is a strong sign that the project does too much. Most of the tools mentioned by OP are from the set to be decided in deployment time instead of design time (log transport, storage, and browser, deployment automation, stuff like that), and they should not be dependencies.
      • markbnj 10y ago
        The concept of a "single project" leaves a lot of wiggle room. In this case the "project" I refer to was a mobile application with all the front and back-end pieces that implies. You could carve the "project" up into sub-projects and view it however you wish, but since I was responsible for much of the back end pieces I experienced it the way I described.
• parennoob 10y ago
  > as a reward you the interviewer get to pick anything you want from that huge list and try to trip me up with it! ;) I don't know about you, but an interviewing process like that would be a strong signal for me to not work at that place.
  • markbnj 10y ago
    Well, it is not so much that any single interviewing "process" would define itself that way. It's more the simple fact that so much of interviewing success or failure depends not on how much you understand, or the breadth of things you've worked with, but rather whether you can run the gauntlet of questions and answers that interviewers use to prove to themselves that you know what you're talking about. Any scalable internet service is going to involve a laundry-list of technologies similar to the list I gave above.
• CydeWeys 10y ago
  This kind of thing may be partly why interviews are heavy on CS fundamentals -- most good developers agree that they are important in a way that framework quirks are not, even if we don't remember all the details throughout our daily lives. Personally I feel much more at ease disqualifying someone in an interview because they e.g. don't know what a binary search tree is for than if they try to use a Java for-each loop over an Iterator when that only works over an Iterable.
  • crdoconnor 10y ago
    >This kind of thing may be partly why interviews are heavy on CS fundamentals -- most good developers agree that they are important in a way that framework quirks are not Google's interviews are heavy on fundamentals because virtually all of Google's tech stack is home grown. Other companies imitate this behavior largely because "if google does it it must work great". Ironically a majority companies actually miss the CS fundamentals that are vitally relevant to them (e.g. relational theory) in favor asking the fundamentals that aren't (e.g. big o notation).
    • NotSammyHagar 10y ago
      When I worked on databases at Microsoft we were totally trying to find people with good cs fundamentals, and who could program. That was what we were looking for (like totally, dude :-)). At google we looked for those things. And in my new job, we also look for those things. Sure, now we ask questions about server and distributed programming, but good cs fundamentals are fundamental still.
    • CydeWeys 10y ago
      You mean relational as in RDBMS, right? I'm curious, what parts of relational DBs do you think are under-emphasized in a typical CS education that you make sure to ask interview questions about? Things like what does a LEFT JOIN do, etc.?
      • crdoconnor 10y ago
        Normalization is under-emphasized in interviews.
• gregpilling 10y ago
  In real life, without an internet connection (say 1980) you would have had books. Life is an open book test, as the saying goes.
  • TeMPOraL 10y ago
    Books and local documentation. One good side effect of working back in the days of spotty (or no) Internet connections was that people were more focused, instead of inventing a new framework every week.
  • anexprogrammer 10y ago
    Yes, but chances are you'd have a fairly static set. For serverside, you'd have K&R, Stroustrup or the Sun Java books, W Richard Stevens, perhaps Design & Implementation of BSD and maybe a domain book or two and you're good to go - for years and years. There'd perhaps be some ludicrously expensive object library that's needed for some domain detail - but it was bought as 1.9, and will stay 1.9 forever because ludicrously expensive and management. You didn't much care that there was a new C++ or C standard release, until addison Wesley put out the book to go with it and management got around to buying tech the relevant updates. Now you're mucking about with serverside and there's 20 different technologies, all being updated and security patched constantly. The project you did 6 months ago relies on some deprecated function set, and the prev release of SomeThing and PostreSQL, and half a dozen other toolsets and libraries. The next project is going to use WizzyNewTech0.8 as well. You either Google constantly, or fail and go crazy. There were advantages to the 90s - you'd have newsgroups for support that were free of spam, and full of techies. You could spend much more time solving actual problems than mucking about deciding on and changing the framework set. You didn't get pwned by 0 days if you didn't update your tech constantly either.
  • proyb2 10y ago
    Possible for Encyclopedia, impossible for technology related to stay relevant in the next few years.
• mancerayder 10y ago
  "I'm interviewing right now, and if you can't tell it's frustrating. I'm not valuable unless I am experienced and capable with a huge list of technologies, and hey, as a reward you the interviewer get to pick anything you want from that huge list and try to trip me up with it! ;)" I totally understand and sympathize with the experience, as a DevOps Engineer with alphabet soup on his CV like you probably do. I experience the same. However, some nuances about your position (and some of the replies about binary search tree questions)... I think good interviewers are going to pick questions based on what you put on your CV. I doubt they're picking from a metaphorical hat questions about redis, flask, Python, java, etc. unless they read them in your resume. Next it's totally fine to use this broad-based category like approach, so long as the interviewer is asking general questions about the technologies. If I put Python on there, I should expect to be able to answer how in general I'd parse a text file with it, or a basic regex example, or when I last used flask and what it was used for. In my personal experience, only amateurs or people who are socially inexperienced ask questions that require an insane memory or having used the technology the day prior as in your example. When I first started my career as a jr guy, and was interviewing someone, I'd commit these same errors. I think the right thing to do is trim some of that soup on the CV, and like someone else says be wary of bad interviewers. And know that sometimes they trip you up just to see how you respond.
  • crdoconnor 10y ago
    IMO good interviewers just ask for you to perform a task that's a close analog to what you will be doing every day. I've had this happen once. Sadly, despite this being straightforward and effective it's incredibly rare. Cargo cult "binary tree search style" problems and technology stack trivia questions are more normal. The level at which dogma and fashion drive this industry is almost embarrassing.
    • mancerayder 10y ago
      I have a refrain I like to repeat to myself sometimes, which goes roughly like: in the land of the blind, the one-eyed man is king. It's true that the interviews can be pretty retarded. Most of our roles don't require knowing half the complex stuff they ask to weed people out. If you're just out of college that stuff is reasonable to ask [1], but otherwise as a hiring manager you should ask what you're looking for. For example, if I'm looking for someone who a) doesn't lie about their experience b) has experience in some of the technologies I need a project completed with or ongoing support for on day 1 c) has the ability to learn technologies I'll need help with on day 180, then I'll ask about a project that was listed on the CV, stopping to ask for more detail about how something works. Then I might present a scenario or problem that's theoretical (or really happened) and have the candidate walk through it. That was when I was a hiring manager. I didn't weed out good people by asking them dumb questions about how many marbles would fit from here to the moon, or about the different types of O notation. Of course, this is specific to the roles I was hiring for (DevOps). When I was on the flipside, I was weeded out by overachieving mid 20-somethings who really relished putting me on the hot seat. It felt not dissimilar to a bad date sometimes. I consider it a 'competitive advantage' that the latter style of interviewing is so commonplace, because it's so off-base. It doesn't make me as frustrated anymore, probably because I'm old and cynical, and a lot more independent now. My thinking now is 'how can I use this to get a leg up on the competition' whether that means learning some cursory rote algorithms stuff if I'm interviewing, or just knowing how to ask the RIGHT questions to get the good candidates (something I feel pretty comfortable about) if I'm the interviewer. [1] I think it's reasonable to ask questions of a college grad that he would have learned in a hard-core comp-sci class for the same reason I'd ask in-depth questions about the projects in the last role: because it's the freshest thing in their minds and they 'should' probably it. Please don't bother us old guys with comp-sci fundamentals. Unix and TCP/IP fundamentals, on the other hand ... (Edit: turns out using an asterisk in here causes some weird markup behavior)
• slyall 10y ago
  One of the things is that before everybody became a "full-stack devops" you didn't have to be an expert at all those technologies. * The Sysadmins knew Linux, bash, logstash, kuberneties * The programmers knew python, java, regular expressions, flask, * The DBAs knew mongodb, postgresql * The network guys knew haproxy, firewalls, switches, etc Everybody knew just enough of the other other platforms to get along and sure it was great if one of the Sysadmins was a python expert or the programmers were great at tuning redis but you were only expected to be an expert at some of it.
  • shermanyo 10y ago
    I paused for a second when I realized how many of those I understand enough to talk to, but not enough to do anything useful without examples to use as a starting point. Maybe that's a good indicator of the point we should divide responsibilities at. (now if only we had headcount to cover distinct roles like that... ha!)
• dikdik 10y ago
  I'm in the same boat and it is hair-pullingly mad. On top of that, having someone stare at me and my work while I'm programming adds a ton of anxiety (and thus poorer performance). I wish there was no in-person technical challenges (I'm sure there are companies out there like this), have me do a small project then come in and speak about it as part of my interview. I get that the types of projects they give out may often be google-able, BUT if it's similar to the types of challenges I will be seeing if hired then it shouldn't matter! Google is just as much of a tool as Java or Python.
• shermanyo 10y ago
  > there is no freaking way I can remember all the details of linux, python, bash, ... As a suggestion, maybe try limiting yourself to local documentation? It can be useful for times when you do plan to work offline (flights, no wifi), and are often more consistent and faster to use when you're familiar with the format (eg. man pages). If you find it limiting in your day to day work, try keeping a list of the common sites you frequent (language references, common examples / snippets) and build a personal repository of reference material to replace your internet searches over time. I have a repo with top level directories for each language, containing an assortment of text files (I use .md though I really only read as plaintext with vim), code examples and scripts (build script examples, library install scripts, etc..). I think of it like constantly preparing for an open book test. If I understand all my resources (because I wrote them), and can quickly find what I'm looking for, then its legitimately all preparation. Using google always seemed like trying to learn the topic while applying it for the first time in the test. I'm never as confident in the result, even if I do think I understand everything in the end.