6 ms·

I really liked this quote - "Programmers just starting out today never had to squeeze, so it’s a little harder for them to get the right religion because they a

• jcagalawan 13y ago
  I've had interviews that obfuscate some basic software system or algorithm. They were always just a page or two though, never 30.
• renata 13y ago
  When I interviewed at Garmin they gave me a couple pages of their actual code and asked me to point out the bugs they introduced to it. Thirty pages seems like a bit much for an interview, but I definitely like the idea. Most jobs you'll be looking at other people's code way more often than writing your own.
  • boomzilla 13y ago
    I really like this idea, but it's not easy to apply. Nowadays, most jobs involve writing code that are based on layers and layers of abstraction, so a lot time, you have rely on the API/docs that are given to you. On the other hand, if the job requires a lot of algos and low level code, this will be a good test to gauge an engineer's thought process and mental capability.
    • austinlyons 13y ago
      Many libraries and abstractions that I come across don't have much/any documentation (or it's out of date, etc), so the ability to quickly look at the source and understand it still seems valuable to more than just low level programmers.
  • meowface 13y ago
    I recently interviewed with one of the "big 10" tech companies and was asked to do similarly; I was given 4 pages instead of 30. I felt like it was a good and useful exercise.
  • chiph 13y ago
    I've done this for interviews - we showed them some code that had real bugs in it, as well as some poor design choices (we told them this in advance so they wouldn't think our real code was like that). We were looking for people who weren't afraid to tell us the code sucked and what they'd do to improve it. If they said it was fine as-is, or spotted very few of the bugs, that was a strong no-hire indication. We tried sending the sample to them the day before, but there wasn't a strong correlation between doing that and good responses from the candidates. Basically, if they got it, they got it. And if they didn't, they didn't.
• zaidf 13y ago
  "Ten years ago every programmer ran into resource limitations, so the older programmers are always thinking about those things." Interestingly this is why I believe VCs let founders of start-ups get do partial cashing out in later rounds. In the later rounds when you are shooting to build a billion dollar business, it's not optimal for the company if you as CEO is thinking about your everyday finances or paying past debt.
  • digz 13y ago
    I think you misunderstood the quote. BG is referring to hardware resource limitations... and saying it was a good thing in terms of encouraging efficient design.
  • sizzle 13y ago
    Yeah you definitely misinterpreted that
• Hermel 13y ago
  As the CTO of a cloud startup, I did exactly that. Apart from the usual brain-teaser and whiteboard coding, we gave candidates 20 minutes to browse through a small database project in eclipse. Afterwards, I checked whether they could explain the data structure of that database. The outcome of this test was a much better predictor for competence than any other technical test. I can whole-heartedly recommend it.
  • Eye_of_Mordor 13y ago
    Does this mean you recruited some people who couldn't explain the structure and you found they were no good anyway?
    • seabee 13y ago
      Sometimes you put less weight on an aspect that deserves more because the candidate showed other skills, 'cultural fit' etc. Sometimes you realise that was a mistake :)
• hoka 13y ago
  IMO, that quote's garbage and really "back in my day". Our resources are just more powerful today. We still run into performance issues with things like bulk updates and computation times (MapReduce / distributed computing) quite frequently.
  • georgemcbay 13y ago
    I wouldn't say the quote is garbage, there's truth to the idea that over time we have to worry a little bit less about cleverly dealing with resources, assuming the amount of resources we care about remains static... But of course they don't. The really interesting thing about the quote is that it is from 1986 but could have been stated the same way in 1996, 2006 and likely in 2016 with the same "10 year back" qualifier and nobody would bat an eyelash. Systems are way more powerful but we're also pushing a LOT more data (in terms of depth of the data, breadth of the data, and types of data). To be fair though, these days a lot of people see "spin up 25 more AWS instances" as a perfectly valid way of solving a bottleneck when compared to months of developer time whereas back in 1986 the decision would be a no-brainer in the other direction given that the equivalent of spinning up 25 AWS instances today would be economically infeasible back then for almost any commercial entity (even if you scaled back the amount of processing needed to fit in the context of that era).
  • bottompair 13y ago
    Ironic language given that most "engineers" today can't write code without dependency on built in garbage collectors. Do you really think developers these days are just as good at optimizing for limited system resources as they were in 1986? "We still run into..." Who? Maybe you - but most developers aren't running into map/reduce problems every day. And when they do, they certainly aren't coding a solution from scratch.
    • boomzilla 13y ago
      I think what really happens is that programmer/software engineer profession have become a lot more accessible to the mass. Back in billg days when he started programming, I would bet less than 1000 kids around the country had access to a computer. In 1986, the total number of programmers would've surely been less than 10,000 and most of them worked for MS, IBM, DEC, etc. In the current time, half of SF are software engineers and entrepreneurs :) I guess my point is there are still a lot of people who work on the hard core stuff like Linux/Windows kernels where every byte counts, or JVM/LLVM where data structures/algorithms are rewritten over and over to get a bit more performance. I would say the number of programmers who have to care about the optimizing system resources may be even more than back then, it's just that there are a lot more application developers these days.
