An interview code submission that wasn't even submitted changed our process - <AUTHOR> https://stackoverflow.blog/2020/06/08/how-an-interview-code-submission-that-wasnt-even-submitted-changed-our-process/?cb=1 <comment><USER2> I've been long frustrated about how technical interviewing takes place in our industry (and I've written about it quite a bit as well eg. [https://www.neilwithdata.com/developer- hiring](https://www.neilwithdata.com/developer-hiring))

I think many companies through the hiring process completely lose sight of what they are actually looking for. They forget that the barriers they erected (whether they be whiteboard problems, take-home coding tests, algorithmic dance on your head textbook problems, etc.) are simply signals about the actual person and their capabilities...and usually, they're _exceedingly poor signals_. That's why you end up with situations where extremely accomplished and talented developers don't pass many technical interviews at companies where they would have otherwise gone on to be outstanding employees.

And it keeps happening, and happening, and happening.

Interviewing for a developer role should be far, far, far more holistic than it is today - rather than throwing away my entire history of accomplishments and creations and just assessing me on the spot in a 2hr winner-takes-all high-stakes game of whiteboard/technical trivia.

For example:

* If I have a strong GitHub portfolio of projects I can prove I worked on, that should 100% take priority as a signal as to my capability and how I think about committing regularly, writing clear commit messages, etc.

* If I've built products I can prove I alone built and I can walk you through my code, that should 100% take priority as a signal as to how I write code, my proficiency with a particular language, etc.

* If I communicate clearly over email, have a blog with my writing demonstrating my ability to clearly communicate technical topics, that should 100% take priority as a signal as to how well I communicate.

etc, etc.

Sadly, today, I'd say ~90% of technical interviews completely and utterly ignore all the above and want you to do the technical monkey dance...because clearly, what makes a developer great is grinding leetcode for 3 months and then pretending you haven't seen the problems before during the interview.

<comment><USER3> So here's a counter perspective: there is no good way to interview, there are just less bad ways, which depends on your company.

The worst filter is choosing at random. If I shuffle a stack of resumes and throw half in the trash, I have eliminated the unlucky candidates. I have certainly rejected a good number of skilled and highly qualified candidates. Regardless the filter did its job, I have fewer applications to review.

If I give candidates whiteboard problems, I filtered out thoughtful people who don't perform well under pressure. If I look at interviewees github submission and blog posts I have filtered out intelligent people with a dearth of free time. If I combine the two filters with an OR relationship, I now let more people through and have a filter that is less effective at narrowing down candidates.

All filters filter out good candidates. Anyone who finds a way to find exactly the right candidates from a filter in a way that isn't bespoke and is scalable is going to be very successful.

<comment><USER4> It's amazing to me that, in all the discussions and articles on HN that I've read about interviewing, no one ever mentions coupling their favorite filters with gut instinct.

Not everything has to be measurable to make good decisions.

<comment><USER5> but everything has to be measured to quantify if the decision was good or not.

You trust your gut when you have no other option, not because you believe it to be better than a data driven approach

<comment><USER4> > but everything has to be measured to quantify if the decision was good or > not.

Do you measure your romantic relationships or marriage or family interactions? Do you measure any human relationship?Because hiring and working with someone with fundamentally a relationship, not a data science or math problem.

I had a manager once who said, "if it can't be measured, it can't be managed." You sound like him. Good luck with that approach, and i hope we don't work together :)

<comment><USER5> You just measured our relationship based on a single comment. So yes, I along with everyone else measures relationships based on data.

</comment></comment></comment></comment></comment></comment><comment><USER6> Coding tests should be abolished.

There's almost never any science or systematic approach to evaluation.

How can you possibly evaluate a test without predefined criteria for evaluating that makes the result good and what makes it bad?

Whether or not the code is "good" is simply a matter of opinion in almost all cases.

Another down side to coding tests is that if the assessor knows less than you about some area of coding and sees something they don't recognise or understand, then they might well negatively view what in fact is a much better way of doing things.

And, much worse than anything else, you have a very tangible chance of spending 12 hours doing it and hearing nothing back at all.

And as for "Tic Tac Toe" as ANY sort of effective test topic, well, that's where you should pull out and find a different job to apply for, where they can at least formulate a _relevant_ test topic and come up with tangible and defined criteria for measurement as well as a commitment from their end as to who will assess it, against what criteria and within what time frame and what feedback they will give you, if any. Ditch the Tic Tac Toe companies.

I did two coding tests in recent years ... in one, their feedback was "they didn't like it", and the other one I worked on for 12 hours because I believe in doing a good job and meeting the requirements, and I heard nothing at all back - not a single word.

Coding tests are, for the most part, bullshit.

<comment><USER7> > you have a very tangible chance of spending 12 hours doing it and hearing > nothing back at all

...which is so very frustrating. It's painful to read things like this:

> That was all we asked; we intentionally left it open-ended. Some people > tried to impress us with huge, elaborate apps that used different services > and engines.

The people hiring viewed this as a trivial, small, meaningless ask. They are proud to have "intentionally left it open-ended."

Some potential candidates did not (through their own example) view this as trivial, they went ahead and poured a ton of time into it and most likely were "replied with well wishes" as the company moved on.

It's irresponsible.

<comment><USER8> Yes, companies need to be up front about roughly how much time they expect candidates to spend.

That said, if a candidate spends 12 hours or 10,000 lines coding up tic-tac- toe, the company is not entirely to blame here...

<comment><USER7> > the company is not entirely to blame here...

I clearly hear what you're saying, and I understand your stance on it. But I can't agree with it.

The burden is on the folks hiring in my opinion.

This is not a "real life" scenario. It should be a SHORT assesment (for both parties). If you were employed within a company as an engineer and you received a nebulus spec (or no spec at all), the burden is then on you to identify, educate, and communicate.

Not during a pre-interview (for the chance and maybe being blessed enough to get a full interview with this world changing company).

<comment><USER8> Your line of argumentation seems to argue the opposite: since it's the candidate who's the prospective engineer, wouldn't that imply that it's _their_ job to clarify the nebulous spec?

FWIW, many of the FAANGs are famous for asking intentionally underspecified questions, and the candidate preparing properly by figuring out what's in scope and what's not is part of the scoring. But at least in an interview you're timeboxed to 45 or 60 minutes!

<comment><USER9> > wouldn't that imply that it's their job to clarify the nebulous spec?

Maybe, except when you try to clarify and their answer is that it's open-ended -- and yet they want something super specific in the end. And the super specific things are just one of many tech opinions and not objectively good design.

> FWIW, many of the FAANGs are famous for asking intentionally underspecified > questions, and the candidate preparing properly by figuring out what's in > scope and what's not is part of the scoring.

Why is this a good thing though? Why is solving riddles in a professional interview somehow ok?

</comment></comment></comment></comment></comment></comment><comment> P-ala-din I don't understand why people hate to be tested objectively.

\- The task was to implement a basic tic tac toe AI (with open book !!!)

the state space is so small that anything would work fast enough in a modern computer.

\- Some candidates somehow manage to build a program that loses?? that is, it's buggy and they failed to test it.

\- The interviewer uses subjective criteria that somehow results in broken code being accepted unanimously.

\- Some people overengineered their solutions and this is called impressive.

\- Someone failed to implement the exercise, wrote an answer that can be googled in a couple of seconds. Made an irrelevant comment about "min-max" vs "negmax" ( performance is not a concern (small state space) and negmax's main advantage is being DRY).

Made a comment about "test bloat" despite empirical evidence from the submissions showing that there was under testing.

and the conclusion that I am supposed to have is that interviewing without code is better? a worth-mentioning portion of the candidates couldn't ship a working implementation of a standard algorithm and the conclusion is less code??

To be honest tic tac toe is a bad task to choose. it's trivial, easily googlable, and has little room for skill expression. It's also doesn't test the candidates' ability to choose the correct algorithm for the task. and it fails to probe daily aspects of dev work ( concurrency, networking, databases ..) that traditional onsite interviews are less able to test.

<comment><USER9> Because it's not objective?

Everyone seems to have very different opinions of what good or bad code looks like, what's overengineered and what isn't.

Why is the problem even asking for AI? are they applying for an AI position?

And why is it ok to ask people to work for free on a coding project? From what I've seen, people generally ask for pretty high rates to do consulting, with good reason.

</comment></comment><comment><USER10> Hiring in our industry can learn a lot from education. Everything the author wrote boils down to fundamental questions that teachers at all levels have to deal with on a daily basis - how do I assess this student? Either in the moment, on a test, through their assignments, etc. Teachers are constantly in a struggle to figure out where a student is and if they are making progress towards what they wish to impart to them.

Technical interviews are very similar, only smaller scoped. The goal is to use the right tests to learn what you need to know about a candidate. A lot of this boils down to having a rubric - what qualities are you looking for in a candidate that makes them a good fit for your team? If you cannot answer this, then your interview process is going to produce poor signals.

This also leads into another pet peeve of mine when dealing with technical interviews - the ghosting and lack of feedback. If you are unable to give generic feedback on why a technical assessment did not pass (not the cultural), that is a strong signal that you don't know what you are looking for as a baseline in candidates. There is nothing wrong with generic feedback along the lines of "relative to other candidates, your commit messages and code style was lacking." It is especially frustrating when the company invites you to apply again in the future. That's like failing a project in school, but the teacher is giving you a second chance with the only feedback being, "better luck next time."

</comment><comment><USER11> > There are now many avenues to see how people develop that don't require them > spending a whole night coding for just a chance at an interview.

About two months ago I walked away from a pre-interview coding challenge that looked like it was going to take 8-12 hours. The problem was too many requirements.

The same job was posted in last week's "Who's hiring" thread. In this economy, if you can't hire, the problem isn't the candidates. It's you!

<comment><USER12> Sounds like Datadog's interview process.

<comment><USER11> I'd say it was a case of poor empathy. I gave feedback to the hiring manager but he didn't budge.

If I was working with a recruiter I would have been a lot more blunt.

Edit: if I see the same job posting in another "Who's hiring" I might reach out again... If I'm still looking for a job!

</comment></comment></comment><comment><USER13> This entire post is why I quit the interview circuit as a person with ample prior relevant work experience.

This gaslighting bullshit has to go. People are given vague and contradictory guidelines for the chance at an interview.

"Well we really like the UI and it passed all unit tests and didn't crash and wouldn't crash and follows typical MVC practices, but we didn't like the system design, and for this particular position we score heavily on system design even though the requirements said not to prematurely optimize and not to spend more than 4 hours on it"

 _But I thought it was scored by a double blind committee so what exactly are other candidates doing from scratch in 4 hours--- oh..... they 're just like me but recycling code from other similar interviews two months ago and adding to it until they get a $500k compensation package_

This is still happening.

<comment><USER7> > This entire post is why I quit the interview circuit as a person with ample > prior relevant work experience.

It is really bad. Removing yourself from it is probably a very healthy choice.

There's so much folklore, cult of personality, etc. behind all of this.

Hiring is REALLY hard. So exec's order a ramp up of head count. It falls on to managers to start the process. They either don't want to do it (why would they want to?), or they don't know how to do it...they are not technical, or technical enough, they don't have "hiring" skills, etc...

So the burden is typically dumped onto the rank & file "senior engineers" to do the dirty work. They don't know how to hire either. They don't like doing things in a "manual" way. Easy solution! Give them a coding test!

<comment><USER14> > Easy solution! Give them a coding test!

(this is tangentially related to the above fine comment :) I believe it went more like this.. The first time I saw this style of test, it was an engineering hiring group from Microsoft, testing for advanced math skills for some audio work in collaboration (?) with Apple. It was onsite at Apple (a long time ago). The first thing the interviewer said is "we want you to solve this problem right now" .. I said, I have a lot of code examples ready that are representative of my best work, and he was pushy and slightly nervous, and said "no we do not want to see that, this is the problem" .. I agreed, and I believe I did solve it awkwardly, but they refused to look at anything except the in-person test for that interview. It really surprised me, as at that time, I had never heard of this way of doing things. There was no whiteboard, it was a desk.

Sometime later, I believe Google famously used this testing method, on people from The Five university programs, of course. Google probably spun it more like a grad school situation, but I do not know that. Later, every EXEC wanted to copy Google, or wanted to learn bullying like Microsoft.

It is so obvious to me that this sort of test is partially a command-and- control exercise, giving the control role to the hiring group. Please recall there was/is a real tug-of-war between excellent engineers and companies at various points in the recent past.

<comment><USER7> You pulled out one small statement and ran with it. The problem is it's out of context with the rest of what I said. Also, there is far more history than what you just outlined which falls into "folklore" and "cult of personality."

You're statements alone have great truth to them, I'm just not clear how it differs from mine and why it's a rebuttal to them. Oh-well :-)

<comment><USER7> This reply makes far less sense now that mistrial9 edited/updated their original statement without attributing that fact :-\ It's been toned down for sure.

</comment></comment></comment></comment></comment><comment><USER15> Slightly off topic.

What is this deal about commit small and often?

I usually work on problems that requires a lot of thought, a lot of back and forth between solutions, a lot of a reach this state where stuff kinda work but it is not what I need yet and I am not sure it is gonna be in the final version.

Eventually I reach the final version and I commit all together, but the commit is rather big.

Do you guys come back and fix everything after? Like re-code the solution from scratch committing at the right moment. Do you just add pieces related from the final version in multiple small commits? And how do you make sure that each commit is correct? Do you re-run the test suite after each commit? While developing?

I must say that in smaller and simpler codebase than the one I usually work with it might be possible. But if you work in complex stuff that have a test suite that take hours, the approach of commit small and fast seems wrong.

<comment><USER16> TDD makes small and frequent commits the natural way to work: figure out the smallest non-trivial step in the right direction, write a single test, verify that it (not the entire test suite) fails _for the right reason,_ implement the simplest code which makes the test pass, simplify the implementation while making sure the test passes, commit. This way each code change typically amounts to a single new path through the code which is known to be tested.

Asking people to use TDD for a coding test is probably a bit much since it takes a long time to learn the ins and outs, but small commits give a little bit of the advantage and can tell you a lot: Does the candidate know how to break the problem into _atomic_ changes? Do they commit only _reachable_ code? Do they create simple, fast, and _orthogonal_ tests?

<comment><USER17> This sounds awful. In fact, TDD as a whole is awful. I'm a developer, I can make any awful code pass any test I want.

<comment><USER18> I can go one better, and make any program at all compile by removing code with the annoying wiggly red lines under it.

The tools and options we have don't exist in a vacuum; you still need good judgement and practice to make the most of them.

<comment><USER17> It's funny you say that. Not long ago, one fresh dev was tasked with linting old code. Their first pass was to delete everything that the linter complained about. Hey, I guess they solved the problem!

</comment></comment></comment></comment></comment><comment><USER19> Not directly related to TFA, but directed at people doing stuff like this in general: you _cannot_ say things like "don't spend more than a few hours on this" or "don't worry about it too much" seriously.

People are competing for a job with these, potentially a big career step. A _lot_ will spend _every waking hour_ between receiving the task and the deadline working on it, because that makes sense when you're fighting for a job alongside a bunch of other people.

Anyone who actually follows the "don't spend more than a few hours on this" instruction is going to be at a huge disadvantage to the other people that almost certainly will ignore it, so as much as you try to make sure to reduce the pressure, you can't.

<comment><USER20> It's really in the best interest of the interviewer to set hard time limits. If you want your developers to work reasonable hours and be productive, you better hope that they can get shit done in a reasonable amount of time.

A start would be to time-box your interviews. Then maybe time out your own day and realize that spending 4 hours on an interview means that you miss dinner, sleep, your workout, and/or social time. I wouldn't want to force a future coworker through that mess.

So, now you've got to limit your interview to a couple of hours. Luckily, since 80% of industry is satisfied with trivia questions, you don't really need to try that hard to design an interview that helps you find better candidates than your competitors.

</comment></comment><comment><USER7> This is so painful to read...

> That was all we asked; we intentionally left it open-ended.

> I let them know there was no time limit or minimum for how many hours they > had to work on it

> But then over the next three paragraphs, they explained what they would have > done.

> Normally, I would have replied with well wishes on their challenges

> When I came back, I had three replies in the email chain that just said, > "Ship it."

> Why did this work well yet was a big deviation from what we had planned?

> How did we get such a strong impression of them with very little code?

> Do we even need code? How much code? Let's try less. Let's try none! Do we > just skip to the phone screen and talk about how they would start?

> Since then, I have moved away from coding tests altogether.

> ..that don't require them spending a whole night coding for just a chance at > an interview.

<comment><USER21> > This is so painful to read...

What's the painful part? That it could have been much more terse but you ended up having to read the whole thing?

If so, I kind of find your comment "painful" (not the words I would use if you hadn't) in a similar way at a high level, if for different low-level reasons. You provided very little information on what your found objectionable, and simply quoted select sentences from the the article.

I think the fact I'm not even sure I'm correctly interpreting your comment explains the problem with that.

I'm not sure the article is too long, maybe it is, but I definitely think your comment is lacking enough information to convey your point accurately.

<comment><USER7> Wow.

This response (and how you responded to it) really illustrates, to me, the problem with hiring in the first place when placing those hiring choices in the hands of engineers that don't have hiring skills.

> What's the painful part?

The parts that I outlined.

> That it could have been much more terse but you ended up having to read the > whole thing?

Nope.

> I'm not even sure I'm correctly interpreting your comment

Yup.

> but I definitely think your comment is lacking enough information to convey > your point accurately

Right, so if it was an issue for YOU, one good choice in the future would be to engage me in a discussion. Ask a simple follow up question.

"Hey, I didn't understand your comment, what did you mean by that? I'm interested in finding out more..."

This illustrates the state of hiring in our industry. Snap, terse, misunderstandings without exploring the idea that maybe the burden is on you to get some clairity if YOU don't understand something.

"Hey, I didn't understand those lines of code, what did you indend to with that? I'm interested in finding out more..."

Typically it falls inline with that the author of this article posted, he passes out an "open-ended" coding task as a pre-interview, get's something back, most likely "replied with well wishes" and moved on. They didn't have the time, desire, skillsets, etc... to identify and engage.

<comment><USER21> > Right, so if it was an issue for YOU, one good choice in the future would be > to engage me in a discussion. Ask a simple follow up question.

"What's the painful part?" was the first thing I wrote.

> This illustrates the state of hiring in our industry. Snap, terse, > misunderstandings without exploring the idea that maybe the burden is on you > to get some clairity if YOU don't understand something.

I explained that I had a hard time understanding what your point was, I explained that it was because of your lack of explanation (you could even say it was terse, which is why I'm surprised you level that accusation at me), and I asked you to clarify.

Perhaps you're offended that I said I found it painful? I made sure to note I was only using that phrasing because you did. My purpose in doing so was to note that it's not a very constructive way to criticize. If you did find yourself ion any way offended by that, please consider how you originally presented your position, and whether that was a constructive way to do so.

> This illustrates the state of hiring in our industry.

This exchange? Maybe it does! I did everything you criticize me for here, yet you somehow failed to see it. I think perhaps there is a lesson here somewhere.

<comment><USER21> I'm going to go out of my way to apologize, as my original reply to you was probably a bit snarkier than called for. At the time, I thought it warranted, because my misinterpretation of your comment (of what I thought the most likely meaning of it was, that is) lead me to view it as fairly snarky itself, when it doesn't appear that accurate, and I intended to lightly reflect that in a way I hoped would illuminate what I saw as the problem with that approach. Obviously, that doesn't make much sense if that wasn't what you were doing.

That said, I do think some of my criticisms hold weight. That is, that there wasn't enough actual content from you in your message to easily discern what you were trying to accomplish. I don't think I was the only one in that position. I _did_ attempt to ask you what you meant, and that was genuine, I just also included my reply for what I thought he most likely purpose, which turned out to be incorrect. I'm not sure if you took that as sarcasm, or as a method to bait you, but it wasn't.

Here's to hoping we both come away from this slightly better than we entered, and with little or no resentment. :)

<comment><USER7> > Here's to hoping we both come away from this slightly better than we entered

That's very funny to me :-)

> my original reply to you was probably a bit snarkier than called for

> At the time, I thought it warranted

> my misinterpretation of your comment

> what I thought the most likely meaning of it was

> and I intended to lightly reflect that in a way I hoped would illuminate > what I saw as the problem with that approach

Wow.

I quoted a few sentences that were painful to me, and out of that came all of this?

A snarky reply, that you felt was warranted, followed up by you trying to educate (illuminate) me on why you saw it as a problem.

Throwing in some "social proof" for why all of that was okay:

> I don't think I was the only one in that position

Along with justifying most of your approach:

> That said, I do think some of my criticisms hold weight. > there wasn't > enough actual content from you > to easily discern what you were trying to > accomplish

Emphasizing how big of a person you truly are by putting in extra effort:

> I'm going to go out of my way to apologize

<comment><USER21> > Throwing in some "social proof" for why all of that was okay:

More just to explain what led to it, but you can interpret it how you like.

> Emphasizing how big of a person you truly are by putting in extra effort:

Actually, just trying to live up to the standard I set for myself, but don't always achieve. I chose an idiom that might have implied something I didn't intend. By "going out of my way" I was really just referring to how I was replying to myself, and not waiting for your reply to me, so try to short circuit that wait, and express my feelings even if you chose not to reply but still felt negatively about the exchange.

It is possible to apologize for _how_ you did something, but not for _why_. This isn't some attempt and stealing a "win" in an argument through meta- analysis, it was just me deciding I had been uncharitable, and deciding to do something about it.

I'm sorry it sounds like you couldn't accept this in the spirit it was meant. It's probably not productive for us to continue further on this topic. I hope you have a good night.

</comment></comment></comment></comment></comment></comment></comment><comment><USER9> I don't want to sound cynical, but is the interview process likely to change any time soon?

Looking at the HN history, it's been a better part of a decade, if not longer, since people have been complaining about the hiring process.

It doesn't seem like much has changed except that it's worse, in the sense that you're usually asked to spend several hours on a coding project for screening AND have a subsequent whiteboard/leetcode interview or 10.

When you take into account all of the 'signals' that you're supposed to provide to even get a job, let alone be successful, maybe this isn't a good profession to be in anymore? Example:

\- Several hours - several days coding projects. Some are screening tests.

\- Having to practice leetcode continuously in order to keep it fresh in your head, because you never use it in actual work.

\- Robust open source portfolio is highly encouraged, in some places required.

\- Constantly keeping up with new libraries, frameworks and languages. It's unusual to get to learn these on the job, usually you have to do this on your own time.

Let's face it:

When you take into account all of that extra time, it seems like Software Engineers are not being paid very well.

Especially if you value your leisure time.

Why is it like this? Maybe it's just too competitive, too many Software Engineers applying for too few positions. Whatever the reason, it doesn't sound at all what it used to be, and maybe it's time to get out.

<comment><USER22> Maybe there are some places that require everything you've listed (open source repos, take-home project, whiteboard coding). But I think many, or maybe most, only require one of them.

At the end of the day, I'm sure we've all met someone that justifies requiring sight of _some_ sort of code of the candidate before hiring them. But different people will find different types of coding test better or worse ("I don't want to spend loads of my free time on a take-home project" vs "I can't code under pressure in front of a white board even though I'm great at coding in general"). So Hacker News will always be filled with endless debate trashing all forms of assessment with no agreement on what to use instead.

<comment><USER9> That definitely has not been my experience at all.

My experience is that _almost every_ place I've interviewed requires both a coding project and at least one whiteboard interview, with open-source as a huge plus in your favor.

Maybe it's not an either-or thing and just requires a little bit more consideration of how it's affecting the industry as a whole.

\- If someone has stellar experience on what's desired, they shouldn't have to jump through the other hoops.

\- If they have a strong open source portfolio that reflects exactly what's desired, they shouldn't need the other hoops.

\- If there's a whiteboard interview, don't ask about anagrams or anything that an experience dev wouldn't already be using in their day-to-day. Ask something relevant, like their understanding of databases, networking, etc if they are going to be Senior Backend dev. Ask about something a strong, experience dev actually knows that a junior doesn't. If you suspect possible gaming, then go deeper into the questions to filter out bs.

\- If there's a coding exercise, keep it timed to a max of 1 hour if it's a screening test, up to 3 hours if it's a final interview. Have the project already set up for them so they're spending time on the problem and not on config. Clarify exactly what you're looking for in the results.

It's basic common sense.

I've heard on other threads a lot about being 'too old' to code. This doesn't happen in other engineering disciplines, where age is highly valued because of the experience it brings.

I'm suspecting this kind of hazing ritual to be screening out very good older devs that have a lot to bring to the table, but don't have the time to do all this extra stuff because they have a family.

</comment></comment></comment><comment><USER23> My interviews have been some combination of:

1\. Techno trivia on whatever stack the company was interested in.

2\. Database modeling and queries.

3\. Questions about past projects and the choices I made.

4\. Whiteboard design questions (no coding)

5\. Here is a skeletal project - do these 5 or six simple programming tasks. Use google if necessary.

6\. Process, design and soft skill questions.

I have changed jobs 8 times in 24 years.

Since all of my experience is in the enterprise development/architecture space, I figured my best bet into getting into $BigTech without spending time "learning leetCode" was through their cloud consulting division. I tried my luck at AWS and I got in - no algorithms, not much techno trivia, just a lot of explaining past projects and soft skills questions on "Leadership Principles". Also - fully remote with travel post-Covid.

</comment><comment><USER24> An advantage of coding interviews: some people just can't help themselves...

To never lose at TicTacToe is not possible. If you're trying to never lose, you don't want minimax, you want a brute force of the search space

Seems like space is 2^9, but actually a few if statements is enough. You said I must never lose?? Okay I take the center (corner has same outcome, but center simplifies)

You now have 2 choices: corner, or side. Internally I will rotate the board so your choice was square 0 or 1

       012
       3x5
       678

If you chose square 1, I just need 2 if statements

       play(0)
       if(yourplay()!=8) return play(8)
       play(3)
       if(yourplay()!=5) return play(5)
       return play(6)

If you chose square 0, ... it is left as an exercise for the examiner

<comment><USER25>
      To never lose at TicTacToe is not possible

Sorry I don't understand that. Normal playing at decent skill level is going to always lead to a draw, which is not losing.

Am I missing something?

<comment><USER24> I was counting failure to win as loss. Your take is correct and better

My main other point :/ :) is a full -never-loosing- AI takes 6 if statements, and minimax is technically wrong for that goal

</comment></comment></comment><comment><USER26> I have thought about this quite a bit recently as well. I think the main thing to look for in interviews is "does this person have a clear and sound thought process?" In theory, the whiteboard questions are meant to suss this out, but the prevalence of Leetcode and other interview prep websites blurs the signal.

I wonder if just asking for a one or two page design doc on something would be a much better signal, since that's probably what you'll need to do on the job anyways.

<comment><USER20> I've seen a lot of engineers that rely on their intuition and end up just creating shit that works and is surprisingly maintainable. I've also seen a lot of different ideas on what a "clear and sound thought process" is.

In fact, someone who is clear and sound in writing might get bogged down when writing code. Good writers are (obviously) not necessarily good coders.

I do think there is potential around the design doc. Design is a big part of a lot of roles. In addition, in a lot of these roles, having the "best" design isn't better than having a design that the rest of the team can understand. Still, I wouldn't do it for the purpose of identifying good "thinking". I would do it because I expect the people I hire to be good (or have potential) at what they will be expected to do.

</comment></comment><comment><USER27> What we seem to forget is that the hiring process is actually to hire people not to reject them.

Companies should remind themselves to help out the candidate, give them prep material, and create a safe and relaxed space if they want to see really how a person will perform in their daily job. I think that a lot of this is driven by big company ego where a high rejection rate implies a higher reputation because of course: "we only hire the best, that's why so many didn't make it" this is a total bias IMO, a sane metrics for a smooth interview process should not be based on the result of the interview solely. You should ask your self how diverse are the profile that you are able to attract, how long did they stay and how good their annual/performance review goes after 1 year, what's the feedback of their coworker and leads after 3/6 months. Getting feedback out of this and tune the interview process interactively and in a data-driven fashion, because this is what it is, a process that can and should be improved, not a sort of fetish medal to show people and (falsely) say: "Hey look how cool I am, I hire only `the best`"

</comment><comment><USER28> > _if the app made sense and the code was readable_ , even if in a very > different style _than what we were used to, we would be up to talking more > and asking the applicant about it_

Not sure what "style" means here, but this seems strange. Why does the author need to say this / why should style matter?

It sounds like the habit of the candidate about the position of braces had an influence on their hiring process, and after giving it some thought, they decided against it. This is the lowest signal one could possibly imagine.

<comment><USER20> Did you misread? The author wants readable code and accepts "style" differences.

</comment></comment><comment><USER29> > "Why did this work well yet was a big deviation from what we had planned?"

Huh? Maybe because you only had one person to review who deviated from the norm?! StackExchange changed the way tech forums were ran by forcing everything into the Q&A format. It focuses people and prevents a lot of back and forth to understand the what the OP is asking.

Spec work sucks as a requirement in an interview SUCKs, but at least you can run it.

</comment><comment><USER7> Some of the best people I've had the honor of hiring, and some of the best jobs I've had the privilege to be offered, never once involved opening a code editor, sharing a screen, reviewing any code, completing a take home project, or being challenged with a brain teaser.

Why is that?

</comment><comment><USER30> >in the end, whether in hiring, coaching, or giving recognition, connecting with people is the goal for a manager.

Go with your gut? Did I miss the part where the lesson learn was named? Learn what you're looking for first?

<comment><USER7> My takeaway was the author learned how to better interview, by not giving code tests, but instead to begin engaging in a discussion with someone.

</comment></comment><comment><USER31> _their submission was incomplete. But then over the next three paragraphs, they explained what they would have done._

I would not hire this candidate for an IC role based on this submission. The main quality I'm looking for in an engineer is "gets things done". If this was a manager role, then sure. A manager could describe what they would have done or (preferably) what they did in a similar situation.

They were given two (!) weeks to complete a simple task. I saw no excuse for not delivering.

<comment><USER7> > They were given two (!) weeks to complete a simple task. I saw no excuse for > not delivering.

So you're saying that in your worldview, it is 100% acceptable for a pre- interview candidate to spend a full 2 weeks (or even a significant portion of that) coding something, for free, at the off chance they'll maybe get an actual interview?

<comment><USER31> Yes.

If I want a job badly enough, I'm willing to spend 2 years preparing for a chance to have an interview there. For example, if I wanted to work at a top AI lab (like DeepMind, FAIR, or OpenAI), I'd better start working on a paper that gets accepted at NeurIPS, or a research project that puts me on their radar.

If that's not 100% acceptable in your worldview, then perhaps you're not who they're looking for.

<comment><USER7> This is reaching far beyond the context of the article, and the comments replying to it with this example.</comment></comment></comment></comment>


Don't get CoffeeScript on your Mustache.js and break your BackBone - <AUTHOR> http://blog.bijanvaez.com/dont-get-coffeescript-on-your-mustachejs-and

<comment><USER2> This happens all the time in any industry. At a certain point you have to decide what works the best, and re-evaluate your commitment to certain frameworks whenever you think its worth upgrading +1

<comment><USER3> Definitely. It is frustrating having to take time off actual productive work to have to learn something new, but the cost of not keeping up is (in the long run) much higher.

I've just started a mini-project (encrypted webchat) pretty much as an excuse to have a play around/familiarize myself with coffeescript and jquery. If it works out well, I'll look at making coffeescript part of my new regular toolkit.</comment></comment>


Airbnb Tech Talk: Spike Brehm on Backbone, Node.js, and Single-Page Apps - <AUTHOR> http://www.airbnb.com/meetups/2d5sndfza-tech-talk-spike-brehm

<comment><USER2> Any idea why Google Chrome asks "This page is in Indonesian. Would you like to translate it?"

<http://cl.ly/image/0a37411l3F41>

</comment><comment><USER3> For the past talks check (including this one, when it happens :) ): <http://www.airbnb.com/techtalks>

</comment><comment><USER4> I love this tech stack.</comment>


Ask HN: What is your modern web development stack? - <AUTHOR> Such as: - language/framework - JavaScript libraries - HTML/layout frameworks - CSS preprocessor - deployment web server - database - containers, VMs, bare metal? <comment><USER2> If I'm calling the shots, up until recently it's been:

Backend: Clojure + Postgres. Keep it as simple as possible.

Frontend: Simple server-side templating in Clojure if that's sufficient. React (from either JS or ClojureScript) if non-trivial client-side interactivity is needed. My experiences with Javascript "frosting" on mostly-server-side applications hasn't been great -- can easily end up more complicated than an all-React implementation, even if you need server-side rendering.

But I'm increasingly keen to avoid the JVM, so future projects will probably have something else on the backend. I've used node backends a few times recently, mostly in "need to glue something together _fast_ " contexts, and have been pleasantly surprised.

</comment><comment><USER3> Lately have picked up Micronaut which is a very interesting take because it has no support for traditional front end, but supports SPA style front ends really nicely. So:

VueJS + Vuetify + Micronaut/Groovy (services) + Postgres

All of it is (except postgres) pure JVM so the VM vs bare metal question is more a logistics / deployment choice.

</comment><comment><USER4> Backends: App Engine NodeJS & Google Cloud Functions

Databases: MongoDB Atlas, MySQL & Firestore

Frontend: React for the app, Wordpress for the marketing site

</comment><comment><USER5> Server: Groovy / Grails, Docker, ECS, Postgres

Frontend: (current) Bootstrap, jQuery (future) evaluating Vue.js

Auth / SSO: CAS, OAuth, Spring Security

</comment><comment><USER6> Backend: LAMP with Laravel

Frontend: React for data intensive applications. Vannila js for everything else.

</comment><comment><USER7> Backend: C#/Go/Python, Docker, Kubernetes

Frontend: Asp.net/Javascript/Ext.Net/CSS

</comment><comment><USER8> Work = Perl backend, jQuery fronted. Hobby project 1 = MEAN stack

I use jenkins for both

</comment><comment><USER9> server:java/spring,springcloud frontend:vue.js</comment>


Why don't metals bond when touched together? - <AUTHOR> http://physics.stackexchange.com/a/87109/17365 <comment><USER2> This is a major reason why the practice of welding, and soldering, is so complicated.

A lot of what makes welding and soldering complicated is the need to remove, or avoid creation of, the oxide layers that inevitably form on the surfaces of metals. More so, these oxides form faster at higher temperatures. That's why solder wire and stick welding electrodes have flux cores or coatings, why MIG/TIG welding uses a shielding gas, and so on.

<comment><USER3> I highly recommend everyone take a Welding 101 and 102 class at their local community college. While my primary trade is IT, I'm certified to weld, and I personally think its a lot of fun. It's about not only knowledge, but skill and experience.

You'll be satisfied when you're able to successfully move the "puddle" of molten metal down your weld line, the weld looks beautiful, and then you find out your weld is extremely strong when its destructively tested.

<comment><USER4> I've been wanting to do this. How expensive is the equipment to keep and maintain?

<comment><USER3> Used welders in good condition can be had for under $1000. Depends on if its a MIG, TIG, or "stick" (flux). Traditional welding relies on the shielding gas being generated from a solid material (flux) wrapped around the consumable electrode. Other methods (MIG and TIG) rely on inert gasses being provided by separate support equipment to a "gun", which is also feeding electrode wire.

To take the class should only cost you book and tuition fees. My total out of pocket at a community college in the Chicago suburbs was ~$600 for three classes (Welding 101, 102, 110).

EDIT: I have a whole box of welding books. If you're serious, I'm more than happy to ship them to you.

<comment><USER5> Which suburb? My wife Erin took welding at Triton in Tyne near west suburbs and liked it, but they shut the program down before she could take the advanced class.

<comment><USER3> My classes were at Elgin Community College (I was living in Saint Charles at the time). Unfortunately, its quite the haul from Chicago.

</comment></comment></comment></comment></comment></comment><comment><USER6> This was the primary source of 'stiction' in the disk drive business. Platters became optically smooth, read write heads similarly. When the heads "landed" on a spot where the lubricant had migrated away from they would bind so tightly the motor couldn't break them free. (old SparcStation drives you could take them out. give them a sharp twist along the platter's rotational access, and if you were lucky move the heads to a space they wouldn't bind to.)

<comment><USER7> Many summers years ago, during an internship, I got tasked with setting up a development machine from old parts lying around the office. One of those parts was an, even at the time, ancient hard drive. When I first powered the computer up everything turned on just fine, but it couldn't recognize the disk. I'd run into bad hard drives before, no big deal.I went to my bosses boss, an older engineer who had seen a thing or two, and told him we'd need another drive. He took the thing out and gave it a good hard twist, and told me to try again. Lo and behold, it worked!

He explained that sometimes when older hard drives have been powered off for many years the head some times sticks to the platter and doing what he did can fix it. I could barely believe that the phenomenon was actually real. I've spoken to a few people over the years about heads sticking to platters and it turns out, while it isn't (or wasn't?) exactly common, it's not exactly rare either.

</comment></comment><comment><USER8> You're just not pushing hard enough.

[https://en.wikipedia.org/wiki/Explosive_welding](https://en.wikipedia.org/wiki/Explosive_welding)

<comment><USER9> As I understand it's not bonding chemically.

"The process does not melt either metal, instead it plasticizes the surfaces of both metals, causing them to come into intimate contact sufficient to create a weld. "

<comment><USER10> You don't need to melt the metal for there to be "chemical bonding". And now for me to probably mangle what I remember from material science.

When you're dealing with metals (and alloys) you're pretty much dealing with a lattice of atoms. It's not very useful to talk about individual atoms "chemically bonding" with each other, or at least not the way you would talk about say... bounding sodium and chlorine to get table salt, or nitrogen with oxygens to get nitrates.

Instead, you have this lattice of metal atoms, within which you can incorporate other atoms. Say you had a lattice of iron. By incorporating other metals into the lattice (say magnesium, or nickle), or even other non-metallic elements (most famously carbon) into the lattice, then you get different alloys. But at no time are you actually bonding say an iron atom with a carbon atom making a "steel molecule".

So when you weld dissimilar metals/alloys, what you're trying to do is to get two dissimilar lattices to "blend" into each other. When you have a crappy weld, one of the things that happen is you get a crappy boundary layer (potentially of stuff like metal oxides) sitting between the two lattices. Whereas if you have a "perfect" weld, the two lattices will seamlessly merge into each other - you'll get this diffusion zone. In the case of two similar metals, then the two lattices can actually perfectly merge - that is what Feynman is trying to get at there.

So, back to the point. Creating a good weld is in many ways as close to "chemically bonding" as you can get with metals / lattice structured materials. Or at least, in a useful sense.

</comment></comment></comment><comment><USER11> Fun fact: ultrasonic vibration can weld metals together (and this is used in modern wire bonders).

[https://en.wikipedia.org/wiki/Wire_bonding](https://en.wikipedia.org/wiki/Wire_bonding)

<comment><USER12> Another fun fact: there's a company using ultrasonic metal welding for 3D printing. They call it Ultrasonic Additive Manufacturing.

[http://www.fabrisonic.com/](http://www.fabrisonic.com/)

</comment></comment><comment><USER13> [http://en.wikipedia.org/wiki/Cold_welding](http://en.wikipedia.org/wiki/Cold_welding)

</comment><comment><USER14> [https://en.wikipedia.org/wiki/Cold_welding](https://en.wikipedia.org/wiki/Cold_welding)

Cold welding is a big problem, and a debatable one, in spacecraft engineering due to the lack of oxides and the out-gassing of the oils in space vacuum.

</comment><comment><USER15> There is wringing:

[http://en.wikipedia.org/wiki/Gauge_block#Wringing](http://en.wikipedia.org/wiki/Gauge_block#Wringing)

</comment><comment><USER16> Correct me if I'm wrong but isn't this why panning for gold in rivers was so prevalent through history? Flecks of gold would naturally cold weld over a millennium of being knocked around in the water.

<comment><USER17> I can't speak for all of history but at least in the US West gold panning was used to locate rich ore veins upstream. The idea is that you pan for gold, steadily moving up the stream until the relative amount of gold flakes drops, meaning you've gone just a bit too far and you probably now have a great idea of where a lot of gold is.

</comment></comment><comment><USER18> Guage blocks[1] due to their near perfect flatness are thought[1] to adhere by "Molecular attraction".

[1][http://en.wikipedia.org/wiki/Gauge_block](http://en.wikipedia.org/wiki/Gauge_block)

</comment><comment><USER19> Is this not an obvious answer? I am genuinely curious why the impurities and oxidation are not the answer the OP jumped to.

<comment><USER20> When you know you have basic but not expert knowledge you can make an educated guess (or several), but in the absence of empirical evidence you acknowledge there could be other factors you haven't thought of.

</comment></comment><comment><USER21> There is galling:

[http://en.wikipedia.org/wiki/Galling](http://en.wikipedia.org/wiki/Galling)

and galvanic corrosion:

[http://en.wikipedia.org/wiki/Galvanic_corrosion](http://en.wikipedia.org/wiki/Galvanic_corrosion)

In short, they do, given friction and/or moisture, and time.

</comment><comment><USER22> The hatches and frames on the Mercury and Gemini capsules had to be well painted because the exposure to vacuum raised the danger of like metals welding together.</comment>


Show HN: Please review my new side project [www.Schmeebs.com] - <AUTHOR>

www.schmeebs.com
I built this site in two days.  I tried to make it a fusion of Twitter + Digg in that people will be able to follow certain "domains" of news then be able to see popular stuff from there.
Its as real time as it can be at this point.  Would welcome any thoughts on it! <comment><USER2> I like the idea but I agree with the others that the color scheme is terrible. I am using FF 3.6 on Ubuntu 10.04 on my netbook and the text is overlaying the boxes which overlays the numbers which overlays the side menu. Needless to say it is very hard to read. While designing your site dont forget us netbook using couch potatoes with the small 1024x600 resolution.

<comment><AUTHOR> Thanks for that. I definitely need to put some more thought into the design. Hope to have something out next week that is a bit better.

</comment></comment><comment><USER3> I like the idea, but I'm not quite sure you want to name it that... <http://www.urbandictionary.com/define.php?term=Schmeebs>

</comment><comment><USER4> On Mashape you can build the same app in 2 hours. Grab the twitter component and then the digg component (inside the mashape market) put them together with a copy and paste and build on top of it your UI.

<comment><AUTHOR> I plan on building it out quite a bit more and do some more customizable stuff.

</comment></comment><comment><USER5> A head's up: Looks horrible in Firefox 220.127.116.11. Yeah, I know, you'll say everyone is using 3.x. But no, plenty of weak old PCs out here still. If I could see how it worked, I might use it. Good luck.

<comment><USER6> I don't think it's a firefox issue, the thing is nearly impossible to read with that background (I'm using chrome), and the text overlays boxes of the same colour, so it is illegible.

I think I like your concept (even though feeling slightly blinded).

I'd play with your colour palette and background. Try to take some 'weight' out of the design with lighter background and darker colours.

I like your sidebar nav, and collapsable menu may be good.</comment></comment>


Ask HN: from zero to development - <AUTHOR>

I friend of mine would like to learn iPhone development, but she is starting from zero since she does not know how to program at all (she studied communication and multimedia design).
I was thinking about teaching her, because I've thought for a long time to enter into the teaching business and this is an occasion to gather some information on how to do it having a student that did not pay for the course and can forgive me some mistake.
She wants to learn iPhone development, but I think this applies to learning any platform from ground level. What do you think it's the best path to teach development to a complete starter? Should I go the path I followed long time ago (learn how to program in a basic imperative language, learn OO paradigm, learn proper development on the target platform) or there is some better path, maybe mixing the steps? I understand that although the path I followed lead to good result, I started learning programming 15 years ago when the landscape was a lot different and I had a different commitment.
I would like to keep the level of interest and fun high from the start, because if I follow a more academic path I fear her enthusiasm could wear off (and this will be helpful in the future to have satisfied customers). Any advice/experience on this subject? <comment><USER2> I've tried this with mixed results. It all depends on the willingness of the 'subject' to bite through the boring bits before getting to the good parts and your ability to make the boring bits interesting. Hint: computing factorials is not interesting :)

Programming is best taught when aiming for a goal. So if her goal is an iphone app then that's the 'hook' you could use to make the boring bits more interesting. Keep that functional iphone app at the end of the tunnel as the way to motivate and you stand a chance of doing a good job here.

Finding out what motivates people is the key to teaching, if someone is hard to motivate or you're not good at figuring out what motivates them it will be an uphill battle. But once you have the motivation on your side you will progress quickly.

<comment><USER3> Very well said, in a succinct way.

Depends on the person (subject),

Goal,

Motivation.

</comment></comment><comment><USER4> You don't need a college degree to get started, but I do advice to start in the iphone platform right away. Considering your friend is into multimedia design already, I would advice her to start by creating simple iphone games in order to learn programming. Just take a look at the open-source cocos2D for the Iphone:

<http://www.cocos2d-iphone.org/about> I'm using it myself as well, and it's completely free.

I don't know if she's is into game making already, but I do know from my own experience (I'm a Game Designer & programmer btw.) that creating a game IS the best way to learn how to program, also the most rewarding.

Here's how I would advice her to start:

0\. run all the examples from the cocos2D engine on your iphone/simulator

1\. learn how to create a calculator with it (using self-made buttons)

2\. display an image(arrow) that moves+rotates where you tap it to go

3\. re-create pong: <http://www.youtube.com/watch?v=LPkUvfL8T1I>

4\. re-create frogger: <http://www.youtube.com/watch?v=2VcS77kFRSk>

5\. re-create tetris: <http://www.youtube.com/watch?v=keeSEJG4XzU>

6\. learn how to integrate menu's + transitions on top of your game

7\. expand your knowledge with SqlLite and create your OWN simple game,

and show the source to your friends and collect feedback on how to make it better.

Recreating tetris is the hardest part, but after that she'll have a solid knowledge of how programs work - and she can use this knowledge to go any direction she wants.

PS. If you need some help with getting started, just reply to my post.

</comment><comment><USER5> I taught Introduction to Programming at a University after I graduated. It was an great experience and I believe I might return to teaching later in life.

The biggest issue for you will be unlearning what you already know. Since you will be dealing with someone starting at zero, you will have to teach things you take for granted. Simple things like for-loops trip up a lot of people. Keep that in mind when you are teaching her, that you might be using concepts or ideas that you didn't think about, but she doesn't understand yet. I would move as fast as possible to working on an IPhone, simple hello world aps, so she can get the visual feedback.

I also would not shy away from the right way to do things, even if it is more complicated. As an example, Java was the language we taught at my school. Not knowing any different (not unlearning what I knew) I had my students properly define every class in its own file. This is just the right way to do things. Turns out all the other teachers would use a single class with private classes nested inside. My students had a small leg up on all other students, even if my best students were not even CS majors.

<comment><USER6> Can you talk more about your days teaching. This is something I would love to do but I know my Alma Mater would never let me do anything without a PhD. Where did you teach? What expectations were there for hours? What qualifications were they looking for?

<comment><USER5> It was at San Diego State University. The course was CS106 which was introduction to programming, a requirement for CS students and some EE majors and some math majors I believe. Technically I was a guest lecturer. I got my first job as a programmer through one of my professors. He was pretty well connected with several companies in San Diego.

SDSU was switching most of its courses to be taught in Java. They also had MSCE certification courses and were starting Java certification courses. I had just landed a new job at a local java shop. My old professor was looking for professionals to teach the new java courses. I was a pretty good developer and my name came up to teach the course (which paid pretty well.) But he decided that I need some teaching experience and got me to teach the intro to programming course to give me the experience. I know he had to pull a few strings to make it happen since I was not a grad student and not exactly a seasoned professional.

It turned out to be a great experience. I really enjoyed it. The pay was horrible. After preping for the lecture, grading, office hours and the lecture, I think it worked out to ~$12/hour. Quite a bit less than I was making as a regular developer. So I only taught the one semester.

I know of another guy I used to work with who was a horrible developer. I mean really bad. I believed he had a masters degree. But he taught extension courses at UCSD. I think the extension courses have a lot less restrictions on the requirements. From there he ended up teaching full time at another college, can't remember where. It was another small one in San Diego. This might be an option to allow you to teach if they offer extension classes.

</comment></comment></comment><comment><USER7> There is a good full course from Stanford here:

[http://itunes.apple.com/WebObjects/MZStore.woa/wa/viewiTunes...](http://itunes.apple.com/WebObjects/MZStore.woa/wa/viewiTunesUCollection?id=384233225)

</comment><comment><USER8> If someone can take a big, complex problem and disseminate the root causes then they can learn how to program.

I would start with something that she is familar with like the design and work backwards into the code. Use as many analogies as possible, try and find similar relationships to things that she is used to.

</comment><comment><USER3> well.. if this helps.

I have seen lawyers become programmers, Mechanical engineers implement ERP systems across countries, people with masters in biology enter and thrive in programming.

It all depends on how much you or your friend spend time in learning and trying out things in programming, that is, if you really like it.

Given the same inherent intelligence (which I correlate with creativity), performance or excellence depends on the accumulated knowledge, so keep accumulating that knowledge - practical and theoretical, from books, experience, the net, talking to others, degrees, certificates, from whichever and every way you can. It all adds up.

Good luck

</comment><comment><USER9> Before starting with iPhone development I would have her to get a CS degree or at least some of the standard courses.

<comment><USER9> When giving -1 please leave some comments. I strongly believe that without understanding the basics of programming one can't become a good programmer. So it makes sense to spent some time and pick these courses.

<comment><USER10> Well I didn't downvote you, but I still very much disagree. Having a solid foundation in CS is quite unnecessary for hacking together an iPhone app, and even if it was, going back to university is very ineffective way of quickly getting the necessary skills.

If, for example, you gave a list of what you considered the most important CS basics for an iPhone developer it would be far more helpful than simply saying "get a degree". Then the person who was asking the original question could build a curriculum around just those parts.

<comment><USER9> Agree. If the author agree with the idea of getting degree then we can figure out what subjects are required. By the short answer I just wanted to let you know my opinion, that it's very hard to get into programming without spending some time learning these subjects.

<comment><USER3> I don't mean to gang up on you, but if it helps in breaking your self-imposed constraints on yourself -

to become an expert in something, or even understand something, one doesn't HAVE to go to a university.

There are lots of university grads who are experts in nothing.

There are lots of experts in this world who became experts in different areas even when they never put a step in college.

Agreed.. university education, is definitely one of the many ways to accumulate knowledge. Its just that, its not the only way.</comment></comment></comment></comment></comment>


Dropbox API v2 launches - <AUTHOR> https://blogs.dropbox.com/developers/2015/11/dropbox-api-v2-launches-today/ <comment><USER2> No love after begging for an administration API for 2+ years.

At this point they should start putting some spin on it.

"Help your company employ more people. Dropbox for Business's lack of administration tools will grow your headcount. When you see your admins waiting for a list of users to load, or trying to write their own tools based on scraping the website, feel good about how you're fighting unemployment."

<comment><USER3> Our goal is definitely to give administrators the control they need through the API, but I'm very willing to believe there are things we're missing. :-) Is there something specific that's not already part of our Dropbox Business API? ([https://www.dropbox.com/developers/documentation/http#teams](https://www.dropbox.com/developers/documentation/http#teams))

<comment><USER2> I didn't see this. Huge step in the right direction.

I don't suppose there is a way to programmatically consume the activity stream and pick events to undelete, too?

I'm sorry I can't edit the smug sassiness out of my original reply.

<comment><USER3> It's not in v2 yet (coming soon!), but check out /log/get_events [0] in v1. I'm not sure that it will cover what you want if you're looking for file changes. That might be better served with webhooks, /files/list_folder and /files/list_folder/continue. Feel free to post on the developer forum if you want more help! [1]

[0] [https://www.dropbox.com/developers-v1/business/docs#log- get-...](https://www.dropbox.com/developers-v1/business/docs#log-get-events)

[1] [https://www.dropboxforum.com/hc/en- us/community/topics/20020...](https://www.dropboxforum.com/hc/en- us/community/topics/200209245-API-Development)

</comment></comment></comment></comment><comment><USER4> Hey if anyone from Dropbox is monitoring these comments: nice work, but there's something missing that I've been waiting for: API access to comments.

I'd love to recommend using the new Dropbox comments feature but I can't until I know there is a way of getting that data out after putting it in. I'm not entering metadata into a system that doesn't have fully programmable export. Been burned too many times.

Pretty please?

<comment><USER3> Thanks for the feedback! This is definitely already being tracked as a feature request, but I don't have anything to share about if/when we'll add comments support to the API.

</comment></comment><comment><USER5> So is this the API for clients or for servers?

I would like my web server to be able to slurp up all the images from my customer's Dropbox. Unfortunately, shared folders can't be downloaded if they are larger than 2Gb, which is quite often for me.

Is there an API suitable for this?

EDIT: oh yes, yes there is! [https://www.dropbox.com/developers/chooser](https://www.dropbox.com/developers/chooser)

EDIT 2: It would be sweet if you guys also exposed SHA2 hash of the files in Choser. Often times they user will mistakenly load the same file, and I would rather not do the work at all if I don't have to.

</comment><comment><USER6> One thing I cannot understand is that Dropbox API does not provide any kind of hash for files (in both v1 and v2). In contrast, Amazon Cloud Drive and Google Drive provides md5 hash, and OneDrive provides sha1Hash and crc32Hash. The lack of hash info makes custom app to compare and upload local files extremely painful.

<comment><USER7> Git annex [1] is a far more capable solution for file syncing and remote backups. It comes with a built-in assistant which syncs directories making it an adequate Dropbox replacement.

Git annex automatically uses SHA256 on all files as the UUID (optionally set SHA512 in .gitattributes). You can PGP sign your git commits to add more verification.

Plus you dont have to trust a 3rd party with your data, as it can sync entirely over local networks via SSH, directly to a USB harddrive, and it supports encryption when using S3 or other cloud storage.

I managed to teach my non-technical girlfriend how to use it without much effort but getting business people to use it might be a hurdle.

[1] [https://git-annex.branchable.com/](https://git-annex.branchable.com/)

</comment></comment><comment><USER8> Love the layout of the API Explorer. Makes it easy to see exactly what is being requested.

</comment><comment><USER9> Is there an accessible description of the API? i.e., what's driving the "code generation process"? Is that open and something I could use to generate a client for <insert my favorite language here>?

<comment><USER3> Stay tuned for more details! The short answer is that yes, you'll be able to do that, but we haven't published that API description yet.

</comment></comment><comment><USER10> The Dropbox Badge thing looks neat [1] but I don't see any indication of an open API so that non-Microsoft applications can take advantage of it. Does anyone know if there are any plans for that?

[1] [https://www.dropbox.com/help/7670](https://www.dropbox.com/help/7670)

</comment><comment><USER11> "There are currently four SDKs for API v2: Swift, Python, .NET, and Java." And a structured, non-REST API.

Aw. All grown up.

<comment><USER12> Initially I was surprised Swift, a new language, came before JavaScript. But after thinking about it you have to have it for iOS integration.

It's too bad their JavaScript SDK isn't ready yet but making HTTP calls from JavaScript is dead simple so that's not the worst thing.

Overall looks like a good set of priorities for what SDKs got done first.

<comment><USER13> Well, if JavaScript were meant to be used as an _actual_ programming language, then it would make sense to develop an SDK for it.

I'm only half joking there :)

In all seriousness, though, it did make my brain tilt about 15 degrees to see the words "JavaScript" and "SDK" next to each other like that.

<comment><USER14> _In all seriousness, though, it did make my brain tilt about 15 degrees to see the words "JavaScript" and "SDK" next to each other like that._

AWS has two JavaScript SDKs.

[https://aws.amazon.com/sdk-for-browser/](https://aws.amazon.com/sdk-for- browser/)

[https://aws.amazon.com/sdk-for-node-js/](https://aws.amazon.com/sdk-for-node- js/)

<comment><USER3> And Dropbox has one for API v1: [https://github.com/dropbox/dropbox- js](https://github.com/dropbox/dropbox-js). There will be one for v2 as well.

</comment></comment></comment></comment></comment><comment><USER15> A simple POST based API? What is this blasphemy?

<comment><USER16> As long as everything is well documented, I don't see the problem. With most languages, you'll probably want to use an SDK anyway.

What's the problem with a POST based API?

<comment><USER17> pixie_ was being sarcastic - alluding to how "RESTful" APIs with the wide array of verbs is en-vogue in some circles.

</comment></comment></comment><comment><USER18> Love the new features. I was hoping to see the ability to programmatically create File Requests. Looks like it might still be a while before it gets implemented.

</comment><comment><USER19> Why would they choose RPC style endpoints over REST?

<comment><USER20> Because REST is a superficial standard and people are starting to figure that out? APIs don't need to be complicated. Give me an endpoint to call and parameters to send. I don't need verbs, cool looking URLs, overloaded headers, special versioning schemes, and a never ending debate of what REST is and what it isn't. Also if anyone replies to this with 'you just don't understand REST' I'm going to put another nickel in the jar.

<comment><USER12> You are apparently me.

I've done REST and "rest" for many years and every single time it starts out really simple. Oh I just need the profile data so let's make a RESTful endpoint just for profile. So easy! Oh wait the profile page need data from X, Y and Z. Well we gotta be RESTful so let's make 4 HTTP calls. Oh, latency sucks on mobile and terrible networks and we have to cut down on HTTP calls? Sorry, can't, we're RESTful...okay fine ONE RPC endpoint for the profile page's information.

I think REST has it's place; it's good if you want a really intuitive way to access a very specific resource. Beyond that? For developing web apps? Almost always have to go down the RPC route and there is nothing wrong with that. Not everything has to be "RESTful" damn it!@

<comment><USER21> > Oh wait the profile page need data from X, Y and Z. Well we gotta be RESTful > so let's make 4 HTTP calls.

There's nothing RESTful about making more HTTP calls. There's no reason that there can't be representations of a resource in a RESTful API that happen to include, in the representation rather than by reference, representations of subresources.

(You probably would want to have authoritative URLs for the subresources _in_ the representation, assuming the media type of the representation is one which supports that.)

<comment><USER12> > There's nothing RESTful about making more HTTP calls. There's no reason that > there can't be representations of a resource in a RESTful API that happen to > include, in the representation rather than by reference, representations of > subresources.

Sub resources sure but I'm not talking about sub resources because sub resources are dead easy. This is more of a "oh we should also display resource X, Y and Z in these different spots".

If you want to be really "RESTful", TYPICALLY (and I say typically because I think every developer has a different definition of REST, lol), your URLs only align to resources so joining resources means multiple calls.

Google has an interesting solution for batch HTTP requests that could kinda be used in a way to batch RESTful requests but it's not the most intuitive. [https://developers.google.com/drive/web/batch](https://developers.google.com/drive/web/batch)

<comment><USER21> > Sub resources sure but I'm not talking about sub resources because sub > resources are dead easy. This is more of a "oh we should also display > resource X, Y and Z in these different spots".

The profile page is the resource (or a representation of the resource) identified by the URL (Uniform Resource Locator) used to access the profile page. This is true, pretty much by definition.

Whatever is designed as part of that page, and is also a resource, is a subresource.

> If you want to be really "RESTful", TYPICALLY (and I say typically because I > think every developer has a different definition of REST, lol), your URLs > only align to resources so joining resources means multiple calls.

URLs align to resources in that the fact that a URL is used to access something _defines it_ as a resource. There is nothing in REST which defines resources as _only_ the orthogonal entities in a data mode (e.g., the loose equivalent of entities in the base tables of a relational DB model.)

You certainly in many cases, for maximum flexibility, want your resources to _include_ those kinds of things, but there is no reason -- at least none that has anything to do with REST -- for them to be limited to them.

<comment><USER12> > The profile page is the resource (or a representation of the resource) > identified by the URL (Uniform Resource Locator) used to access the profile > page. This is true, pretty much by definition. > Whatever is designed as > part of that page, and is also a resource, is a subresource.

No that's not true at all. Your API design should not influence the user experience but the other way around and you're unlikely to change models should you have more optimal ways to presenting things.

On paper? Sure but I've never seen anything able to be split so nicely as you describe.

</comment></comment></comment></comment></comment></comment></comment><comment><USER22> Sample app link here is broken [https://github.com/dropbox/dropbox-sdk- python/blob/master/ex...](https://github.com/dropbox/dropbox-sdk- python/blob/master/example/back-up-and-restore/backup-and-restore-sample.py)

<comment><AUTHOR> Thanks for letting us know. We'll get that fixed (I'm an employee). Here's the correct link: [https://github.com/dropbox/dropbox-sdk- python/blob/master/ex...](https://github.com/dropbox/dropbox-sdk- python/blob/master/example/back-up-and-restore/backup-and-restore-example.py)

</comment></comment><comment><USER23> So could one use this to manage encrypted files stored in Dropbox?

</comment><comment><USER24> Is the Dropbox client fully open source yet? I won't use a spying tool that hires international spies to be on the board if they continue to be closed- source and intent on spying. Their new SDKs seem to be open source - why not their main client product?

<comment><USER25> What are you worried about in the client app that would require it to be open source? Should they also open source their backend systems and give you access to them?

<comment><USER26> There was serious concern with some evidence a few years back that the Dropbox client was touching files in folders that weren't shared. Not sure if that is what OP's concern is. But I agree with your point, the client is only one small piece of the puzzle and won't reveal much.

<comment><USER27> This concern pops up every once in a while because people like to put it out of context. Most operating systems don't allow any way to poll for file events in a specific folder only, so you either keep looping through all files in the folder looking for changes which would be an annoying resource hog or you get all events and ignore changes that don't occur in the folder of interest. It's completely fair to say that any installed application can do whatever it wants so you are concerned, but the touching files part is just people wanting to complain.

</comment></comment></comment></comment><comment><USER28> Can I programmatically edit .xls files over the API? That would be great.

<comment><USER29> It's a storage api not a spreadsheet api. Dropbox itself can't do that, but it can get you the data and you can use an xls library or program to edit them.</comment></comment>


2048 for stars - <AUTHOR> http://newbrict.github.io/Fe26/

<comment><USER2> 24Magnesium is a dead end. It'd be a good idea to use a different font color to mark it.

(What happens with the 24Magnesium in the real stars?)

Edit: From a comment in another thread by ISL [https://news.ycombinator.com/item?id=7607397](https://news.ycombinator.com/item?id=7607397)

> _I 'm getting trapped at Mg24. Following the alpha-process, I should be able > to stuff in another alpha to get to Silicon, but it's not happening, nor is > it listed in the fusion rules below the game. > [http://en.wikipedia.org/wiki/Alpha_process](http://en.wikipedia.org/wiki/Alpha_process) > ._

<comment><USER3> It's a dead end, but it makes the game kind of interesting (I just exclaimed in the office 'I got to SILICON! Now I can rip up the alpha process to iron! Muahahahahahaha! Then I got iron, and the game was over).

If you can just hammer alphas (Helium nuclei), the game is sorta dull.

I think there's still a ton of merit to this basic idea: Playing on a larger board initially full of hydrogen, allowing correct branching of decay products (so you keep getting back hydrogen in random locations), and allowing fission could be a (complicated) lot of fun.</comment></comment>


Spain approves "sun tax" - <AUTHOR> http://www.renewableenergyworld.com/articles/2015/10/spain-approves-sun-tax-discriminates-against-solar-pv.html <comment><USER2> And that was a year ago and this was three months ago

[http://cleantechnica.com/2016/03/10/parliament-spain- removes...](http://cleantechnica.com/2016/03/10/parliament-spain-removes- punitive-sun-tax/)

<comment><AUTHOR> The parliament didn't remove the sun tax. I am not sure about this new, but this tax is still being applied. The main leftist party in Spain (Podemos) defended during the last campaign to remove this tax [1], and there is a citizen currently suing Spain for this tax in front of the EU [2]. The Real Decreto de Autoconsumo [3] is active.

[1] [http://www.lamarea.com/2016/04/07/impuesto-al- sol](http://www.lamarea.com/2016/04/07/impuesto-al-sol) (this is around after the link you added, in spanish). [2] [http://gaceta.es/noticias/espanol- denuncia-impuesto-sol-gobi...](http://gaceta.es/noticias/espanol-denuncia- impuesto-sol-gobierno-ue-05072016-1956) [3] [https://www.boe.es/boe/dias/2015/10/10/pdfs/BOE-A-2015-10927...](https://www.boe.es/boe/dias/2015/10/10/pdfs/BOE-A-2015-10927.pdf)

</comment></comment><comment><USER3> This is nearly a year old. However it really is funny to consider that a country can tax such an abundant thing as the sun.

<comment><USER4> There is also the case of making collecting rain water illegal....

[https://jamesptaylor.wordpress.com/2007/11/29/bolivia- bechte...](https://jamesptaylor.wordpress.com/2007/11/29/bolivia-bechtel-and- the-fight-for-public-water/)</comment></comment>


Intrapreneurship Case Study: Angie's List and SnapFix - <AUTHOR> http://vergestartups.com/intrapreneurship-case-study-snapfix/

<comment><AUTHOR> I dig Oren's candid feedback from operating within a large tech company. "Frustrating at times" but they shipped a pretty cool product with SnapFix

</comment><comment><USER2> Oren's point about how projects are managed differently in startups and the corporate environment really rang true with me.</comment>