71–80 of 164 posts
https://news.ycombinator.com/item?id=7819413
[1] There is some attribution a the bottom of the page, but it isn't proper. It contains neither the original author's name, nor is it a clickable link. It's just a plain text URL. Better than nothing, but still the most shabby way of "attribution" I've ever seen.
Accurate, but missed the part where the carpenter is asked to build a cabinet by drawing it on the whiteboard.
Where is it going to go? How big should it be? What's the purpose? Is it going to be built-in, or standalone? What's your budget? Do you want doors, and if so do you want glass in them? Shelves? Drawers? Some combination?
Are there exsting cabinets or furniture in the room? Do you want the style matched, or the woods matched, or both?
All of this stuff goes into the specs for the whiteboard... oh, and you don't know enough about this that "cabinetmaker" is a serious specialization, you should really have put that down as the job title and you should be looking at a portfolio of their work.
So not so far off, really.
would you like to work in such a place?
Accurate, but missed the part where the carpenter is asked to build a cabinet by drawing it on the whiteboard.
- The ridiculously broad yes or no honor question (e.g. "So are you familiar with data structures and design patterns?”)
- The ridiculously specific-to-the-company question (e.g. " Here is a batch of the data our systems generate. How would you process it for triggering of requests to our api?")
- The vaguely worded trick question: "OK that looks good... But how would you do it if you didn't have all these nice Java objects and methods?")
- The Prove-it Take-home that doesn't change anything. "We use ruby and you've mostly used Java, do this ruby take home assignment." Two days later. "Your assignment looks great but we're really looking for someone with more Ruby experience."
- The post-coding interview, resume-based rejection AKA "why the fuck did you ask me to come in in the first place?" rejection. (E.g. "Your coding interview went well but you've jumped around to different projects and we're not sure you wouldn't leave us if given the chance.")
- The didn't drink enough kool-aid rejection. "Don't know the CEO's full bio? Don't know the intricate details of our public API? Didn't read our blog post from this morning? For shame."
Are interview questions this irrelevant? Because there are relevant questions you could ask a carpenter in an interview, like if they've worked with I-joists, whether they know what a nailing schedule is, whether they're familiar with a "California corner", their health and safety knowledge, etc.
I would say that passing interviews is a separate skill, different than doing actual work. They are not completely different, of course, but different. This implies that the irrelevance is pretty high, otherwise you would not need to prepare specifically for interviews.
This is so true. I see a lot of job ads that seem to require very specific experience, but where anyone in that field could do the job. If you just make up eg 4 different types of technology, and put a few things in each bracket: [SVN, Git, Mercurial, CVS] [MySQL, PostgreSQL, Oracle, MSSQL] [AMQP, MQTT, STOMP, RabbitMQ] [Java, C#, C++, ObjC] Now if someone came along and said they'd solved a domain problem (eg tradin…
What's the default implementation of GetHash() in c#? I actually like this question (not that I've ever asked it before), because it teases out how well someone knows .net and C#. The specific implementation of GetHashCode isn't what's interesting. It's whether you know that .net implements reference vs value equality by default, whether you know you really do need to override GetHashCode if you override Equals, test…
Everything eventually boils down to the bunch of algorithms Knuth so carefully documented for us. Learning a new language is just learning the syntax and semantics for it's mapping to those algorithms.
Stop holding languages in so high regard, jeez. IT is held back by this so much it hurts. Let's just describe some sensible high-level evaluation semantics and start all compiling into that already!
Accurate, but missed the part where the carpenter is asked to build a cabinet by drawing it on the whiteboard.
The point of whiteboarding isn't to "build" correct/functional code - it's to get an idea of your thought process and how you go about solving a problem. It's not perfect (and there are both advantages and disadvantages to using a computer instead of a whiteboard) but when done correctly it gives a lot more useful insight than sitting there asking questions about their past the whole time.
Earlier quoted context omitted.
That's how I find myself conducting my own personal development. The deeper I dive into Ruby, the more I find myself able to hold my own in conversation with my friend the graybeard C++ guy whose been doing it longer than I've been alive. He'll describe something he's trying to do and I'll be able to immediately find an analogue in Ruby. I'll get a sense for how Ruby exists in the general evolution of programming lan…
now I want to understand what a framework is I'll short-circuit that one for you right now: you call a library, a framework calls you - it figures out how by some combination of convention and configuration. Libraries put you in control, frameworks make you cede control. You can usually mix and match libraries, whereas you can only use one framework at a time comfortably.
I find myself refactoring code a lot, pulling pieces out and putting them elsewhere. Sometimes I think, "this piece would be better as a gem", or that "this gem needs to be its own application.
When I think about the overall thrust of what I'm doing, I get the sense that I'm building a framework. I need to be able to work web applications into the framework, and the only framework worth really using in this fashion is Rails. But Rails isn't intended to be included as you would a library. I need to understand it better if I'm going to be able to work it into my own framework.