• Haul4ss 13y ago
  I like the idea of a code comprehension test. I would give the code to the candidate 1-2 days before the interview, and let them ponder it. I know, technically they can cheat and google API calls or show it to their friends, but I bet with a little prying in the interview you could uncover that.
  • mkartic 13y ago
    In this context, taking help shouldn't be considered cheating. Its better that s/he looks up the API calls. It wouldn't be a comprehension test if all that is required is knowing a few API calls. Isn't the whole point of the exercise to see if the candidate can get past the API calls and understand the big picture?
• 72deluxe 13y ago
  I thought the irony of that was the masses of RAM that the .NET runtime consumes? Or am I missing that? Every time I opened Management Studio for SQL Server 2005+, it took forever and caused massive disk churning, compared to the Win32 version for SQL Server 2000 and before, which didn't engage in abstract disk churn and memory gobbling.
  • bad_user 13y ago
    Is that really a function of the app being written on top of .NET? It could be, but most often than not, that's due to poor architectural decisions. Pointing fingers without knowing the internal details isn't constructive criticism.
    • tanzam75 13y ago
      .NET applications should not just churn at random. There needs to be real memory pressure (was there?). I wonder if something went wrong with the native image generation during setup? It may be trying to JIT it every time on startup. That could be quite slow and result in a lot of disk activity.
  • kyberias 13y ago
    Is Management Studio 2005+ written on .NET? Any reference on that?
    • 72deluxe 13y ago
      As far as I new it was. You noticed the flickering views and new-style GUI controls, eg. looking at the properties of a server caused massive update flicker, common to .NET controls (early versions only?)
• bitwize 13y ago
  But the flip side of that is that optimizations that were made when resources were tight may bite you in the ass when resources become available. For example, the declaration for the WinMain entry point that still persists to this very day in Win32 and Win64 applications looks like this: int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpszCmdLine, int nCmdShow); Note the hInstance and hPrevInstance bits. Back in the day Windows loaded the code for a Windows application's .EXE once into memory and then maintain several pointers to a separate data section for each running instance of the application. The hInstance and hPrevInstance are actually pointers to such datasections. One of the reasons for this was so that the program needed to only do certain kinds of initialization once; if future instances needed that data, they could copy it into themselves from the previous instance (remember, no protected memory!) with the GetInstanceData function. In addition, it was a simple way of telling if you were already running; window classes, for instance, were registered once per program, not once per instance. Of course in Win32, instances of a program are their own processes with their own address spaces, so you can't do the kinds of clever tricks you could in Win16 to save time and memory. And hPrevInstance is always NULL. Win16 programming is full of hacks like this that made sense in their day, but are counterproductive now, though their vestiges remain on in Win32.
• anthuswilliams 13y ago
  In 2013 I briefly contracted for a PHP shop. The hiring manager would invite people in for an interview and present them with the following code: mysql_query(' INSERT INTO `products` (`name`, `descriptions`, `price`) VALUES ( '.$_GET["name"].', '.$_GET["description"].', '.$_GET["price"].'); '); Then he would ask, "how do you feel about that?" He claimed this question weeded out a lot of potential candidates.
  • tanzam75 13y ago
    I like it. I don't know if you can use this kind of test on fresh-out-of-college hires, because a lot of professors don't teach security, and there may be plenty of other bad habits to break anyway. But on any experienced hire -- even someone one year out of school -- it's perfect for screening out the codemonkeys.