30 km/h and even 50 km/h are respected pretty much nowhere except where there are stationary traffic cameras. I ran across an article recently (can't seem to find it again) where 90% of German drivers voluntarily admitted to not keeping to the speed limit.
For most people, breaking the speed limit does not seem a big deal. Then they run over a kid and say "I didn't mean to do that"! Well, they did in a way - keeping to the speed limit is not hard.
I'm responsible for hiring developers at our company based in Berlin, Germany, and found it best to have a guided interview about the candidate's work experience and interesting problems that she/he solved. I never understood the whiteboard hazing/CS trivia that are so widely discussed on HN since it seems extremely disconnected from the actual work that's being done.
That said, I'm always surprised how many candidates cannot even point to one problem they worked on they found interesting or one solution that they're proud of.
We worked with an HR consultant to develop a interview guide in the form of certain questions that we make sure to hit during the interview in order to be able to compare between candidates and make an informed decision.
However, we're small and not in the US. Anyone have experience with other companies in Germany/Europe? How does the typical interview work over here?
> That said, I'm always surprised how many candidates cannot even point to one problem they worked on they found interesting or one solution that they're proud of.
It could be that this technique favors people good at telling stories.
Personally, I'm a horrible storyteller. If you were to ask me what I did over the weekend, I'll offer some facts like "oh, went swimming in a river and Bob lost his hat, but we found it later. The water was nice." Whereas Bob could easily regale you with stories about the epic hunt for his hat and throw in a punchline in the end.
If I didn't know that you'd be asking for solutions I'm proud of, I might draw a blank at that moment. Granted it's an interview setting and these are the questions one needs to prepare for. But if given the choice between speaking about myself or whiteboarding, I'll take the whiteboard.
I've always preferred math over history for that matter. It's easier for some of us to apply processes than to recite chronologies.
> > That said, I'm always surprised how many candidates cannot even point to one problem they worked on they found interesting or one solution that they're proud of.
> It could be that this technique favors people good at telling stories.
Or people who think they're impressive. I know I would've been able to point out many problems and solutions I found interesting and were impressed with when I was 15. Today, not so much. The more I know, the less impressed I am with myself, and more and more stuff just feels "routine" and nothing special.
I'm not a "look at me!" kind of person, but here's what has really helped me with these kinds of interviews.
Keep a daily journal of what you work on. Nothing fancy, just stop by once a day religiously and add a few notes on what you did, what meetings you attended, who you spoke with, etc...
Save your evaluations and especially any award packages you or your team might get submitted for. At least where I work both are your supervisor's attempt to make you look as good as possible.
Then, when you're job hunting review your notes and bullets and collect the ones that sound the best and perhaps ones that have numbers assigned to them (size, savings, productivity, etc..)
Preferably you'd memorize these few stories about yourself, but if you must you could also bring a notebook with prompts to remind you.
My grandfather used to do this. He had notebooks filled with what he did every day of his career. It's really cool to be able to go back and look through his notebooks and see what he was doing in April of 1971.
My notetaking is not as rigorous as my Grandfathers, but I do something similar. Every month I make a new manilla folder with the month and year on the tab. Each week I write down every project I'm working on and every meeting I have. If someone brings me a new project I put it on the sheet. Every note I take a meetings and during projects goes in that folder.
At the end of each week I go through the notes from that week and write down anything interesting on that week's note sheet. At the end of the month I go through all the notes and write what I accomplished on the front of each manila folder.
It makes it really easy to keep track of everything you've done, without consciously keeping a journal in the moment. It's also a really easy organizational system. When someone asks, "What did we do for [x] in the past", all I need to do is flip through my folders looking at the front for anything that rings a bell, rather than trying to keep up with a tagged organizational system.
This probably doesn't work if you don't have a file cabinet though.
If someone brought along an notebook full of problems they'd experienced and how they'd solved them to an interview I was conducting I would be very impressed!
This is great advice, thanks. In the past six months, I've been better about keeping notes. Not specifically for this, but this is definitely another benefit of journaling.
At this point in my career I'd have to say I agree. Many of my team are at the start of their careers. I find it really interesting the number of times they seem impressed by something I did that I'm just "meh" about.
Oddly enough, the opposite is true as well. I'm constantly impressed at the level of ability they have at this point in their career as compared to my ability at the same point in my career. They just simply know more. Of course, there's more to know these days but still, I find it impressive.
Good point. When I notice that people are struggling with finding something, I usually just pick one thing from the resume and try to go more in depth about that.
> If I didn't know that you'd be asking for solutions I'm proud of, I might draw a blank at that moment. Granted it's an interview setting and these are the questions one needs to prepare for.
The key word there is "prepare". These are standard interview questions that you just have to have a prepared, rehearsed answer for that you can rattle off without thinking. There are tons of these types of "behavioral" questions. Tell me about a project that you worked on that failed. Tell me about a time you had to deal with team conflict. Talk about a struggling project that you had to help turn around. You can get a book full of them. Be ready with canned answers for as many as you can and practice them in front of a mirror.
Yup, whiteboarding and reciting tried and true stories are inevitable routines when interviewing. However, you'd also be surprised at how many people don't know how to prepare for this. My main concern would be the possibility of turning a great candidate down just because they didn't happen to interview well.
> My main concern would be the possibility of turning a great candidate down just because they didn't happen to interview well.
Too bad (for candidates) that that concern doesn't appear to be shared by... well almost everyone in tech hiring these days. The general wisdom of the day seems to be "it's better to eliminate 100 false negatives than hire one false positive."
Probably because it's "easier to hire than to fire".
I worked with some really great folks that had trouble getting hired and it was because of the flawed interview process. One person writes concise and clear Rails code that's easy to read, and makes some of the wittiest comments on Slack (subtle puns that go unrealised for two minutes, then you finally get it and makes you smile). But he stutters a bit. And because of that, interviews are difficult for him. Which is a real pity, because in less judgmental situations, no one would think twice about that.
(Don't worry there's a happy ending and he's now at a good company.)
I learned after my first university job fair the necessity of being more outgoing during these situations, but there's great engineers out there who still live by the myth of "they'll know me by my work".
I think many will be able to tell the story if it is a story about something they care a lot about.
Also, there is an opinion that good developers are good communicators.
Companies differ, and what they are asking of software engineers.
I was working with a brilliant guy in the same company. He was very technical and you could say that easily he was programming all day long non stop. His intelligence and technical expertise amazed me. Thing is he wasn't good with people skills, hence he wouldn't fit the company I am currently working for.
There are companies that hire devs to solve a problem and give them time, space etc to go all hardcore.
Then again there are companies that require from their dev's to be able to communicate with the rest of the team, and take part on meaningful theory-crafting meetings.
So neither whiteboarding, nor tell me a story question is wrong.
I just find it that whiteboarding difficult questions should be asked from the very technical jobs, and I've found whiteboarding difficult questions when interviewing for a company that wants to move out of wordpress to their own website in angular.
I'm not sure why there is such extreme hate for the whiteboard. Yes it has plenty of caveats when it comes to actual coding and recruiters should not expect any candidate to write precise code on that medium.
I do use the whiteboard for trivial CS questions limited to 5-10 minutes. Think fizzbuzz and string reversal. Candidates have the option to use my laptop (not ideal because the keyboard has a US layout) but they are welcome to use their own computer as well (if they thought about bringing it). It weeds out candidates who can't even produce basic code. And yes, a candidate with 2+ years of experience should be able to write a basic function on a whiteboard, a napkin, or whatever. If not, the interview is not lost but the candidate will have to prove his skills another way.
For most candidates, we also give a longer technical test which is to be done at home and takes 2 to 4 hours to complete. Candidates are given as many days as they want to complete it.
Whiteboard is an excellent medium however when discussing architecture and higher level ideas. It's also a tool that I've used during day to day activities with colleagues. Software based tools don't come even close.
I believe the hate comes from unprecedented and hard CS questions asked on the whiteboard.
I recently went to an interview that asked me to balance a binary tree on a whiteboard. It can be done, and I can do it. Thing is when you go to interview for that company that has 2 developers(small team, small company) and ask you that kind of question it puts you off thinking that those guys won't be great to work with (arrogance etc comes in mind).
I am fond of simpler questions, like you said fizzbuz etc. Obviously if you are interviewing a guy that has 2+ years of experience, he has to be able to pass the fizzbuzz test.
When you are interviewing someone with 5+ years of experience for a higher up position I guess you do have to ask some harder question, but I personally think just speaking to the guy and asking him stuff about his past projects etc will give you a hint on if he has the skills he is talking about or not. Asking him to outline a hard task he took part and how he solved it is an amazing start. As a 5+ years guy personally would rumble about a few things and it would take me days talking about them. (That will give you an understanding if I've worked before or not on the things outlined on my CV).
I've been coding for about 25 years. The last time I had to write any code related to binary trees was in school, 15-16 years ago.
Given enough time and debugging I'm sure I could do it. I'm not going to be successful on a whiteboard though. If I actually had to do it I'd look it up instead of wasting my time figuring it out.
Unless you're interviewing for a position where they'll have to implement binary trees you shouldn't be wasting time asking about code for them. Questions should be relevant to the position.
Additionally: Nine times out of ten, you shouldn't be implementing the binary tree in the first place. There are already tons of tested, robust libraries out there that will do it a lot better than you can, handling all conceivable edge cases, available in a variety of license flavors. Many languages' standard libraries include support for binary trees.
You want candidates who can work through the buy-vs-build tradeoffs.
Reminds me of when I was asked to implement a filesystem API in C or C++ with file manipulation and path parsing and whatnot. The best answer I can think of is usually "With no weird constraints given (is this an embedded system, for example?) just use boost::filesystem and move on with your life." Not impressed with this answer, the interviewer would continue with "assume you can't use Boost!" Next answer is: "There are a variety of filesystem abstractions already written, far better than I could whiteboard. I'd go through each one and pick the one most suitable to the project." I thought it was a trick question at first. You really DO NOT want candidates who hear that question and launch into writing code!!
It's obvious that they're not going to use the code you wrote at an interview in production. So "just use a library" is not a relevant answer. The question was probably posed to give you an interesting engineering challenge to work through with the interviewer so that they could see your problem solving process. Instead you just argued with the interviewer.
The GP's point (which I supported) is that it's a waste of time to take a candidate through scenarios that are not at least similar to what they'd actually encounter doing the actual job.
But the point is that if you cant do something so simple, like traverse a tree, then you probably don't understand how trees work to begin with.
Similarly, I've never had to implement fizz buzz for real, actual, work. But I wouldn't trust a programmer who was incapable of doing fizz buzz without importing a fizz buzz library.
But the earlier comment wasn't talking about _traversing_ a tree, it was talking about _balancing_ it, which is a much harder problem and one I wouldn't want to do without google either.
This can also be an education problem. There can be big mismatches in what is easy and hard
If you're coming from a more FP background things like flipping a binary tree are silly obvious. If you spend a lot of time with C++, of course you know how to write a linked list with memory management. Python devs are probably way better at slicing and dicing data
There's a certain expectation of what's easy and hard, but it's really easy to have a mismatch given the diversity of education out there.
It's also that coders tend to... err... "offload" memory for the stuff they aren't immediately using on a daily basis, and only remember the general terms and names that would be enough to find and remember the details shall they be required.
Last time I've had to do something with the trees implementation details (IIRC, that was AVL trees) was, like, 5 years ago. Right now, I don't exactly remember anything about AVL trees except for they have that nice O(log n) for lookups, insertions and deletions. Would I need to code them from scratch (or remember their internal workings for any other reason, like debugging some core dump), I'd go find the algorithm description (or particular implementation's source) and do so.
At the same time, last time I've worked with balanced trees was just a few days ago, but that was Erlang's `gb_trees` module that did all the stuff and I just had to freshen my memory on the syntax details.
All I would be able to do on a whiteboard is stare for a minute, trying to remember stuff, then probably say "uh, sorry, I don't remember this stuff - haven't did that in a long while". Yes, that makes me a worse programmer, I guess, but are interviewers actually looking for those who remember everything in their head and write code on whiteboard? Looks like a weird case to me that doesn't have to do anything with reality.
It took me 5 minutes on my laptop at home to code out a problem that I danced around for an hour on a whiteboard being stared down at by 2 engineers in silence. Yes, I had the benefit of hindsight, but unless you've actually done a whiteboard interview yourself where your livelihood is on the line for an hour, don't act like a trivialising nonce.
> I do use the whiteboard for trivial CS questions limited to 5-10 minutes. Think fizzbuzz and string reversal.
Why do people keep saying string reversal is easy? Text is one of the hardest things out there. Unless you expect your programmers to support ASCII only?
Why not reverse a list or an array? That does sound like something that is doable in 5-10 minutes.
This is why I like the question. As an interviewer, I will leave that matter open and see if the candidate asks for clarification. If so, bonus! But I will tell them to just
solve for ASCII.
The worst-case scenario is a "self-hazing" where someone
sees the encoding difficulties and freezes up instead of
asking for clarification. I've never seen that happen
though, in my experience though, everyone -- even the good ones -- just assume ASCII.
Thank you. A great response to "reverse a string" is "What's the encoding?" If it's anything but ASCII, you're in for a long white boarding session. If the interviewer doesn't know what you're talking about, back away slowly......
what makes other encodings hard ? The two things that come to my mind are byte length and comparison function. If the encoding had a fixed-length byte length, then it should be just swapping n-bytes at a time instead of 1-byte. What else is difficult about non-ascii encodings ?
e.g. in UTF-8 a codepoint is encoded in varying byte lengths (so you have to split into codepoints and then reverse), and, a lot more difficult, a sequence of multiple codepoints can be combined to form a symbol. Simplest case would be something like "ö" encoded as "o" (U+006F) followed by a combining diaeresis (U+0308).
Other fun special cases: 🇺🇸 is U+1F1FA REGIONAL INDICATOR SYMBOL LETTER U, followed by U+1F1F8 REGIONAL INDICATOR SYMBOL LETTER S and should if possible be displayed as a US flag (otherwise falls back to text "US"), should reversing it create 🇸🇺 (replacing the flag with the characters "SU"), or still show the flag? (I'm not even sure if there isn't a case where both are valid country codes and it would change to a different flag?)
Similarly, Emoji can be formed from a sequence with combining characters inbetween, which don't display correctly if reversed codepoint by codepoint.
Some examples: If you're dealing with UTF-8, which is very common, you need to handle variable-length characters. If you're working with UTF-16 you need to handle surrogate pairs. Neither are the end of the world, but the basic "array walking" string reversal methods you'd expect from a white boarding session wouldn't work.
Well, OK, if you are using C or something, and traversing through binary it is hard.
But if you are in python, and given a string object, and told to reverse it without using the reverse method.... Yeah, that's easy. You should be able to do that.
What is the field you hire coders for? Because for the mine (iOS) your ability to code fizzbuzz have little relevance. The knowledge of APIs, common patterns, ObjC vs. Swift, common means to handle dependencies, etc. etc. is impossible(?) to fake if you do not have relevant experience you claim you do.
Sure but if you cant program fizz buzz, that means you don't know what an if statement is.
Fizz buzz tests for "does this person know what a function is, what an if statement is, and the modulo operator". And frankly, I'd give the modulo answer away for free if the candidate asked.
All programmers should know what a function and an if statement is.
As an iOS developer, I would still get whiteboard questions ranging from "reverse this string" to "find all the anagrams in this array and print them in this specific fashion", usually with iOS specific trivia about view controller lifecycle, UIKit (whats the diff between frame and bound?), etc. sometime before or after the whiteboarding
Interesting! I actually love using the whiteboard to sketch solutions and architectural decisions. I believe the hate comes from having to code on a whiteboard - which is justified, since no one ever coded on a whiteboard except in an interview.
Also from Europe, and we have a similar approach, discussion with the candidate about previous work, interesting problems, any public code they've written, etc. Just to figure out what kind of challenges excite them, and get to know them better.
We also do a coding challenge after that, basically the candidate behind a computer, with all the resources they want accessible to them, implementing a simple example directly relevant to the type of work they'll be doing, while the interviewers are in the room and debate with them if needed.
To me, the most important quality in a candidate, once we determine that the basic skill level is good enough, is their ability to learn, quickly find the resources needed, and rely on the team when they need help. Whiteboard interviews don't seem to select for any of those qualities.
> found it best to have a guided interview about the candidate's work experience and interesting problems that she/he solved.
This. I advocate this method of interviewing here in the states every chance I get. The most common form of push back I get is from hiring managers terrified of being hoodwinked into making a bad hire. It's like they don't trust their own judgement enough to be able to tell apart those who know what they're talking about from those who just talk a good game.
> I'm always surprised how many candidates cannot even point to one problem they worked on they found interesting or one solution that they're proud of
Junior engineers, I assume? I had problems with those questions when I first started out. It's hard to say with a straight face that the thing I was most proud of at that point in my career was creating a very simple templating system in PHP. Of course, the interviewers rolling their eyes and saying 'is that all?' didn't help.
> It's like they don't trust their own judgement enough to be able to tell apart those who know what they're talking about from those who just talk a good game.
Which is usually the case in larger companies, I assume. The person doing the hiring in that case is far removed from the people and work actually connected with the candidate.
> Junior engineers, I assume?
You're right, that's surely part of it. Not only, however - sometimes you get the feeling that work is something that happens to people, not something they seek out and try to get better at. Which for many positions is completely fine.
Generally speaking, someone's ability to recall things is very dependent on how they're feeling. If you're happy, it's easy to recall positive things, if you're depressed it's practically impossible.
A lot of developers also have imposter syndrome. After I've solved an interesting problem, within a few days i'll probably have dismissed it as not being a big deal and started to forget about it.
These kind of questions are useful, but candidates should be preparing their talking points, because the risk of forgetting the story that's going to get you hired is too high
Yes. I read about this idea a few years ago (tell a story about a project you liked) so I had to make an effort to focus on ONE story and tell it well. I've been doing it a couple dozen times so far (I'm a contractor who likes small projects, six months is starting to get too long) and I've had significant success with it.
(When I think about the problem "objectively", all I did was use SSDT to simplify deploying database changes from QA to production without having to shut down either. No big deal. However, it was something that the company had been doing manually for years, spending three error-prone days each month, and they were extremely happy with my solution.)
So true.. and this is a great interviewing technique. I basically ask one question during an interview: what was the hardest problem you ever had to solve? It may sound stupid at first glance, but it gives you insight into not only the breadth of their technical knowledge (since that problem may not be germane to the position you're hiring for), but also the depth of their abilities. The way they answer this question reveals quite a bit about the person. Not only technical, but also their interpersonal abilities.. how they manage their place on a team, how they manage expectations up and below, etc. I can glean quite a bit about the person based on how they answer this one question. Only asking questions about your particular domain doesn't necessarily indicate how good they'll be at solving those types of problems, only how much they happen to know about them. Of course, you can say that perhaps they shouldn't be interviewing for a position they may not be qualified for, but frankly the best people I've ever hired had very little experience in problem sets that were specific to my day-to-day responsibilities, but delving into details about things that they've done told me a great deal about how they solve anything. It may not be the best way to hire, because it requires a breadth of technical knowledge of the interviewer, but it definitely has worked for me. Asking someone to solve a ridiculous puzzle on a whiteboard..when they're obviously nervous about being there in the first place seems kind of dumb to me. However, digging into a problem that they've solved immediately puts them at ease.
I'm not a huge fan of this question. I've been programming for 20 years (professionally for 13). Is the hardest problem some noddy maths i worked out at 15 to convert real coordinates to screen coordinates? Is it the first app i wrote out of college when i learned that servlets aren't thread safe? Is it what i worked on last year to design my current company's authentication/authorization system?
I find it very hard to interpolate between these examples. And none of them are "hard"! I haven't written an OS or a more efficient linked list. All I've done is plugged away at something until it works.
"found it best to have a guided interview about the candidate's work experience and interesting problems that she/he solved. "
When I've been job hunting in the past I've also found that these have been the best situations for me. I find coding questions beyond fizbuzz totally silly and when something more is requested of me my attitude shows this.
We are currently hiring. Denmark. We received i think few hundreds applications, picked 20, discussed internally, picked 5. Those 5 received invitation for homework, simple functional Javascript exercise. We dropped 2, the rest received invitation for UI Javascript exercise, vanilla btw. Then we talked with them. Picked one. In my previous gig in UK we had 3 homeworks and then chat. Sometimes we did drop the third when candidate was exceptional. So far only one candidate refused homework next stage, but the first stage result was bad enough for us to not consider him anyway. All top candidates and hires were eager to do the homework.
Interesting. I've done a fair number of interviews for my last few companies, and while I've found that whiteboarding isn't terribly useful, likewise I've found that I really do need people to do some coding. I've definitely encountered people that talk a great story but don't have the chops behind a keyboard.
My usual process (which isn't to say it's perfect, but it's a process I regularly edit to address problems I see) is to give a few, simple problems, and have them actually code it on a system.
* I know that the computer and environment are unfamiliar to you, so I expect there to be chopiness and typos
* I know that most people are nervous during interviews, so I don't fail people if they freeze on one of the questions or miss a concept
* I don't give "trivia" questions - the problems tend to be fairly easy ones that cover your ability to approach basic problems. Example: "here is a nested data structure (like an array of objects). Write a method to pull these sorts of elements out."
* I'm actually hoping you'll screw up - I'm far more interested in seeing how you deal with a bug than if you can dash out an algorithm flawlessly. Nonetheless, I keep the questions simple because I want to minimize the impact of nervousness
* I inform people they are absolutely allowed to use Google, StackOverflow, etc - I'm trying to mimic the actual work experience as much as I can. I WILL judge people on their searches, but I'm pretty loose - I can only recall one person that I dinged for searching, and that's because they went to about.com and copied the answer there without trying to understand it (and it subsequently didn't work). Usually this ends up GIVING people points, because if they demonstrate comfort with finding solutions, I expect that we can hire them and know they'll improve over time.
Despite this, I still ask a few questions that are purely verbal. I want to see if you are someone that will force your preferences on others or are willing to bend. (I'm not looking for a doormat, but I've never met one, so that's a bit moot) I want to see that you are continuing to learn things, because the skills you have now will just not be the skills we need in a year or two.
but overall - I have to judge candidates based on the limited info I can glean in an interview. Of:
* resume
* whiteboarding skills
* discussion skills
* coding skills
...I find the latter to be the best measurement of the options, even allowing that it won't be fully accurate.
Hi JonasVP, a little late but regarding your original question...
We were building a tech team at a start-up in Germany.
Our hiring process evolved and stabilized into the following process, which worked exceptionally well for us:
1. Review of written documents, accepting any kind, any style and any medium.
2. Telephone interview with recruiter from HR about motivation, personality and the formal aspects of education and experience.
3. Personal interview with VP of engineering. Future employee is asked to bring some of his or her source code to the interview, any language any style any form is good. We don't copy the code, we don't keep it, we don't use it in any way. This is the only technical interview.
4. Interview with the CTO, immediately following. This is the most important social interview, and it also contains the main salary negotiation.
5. Decision.
Between any of the steps, we would briefly exchange our impression of the candidate, and it turned out that it is wise to sleep a night before taking the decision.
My function was VP of engineering and lead architect, and I would conduct the interviews of step 3. My principles are as follows:
- Keep the candidate at ease as much as possible. We want developers to crack hard problems with "feet on the table" as the Dutch say, most of the time. Stress distorts things, and I want to see the undistorted version.
- Get to know the candidate, and what makes him or her tick. This requires respect, tact and genuine interest in the person and his or her achievements.
- Estimate the fit with team and company. I can talk a lot about this---but in the end it either feels right or it does not.
- Gauge the technical capabilities of the candidate. For this I let the candidate choose a piece of the source code at will and have her explain what it does, and why it is the way it is. For all our hires, some form of dialog on software architecture in general emerged. This usually takes between 10-30 minutes.
- Do your best to get the candidate interested in the company. For this I do not advertise the benefits of the company but simply explain what the company does, what the software we create does, which languages and systems we use and maybe even demo some of it live. Also I explain the risks of working for a start-up company to the less experienced candidates.
I don't do programming exams of any kind. Interactive exams exhibit dangerous positive feedback: you start with something in the middle. If the answer is good you make it more difficult. If the answer is bad you make it easier. Repeating this quickly converges to either extreme, which means you missed the chance to learn something more profound about the candidate, and even risk loosing suitable candidates at split-second blackouts. I don't like take-home exams either, although they are all the buzz these days. A take-home exam is a large investment for the candidate, and most of the people I hired never even touched the programming systems we were using (Erlang, Python, Ocaml, GLPK to name few). All hires did exceptionally well after a few weeks, and with a little bit of guidance. So what could a take-home exam tell me? Even worse, take-home exams are supposed to reduce the risk for the company, at the expense of the candidate. But do they actually do that? At what price? In addition, the large German probationary periods provide an easy way to correct mistakes later, which I had to do only twice so far.
> That said, I'm always surprised how many candidates cannot even point to one problem they worked on they found interesting or one solution that they're proud of.
I have trouble recalling the details of things I worked on even say a week ago sometimes. I also don't find most of the work I do that interesting as I've been coding along time solving the same kinds of problems. However to play the game i would of course brush up for questions like that, and be quite convincing.
> I have trouble recalling the details of things I worked on even say a week ago sometimes.
No problem here, it probably wasn't very exciting but have you never encountered something which stuck in your mind? Or that you could at least recall some part of a project if someone asked "So, you've written here that you've worked on project xy and did this and that, can you tell us a bit more about it"?
Asking about project xy is different though, it's more guided. I think it's much easier to answer than the really open ended ones that ask you to pick an incident from all 10-15 years of your work history: the field there is so wide that unless I've specifically considered the question in advance I'm likely to sit there going ummm for a bit.
In general I think the question format favours people with a good memory for anecdotes and story telling ability.
His main work is about reducing the possibility to extract "rents" from society by closing loopholes in our current economic system:
1. Money is "better" than everything else so those holding money can extract surplus value by lending it out. This was later also found out by Keynes and others. Keynes' solution: inflation. Gesell's solution: imposing carrying costs on cash.
2. Land is required by everybody yet impossible to increase. Solution: the goverment is owner of all land yet leases it out long-term by auction. All income is distributed among all mothers, since the price of land is direct consequence of the number of children/people in a country. Now you would distribute it among all citizens and call it "basic income".
His ideas are still completely valid and deserve a wider audience.
> All income is distributed among all mothers, since the price of land is direct consequence of the number of children/people in a country.
Isn't an inherent flaw in this that it encourages people to have as many children as possible?
I'm under the impression that at a point when your population is established you want something like a 1.2 birth rate, or just a little more than enough to cover your unexpected deaths.
Well, that's a tricky argument since at what point is a population "established"?
I concur, however, since I'd prefer it to be distributed among all residents, whether born in that country or not. But that's another discussion entirely.
Thanks for mentioning property tax, one issue that is sadly overlooked in practically every discussion. In Germany there's a small initiative of cities and citizens that aim to restructure property taxes to actually incentive productive use of land: http://www.grundsteuerreform.net/ (unfortunately only in German)
Basically it aims to remove all taxes on buildings and _only_ tax the property it's on, at a rate that is propertional to the value that society (the people living in the city around the property) and the city itself (through infrastructure) provide to the property.
The tax would then strongly encourage productive use of the land instead of speculating with it.
Specifically: my Xtracycle Edgerunner. Beatiful, handles like a normal bicycle but carries my wife and kids and/or groceries like a truck. I'd marry it if I were available.
I suspect the American interpretation of "organic" is much less strict than the European one. Also, there would probably be much less regulation and control of the production process because free market.
Just FYI: Hacker News already shortens links, no need to pass them through a 3rd party service. I personally prefer seeing a readable domain name before clicking (as I'm sure many others do as well).
But then the same question as with other short URLs appears: Does amzn.com really belong to amazon.com, or is it a third-party service that may redirect you somewhere else at will?
The point is, I don't care whether amzn.com really belongs to amazon.com or not. I want to check a domain quickly without having to research that kind of stuff.
Attrs (https://attrs.readthedocs.io/) replaced namedtuple for us (and many others). It's slightly more verbose but allows all class goodness such as methods, attribute validation, etc.
Doesn't work for everything, but you can subclass a namedtuple:
from collections import namedtuple
class Foo(namedtuple("Foo", "a b c")):
@property
def sum(self):
return self.a + self.b + self.c
f = Foo(1,2,3)
print f.sum
When you abstract away test code, you are abstracting code written to test a software application's design, and thus your abstractions (and test data) necessarily mirror your application design.
This is why I commented elsewhere that DRY should be applied not as a coding principle to all code, but as a design principle to software design.
30 km/h and even 50 km/h are respected pretty much nowhere except where there are stationary traffic cameras. I ran across an article recently (can't seem to find it again) where 90% of German drivers voluntarily admitted to not keeping to the speed limit.
For most people, breaking the speed limit does not seem a big deal. Then they run over a kid and say "I didn't mean to do that"! Well, they did in a way - keeping to the speed limit is not hard.