How to Interview Engineers - <AUTHOR> http://blog.triplebyte.com/how-to-interview-engineers <comment><USER2> The sad reality of programming interviews is that it's absolutely necessary to ask several near-trivial questions in order to flush out the candidates with awesome resumes and impressive degrees who simply have no idea how to analyze a simple problem and solve it using a computer.

Lately, I've been asking "given the starting and ending times of two calendar appointments, determine whether or not they conflict." No loops, no fancy algorithms, no tricks... and asking it has not been a waste of time. I get people writing doubly-nested loops over all of the seconds in the two intervals, comparing for equality; I get multi-line predicates full of redundancy that still yield false positives and negatives; it's depressing as hell.

<comment><USER3> I'm not a programmer but wouldn't

if (endtime[1] > starttime[2]){status=conflict}

work? Assuming time is encoded in epoch format.

<comment><USER4> This is close but you need to ensure the start time is before the other ends, and test for the second one starting before the first also. There's four cases:

[appointment 1 start] [1 end] <\-- some time --> [appointment 2 start] [2 end] (case 1 - no overlap, appointment 1 first)

[appointment 1 start] [appointment 2 start] <\-- some time --> [1 end] [2 end] (case 2 - overlap, appointment 1 first)

[appointment 2 start] [appointment 1 start] <\-- some time --> [2 end] [1 end] (case 3 - overlap, appointment 2 first)

[appointment 2 start] [2 end] <\-- some time --> [appointment 1 start] [1 end] (case 4 - no overlap, appointment 2 first)

So you need to do:

if (appointment1.end > appointment2.start AND appointment1.start < appointment2.end) OR (appointment2.end > appointment1.start AND appointment2.start < appointment1.end) // conflict

<comment><USER5> Your cases don't consider [1 start][2 start][2 end][1 end] or the opposite, but your pseudocode still covers those cases.

<comment><USER6> > Your cases don't consider [1 start][2 start][2 end][1 end] or the opposite > [...]

Your notation there, where instead of a pair of start/end pairs you have a list of tagged times, reminds me of a good approach if one is doing a generalized version of the problem: given a list of N appointments, find conflicts.

Make a list of tagged times, where a tagged time is a triplet (time, 1, name) if appointment named "name" starts at time "time", and is (time, -1, name) if appointment named "name" ends at "time".

Sort the tagged time list with time ascending as the primary sort key, and the start/stop tag ascending as the secondary key.

Now to find conflicts you simply scan through the tagged times list, keeping a running total of the start/end tag values. If the running total is greater than 0 when you begin to process a given entry, that entry has a conflict with an earlier appointment, and the running total is how many earlier appointments it conflicts with.

As described above, this lets you print a list of what appointments have conflicts with earlier appointments, but it doesn't give an easy way to say which earlier appointments conflict. If you want to do that, it is straightforward. Just add a set data structure, and during the scan of tagged times add "name" to the set when you encounter an appointment's start, and remove "name" when you encounter an appointment's end. When you find a conflict, the set contains the names of all of the earlier appointments the present appointment conflicts with.

The above assumed that two appointments do not conflict if the ending time of the first is the same as the starting time of the second. If that should be counted as a conflict, just change the sort so that the secondary key is sorted descending instead of ascending.

</comment></comment></comment></comment></comment><comment><USER7> _Spending a week working beside an engineer (or seeing how they complete a substantial project) almost certainly provides a better measure of their abilities than watching them solve interview problems for 1 hour_

 _Trial employment is expensive for the company.

[...]

Trial employment (and large take-home projects) are expensive for the candidate._

I can't help but think there's way to mitigate that expense among several (dozen) companies.

Triplebyte is already interviewing for other companies, why not set a low bar and hire everyone who passes it for a week? Charge your clients accordingly. If you have 25 clients hiring for overlapping skills, have them all pay to hire a person for a week.

40 hours of of labor / 25 clients = 1.6 hrs of labor per client, or about what it costs to do a single technical interview.

Meanwhile, the interviewee gets to do a single, focused project for a week, but effectively interviews with 25 companies!

I can get on Dice right now and find over 100 openings for python/java/golang/javascript/c++ engineers, certainly all of those companies would benefit from something like this.

More power to Triplebyte if they can figure out how to take those projects and turn it into a client deliverable on top of defraying interview costs.

<comment><USER8> If I'm already employed, it be weird to take a week off just to work for another company. Also ramp up time takes at least a day or two. This whole process seems troublesome for both the employee and employer

<comment><USER7> When did you last switch jobs?

I recently went through a round of employment where I quit my job at the beginning.

Between updating my resume/social networks, brushing up on academic CS, finding leads, scheduling interviews and follow-up interviews and managing/negotiating offers, it was absolutely a full-time job.

I can't imagine finding a new programming job while still working at the old job.

<comment><USER9> I think this is a crazy expectation.

I last switched jobs while working at Apple last October. Having the BATNA of your current employment is crucial to the negotiation process and I can't imagine forgoing that- if you have no current income that's an insane bargaining handicap.

Anyone with experience absolutely is not going to go for "quit your job, and maybe we'll give you a new one after a week, maybe it won't work out and you are boned"

<comment><USER10> I had a YC company that wanted me to do a trial week. They wanted me to quit my job when I said I couldn't take off a week of vacation.

When I said no, they wanted me to come out Friday through Monday and since the whole company works on the weekend, they would get 4 days to work with me.

At that point I said I wasn't interested.

<comment><USER11> Wow this is next-level outrageous!

Could you share the name of the company so others might avoid them and avoid wasting their time with such nonsense?

<comment><USER10> Since it was in 2014 and I don't know if they still do this, I won't name them.

I guess the lesson learned is to ask what the interview process looks like before getting involved.

However for this company, I applied online, they sent me a InterviewStreet/HackerRank coding test, and only after I passed that did a recruiter call me, and tell me they wanted me onsite for a week.

<comment><USER11> >"However for this company, I applied online, they sent me a InterviewStreet/HackerRank coding test, and only after I passed that did a recruiter call me"

This is a huge red flag in my opinion and I would recommend people not agree to this. Why? Because it shows complete disregard for the candidate. "Pass a test and you can speak to an actual human being." Its demeaning. It also shows just how useless many recruiters have become. Part of the job of a recruiter's job and good ones do this, is to get a candidate excited about interviewing with the company and get the preliminary deal breaker questions out of the way to see if it even makes sense to proceed.

<comment><USER12> And for me that was a perfect interview. First quick question by email to see if I was interested, then some simple test to see if I can really program, then quick interview to see if I have required domain knowledge (all questions were about knowledge required to program effectively, not abstract "how to move mount fuji"). For an introvert programmer like me it's a perfect interview schedule. Also it helps when you are already working and want to check conditions in other company without risk of being thrown out from your current job.

<comment><USER13> I gave up on those the last time I wasted 4 hours of my life on one of those tests and never even got a rejection email. It wasn't a hard test and I didn't do badly.

Nowadays I just point them at my github. If a body of open source isn't enough to get an interview I'm not interested in working there.

<comment><USER14> Are you against coding tests in general (especially when you have open source work to point to) or just as a prerequisite to speaking with someone?

<comment><USER13> Just as a prerequisite.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER15> I find it odd that so many comments here highlight the fact that people are giving interview questions that have little to nothing to do with day-to-day employment tasks.

It seems to me like an enormous amount of time wasted for both interviewers and interviewees.

When considering someone for a development/engineering role there are a few basic questions to figure out:

1\. Does this person have competence within our technology stack?

2\. Can this person communicate clearly?

3\. Is this person productive/can this person be productive in our environment?

4\. Does this person have characteristics that will allow them to succeed in our environment?

Making people jump through hoops like some sort of dancing monkey while they are on a job hunt is needlessly cruel and is a waste of everybody's time.

If you regularly see people who can't succeed with what you consider basic engineering questions, you either have a recruiting problem or you yourself have a communication problem.

If you expect an interview candidate to expend 8 hours or more working on interview tasks, you should be presenting a unique enough opportunity to justify it.

If you expect an interview candidate to whiteboard a solution to a coding problem that they received in the room, that should be part of your everyday work experience and you should go through the process yourself in front of them so that they have an understanding of what your expectations are.

If you want to review their code and talk with them about it to determine competency, provide an example of your own code and a set of questions and answers that would be successful.

Don't put engineers through a gauntlet of challenges that you would have trouble successfully navigating under the pressure of feeding your own family. They have more than one company they are interviewing with and each company has their own focus. Put them in a position to succeed and give them the chance to do so. That's what you want out of your own people - the ability to succeed given a reasonable amount of guidance and clear parameters for success. If you can't provide the guidance or the parameters for success for an interview, how can anyone expect to succeed in your actual working environment?

<comment><USER16> The question of relevance reminds me of an anecdote. (Before that though; I tend to agree with your points.)

A distant acquaintance interviewed for a secretary position. It didn't go well, because she was asked a general knowledge question (something along the lines of: "name some of the planets in the solar system"). She was furious with how irrelevant and unfair this was. It makes me wonder though, would I have hired her? I probably wouldn't have asked that question, but still. When someone is missing some really basic knowledge - even if it's irrelevant - it's not a good sign, per se.

<comment><USER17> One of the things I like to do is ask a factual question about a technology listed on the candidate's resume that isn't required to know in order to hack something together, but is something that "you should know" if you've been working in a particular technology for a few years.

These are part of the warm-up, I'll ask one or two right at the beginning of the interview and then move to the real questions.

Examples are: "How does the autorelease pool work?" (Objective C before everyone switched to ARC.) or "How do you ensure that an object is garbage collected," (C# and Java.)

These are more about judging a candidate's real knowledge versus stated knowledge. Someone who's spent 8 years in Objective C better know how to use the autorelease pool; and someone with at least a year of experience in a garbage collected language better know how to ensure that an object is collected.

<comment><USER18> As someone who has worked in C# for about 8 years: you can't.

You can call `GC.Collect()` and _hope_. But far as I know the GC will do a best effort and gives no guarantees.

Of course that's besides that fact that I would need strong arguments to accept a `GC.Collect()` anywhere in the code. But to call it just to ensure an object is collected? Oh boy..

Depending on the case you could add some code to the `Dispose(bool)` method to know _when_ your object is collected, but also in that case you risk flipping a Bozo bit.

</comment></comment></comment></comment><comment><USER19> My own 2 cents for interviewing, for engineers and most other vaguely technical positions but perhaps broadly applicable:

\- Don't ask them to whiteboard, especially don't ask them to whiteboard some absurdity

\- Don't put a panel of 5-10 people against a single candidate, but if you must absolutely (why?) do not do it on the first interview

\- Don't ask time-wasting stupid questions about manhole covers, boiling bagels on mars, overlapping clock hands, or how many eggs fit into a phone booth

\- Don't put someone into a socially awkward situation

\- If you ask a knowledge question and the response is something like "I don't know, but I would google it" that should be acceptable if they are demonstrably capable of using what they find

\- Do ask them to walk through their own projects, their code, their past work/contributions, etc

\- Do try to effectively convey the corporate culture so the candidate can know if they are a good fit or not ahead of time

\- Do try to accurately convey what their actual job duties and day-to-day work will be

<comment><USER20> Can you expand on the boiling bagels on mars question ? Havent heard of that before

<comment><USER19> It's just a variation on the typical logic/creative thinking questions that a lot of people and companies obsess over.

"Well they're a great candidate otherwise but they totally failed the boiling water on alternate planet question, so let's keep searching" \- believe it or not, that's a real mentality out there. I don't get it and never have.

<comment><USER21> Maybe its just me but I find a lot of algorithmic interview questions are just as hit and miss as these obscure questions if you need to do it in an interview.

I had a phone interview with Google and was asked to come up with a variation of a soduko solver. Couldn't get it there and then, but half an hour later walking down the road, a really elegant solution came to me.

</comment></comment></comment></comment><comment><USER22> > background-blind interviews, looking at coding skills, not credentials or > resumes.

Subtext: "Did you create a famous open source tool, write a book, have patents in your name or architect some amazing system at a big company? Doesn't matter! Our hiring process prefers code monkeys who can solve our puzzles instead of system thinkers."

> An interview can result in a bad engineer being hired and later fired (a > false positive).

Subtext: "A hire can either be good or bad. It's never management's fault if it doesn't work out."

<comment><USER23> >Subtext: "A hire can either be good or bad. It's never management's fault if it doesn't work out."

I agree that the article gets this wrong. It reminds me of Diego Forlan's time at Manchester United.

Diego Forlan is/was an Uruguayan striker at Independiente (Arg) where he scored 36 goals in 77 games (a very good rate). He then moved to Manchester United (Eng) in January of 2002 and was anticipated to take off. He made 18 appearances in the 2001-2002 season but failed to score. It took him until October to net his first Premier League goal.

He was loved by the fans as he has/had a great attitude and had some delightful near misses. He also famously scored twice against Liverpool[1]. But he continued to struggle at United, scoring only 17 goals in 63 appearances until he was sold to Villareal (Esp) in August of 2004. In his first season at Villareal he won the Pichichi Trophy (golden boot for La Liga) and the European Golden Boot. What a turnaround!

Forlan went on to have a terrific career and is considered one of the best Uruguayans to play modern football (soccer). His time at United was certainly a misstep but it wasn't because he was bad. And it wasn't because United were bad. It just didn't work. Sometimes it just doesn't work.

[1] [https://www.youtube.com/watch?v=49Zym0gaZqA](https://www.youtube.com/watch?v=49Zym0gaZqA)

<comment><USER24> Did they really get it wrong? Very few candidates are Diego Forlan, very few wrote books, verfy few created a foundational open source project, etc...

I suspect candidates that wrote the Linux kernel, Rails, Modern Effective C++ etc... don't need a recruiters services. If whatever candidate wrote is not so big as to land them jobs almost automatically then was it really that big as to demand consideration separate from college degrees and other ignored history?

I think we dislike the idea of our history being ignored because we all feel that we are special, but in reality very few of us are.

<comment><USER23> >Very few candidates are Diego Forlan

How would one know? Usually we know a friend who works somewhere and they say the company is shit. Or you work somewhere and someone doesn't work so you end up thinking they're shit. It's not often that you have both sides of the story.

>very few wrote books,

Books might indicate a good communicator and independent ability to complete a task but it's not an indication that someone is a good team member that fulfills a particular role.

>verfy few created a foundational open source project, etc...

I contend that this actually risks being a Balotelli. Good in the right atmosphere, but very independent and often stroppy when they don't get their way. They can be terrific in their element but often they're not good enough to build a team around.

<comment><USER24> I would argue I know because I have done many interviews, not nearly as many as the author of the article. Most interviewer candidate are about as qualified as a stuffed animal, except I would allow a stuffed animal in the office because they tend not to break things.

I agree with you that on your points about books and project founding, but I would hear a candidate out and not make hard unchangeable presumptions.

As for how do I "know" I can't know, I am only in the interview for an hour or two. The best I can do is get a sense. If the candidate nails fizzbuzz, explain the nuances of git v mercurial for 20 minutes and provides a plausible explanation for his previous place of employments toxicity then that affects my decision making one way. If it feel as though their reasons are thinly veiled excuses, they don't know foundational tools or fail at fizzbuzz... well I don't let interviews proceed to where people fail all three when they start with some minor points against them. Too many red flags and I call it done.

</comment></comment></comment></comment></comment><comment><USER25> An interesting point my co-worker made is that, almost by definition, if an interviewee does not know how to answer a question, they don't know why that question is important or where that type of problem is applied. So from the point of view of an interviewee who's can't do well on all the questions (that's most of us in most interviews) some of the question will always seem like minutiae / lacking application. (Of course, there's also plenty of just bad interview questions)

<comment><USER26> It's entirely possible to not be able to answer a question because the question is objectively not meaningful, and therefore the candidate has correctly never considered it important enough to learn about.

<comment><USER25> Totally. Both things happen.

<comment><USER27> Sometimes questions are useful only if you are in the context of the specified problem. I mean, if you are not struggling or have never struggled in the problem, you will probably not know the specificities of it. This is specially true for unexperienced engineers or those who are working on a different field

</comment></comment></comment></comment><comment><USER28> _" 15% dislike academic CS (and think that talking about CS is a sign that a candidate will not be productive)"_

That seems really weird. Academic CS isn't really necessary for most programming jobs, but I can't see how it would ever be a detriment.

<comment><USER29> I had a guy work for me that was very academic minded regarding programming. He had a hard time letting go of the "pure" way of doing things and taking a good/practical approach to just getting stuff done. It can definitely be, but won't always be, a detriment in my experience.

<comment><USER30> I've worked at places where well-meaning 'just get stuff done' people created mountains of technical debt that hobbled the project in the long term. Made them look great, though.

Great programmers should hopefully recognize and implement a proper balance between practicality and rigor, as necessary. They should also exhibit self- awareness and self-restraint, which sounds like the real problem for the guy you mention.

<comment> FLUX-YOU >I've worked at places where well-meaning 'just get stuff done' people created mountains of technical debt that hobbled the project in the long term. Made them look great, though.

Those people were just getting a bit better at building things. They were building experience. It just so happens you found their bad code that they'll realize was terrible a few years from now.

We can't simultaneously hate our own previous code and expect everyone else to delivery perfectly when they first start (or even at mid-level).

</comment></comment></comment></comment><comment><USER31> We've had success with take-home coding challenges.

After 1-2 technical phone screens, we send applicants a coding challenge for which they have 48 hours to complete. The coding challenge is representative of some of the work we do (e.g. Given our API, create a D3 visualization of X) and should take applicants several hours to complete.

In submissions we look at everything from overall program structure and approach to applicants' attention to detail and usage of good industry practices.

This coding challenge quickly weeds out applicants that interview well but code poorly and is an efficient way for us to see the quality of work we can expect from them (and conversely, the type of work they can expect to do with us).

After a successful challenge, we bring applicants in to meet the team. At this point, it's largely just about culture fit.

<comment><USER4> Do you specifically hire D3 developers? This sounds like a pretty difficult "coding challenge" for a non-D3 guy, let alone someone who may not even primarily use javascript. Having used D3 sparingly before i've found it something that requires a fair amount of upfront domain knowledge to get much done beyond something extremely simple (unless of course you copy an existing example, which is what I always did). This seems unreasonably difficult for someone with no prior knowledge to accomplish in a 48 hour window whilst working etc -- you may find you are inadvertently optimizing your interview process for the unemployed with this kind of time limit / coding investment.

<comment><USER31> No, we're not specifically looking for experienced D3 devs. That particular challenge can be completed with the simplest D3 viz if desired (of which there are hundreds of examples online) and doesn't even require prior D3 experience (I didn't have any when I applied). We do look for a solid working knowledge of JS, however, and an ability to learn new tools quickly.

The 48 hour time limit is a relatively arbitrary timebox and isn't a hard limit; we value quality over speed.

</comment></comment></comment><comment><USER32> I've performed interviews and phone screens for years and out of all the techniques I've tried all of them typically end up with me thinking I'm doing it wrong. Basic domain questions, problem solving, white boarding, white boarding along side the person helping them out, coding in an IDE, take home projects. As of today, in Kansas City, I'm looking at around 4% pass rate, and close to 90% utter face palming failures.

I check my ego at the door, I try to make the person as comfortable as possible, small talk, help them out as much as I can, provide them with answers or explanations when they get something wrong. I've never asked an algorithm or data structure question, I've rarely asked a patterns question. Most people can't answer basic every day questions.

Overtime my goal in interviews turned into making sure the interviewee left with more domain knowledge than when they came in hoping it will help them do better somewhere else.

Ended up creating a pre-screening service that asks the same basic questions and in the end provides the user with a study guide based on how they answered. Currently piloting with two local recruiting companies and I'm finding the same similar statistics of failure/success. Maybe that makes me the issue :)

<comment><USER33> You know the quote: if you encounter an asshole first thing in the morning, you encountered an asshole. If you encounter assholes constantly all day long, it's probable you're the one who's the asshole.

If you have a 90% rate of "utter face palming failures", the problem isn't with the people you're interviewing, it's with the interviewer and/or the interviewing process.

<comment><USER32> That's what I keep questioning and why I've tried various methods. After screening resumes along with coworkers, at various companies I've worked at, we'll pre-screen or not, bring them in and ask them questions from their resume.

Resume says 'I'm an expert in SQL'. Great, lets start some every day foundational questions. What is the difference between an inner join and an outer join. Why might we use a varchar instead of a char data type? Why do we use indexes? What is the purpose of a foreign key? A good majority of the candidates can only answer the join question.

'10 years experience, senior dev in <main language>' can you write a function that returns the largest number in an unsorted array? Most struggle to even pseudo code it. Tell me something, anything about interfaces. Basic security question on SQL injection/xss/csrf/hashing/encryption. Without a doubt most have only heard of SQL injection and then they get that wrong. Most say hashing and encryption are the same thing.

I do blame myself, the failure rates are incredibly high. But when resumes looks great and onsite can't pseudo code a simple loop, or answer basic questions about something they claim expertise in, what can you do? Require and call references to make sure the the lead dev with 12 years experience and decent companies isn't lying? Because the result of most of my interviews appears that people inflate their resumes and flat out lie.

<comment><USER33> So let me ask you an "easy" question: for your interview questions, are you consistent in what you ask, and do you have a consistent approach to evaluating a candidate's response?

I ask this because some of your "foundational" questions are not as simple as you might think (I could talk for literally _hours_ about XSS and the only conclusion I could give you would be "there's no sure-fire way to prevent it", for example), and others border on pop-quiz material, which is not really a great way to evaluate someone.

Another question that's important to ask: you say you're working with recruiting companies. Have you tried not doing that? Recruiting companies don't exist to find you qualified people, they exist to spam you with résumés. Recruiting companies have been known to flat-out _alter_ résumés to make them better match the set of keywords you said you wanted. And my own experience is that recruiting companies are the source of a huge percentage of headaches in hiring. Cutting out the middlemen can and likely will drastically increase your success rate.

<comment><USER32> I try to be consistent with my questions, but it depends on how well the candidate is answering them as to the depth I go into a subject. Generally I ask the candidates about previous projects and work my questions into the conversations. It usually isn't a rapid fire pop-quiz type interview.

Tell me about a project you had the most fun working on. You tell me you started working on a SPA in Angular 2 and I ask if you've heard of some common attacks like XSS or CSRF. You say yes to both and I ask if you had any preventive measures in place or how you would go about trying to prevent them (I'd stop you if you kept going on and on). We'll work our way through the projects stack best we can in the same manner.

We generally used recruiters at all the companies I worked at due to lack of applications. I agree they're part of the issue. I also phone screen for recruiters so at least some of them are doing their due diligence (no idea how they act on my reviews though).

</comment></comment></comment></comment></comment><comment><USER34> As someone with an actual accredited engineering degree, I find it bizarre that Silicon Valley has decided that the term "engineer" doesn't even need to be qualified anymore. Even without getting into the flame war over whether "software engineers" are real engineers or not, there's a very large pool of engineers to which this post doesn't apply at all. I can't be the only one in the latter pool that reads HN, can I?

<comment><USER35> I used to be reluctant to call myself an engineer. I don't actually get to do too much engineering in my work. But I've seen too many less qualified people calling themselves engineers so I might as well... Besides, my degree is from the Engineering faculty at my university rather than Science where the CS/SE degrees are. At least that's how I justify it to myself.

</comment></comment><comment><USER36> Where I work, we'd be totally happy to ask interviewees how to reverse a binary search tree. As soon as an actual developer creates a pull request that does as such. Which hasn't happened yet. So we don't ask about things like that. And everyone seems happier.

<comment><USER37> I don't get it. Programmers are surrounded by trees. The filesystem, your code's AST, dependency trees, the HTML DOM, any JSON ... why do people consider it so unreasonable to ask a question about simple manipulation of a well-understood tree data structure?

<comment><USER38> Unless you're writing a database or browser engine, you will never have to implement a binary tree. So it is effectively trivia knowledge. It's like asking how the x86 CPU architecture works, because it's the platform on which most code runs.

</comment></comment></comment><comment><USER39> Here's a concept I had a question about that I don't think gets discussed that often...

If a company were to offer a base salary at a mere _third_ of the Google base salary for the same job, why should an applicant have to copy Google's _depth_ of computer science abstraction in the coding interview?

Is the onus on the developer for _even entertaining_ such a demanding question at a low pay, or does the current economy favor employers in such a way that developers have no other choice? Or rather, is the knowledge of available jobs asymmetric enough to where employers can pay pennies, piss, and peanuts for A-level employees?

<comment><USER40> I don't see a connection between pay and the interview process. Should the company also make their chairs one-third the height? Have one third the whiteboard marker colors? Feed you one-third of a lunch?

<comment><USER41> My willingness to jump through hoops is proportionate to how much I want to work with you. If you pay me well and treat me well, I want to work with you. If you're trying to hire me for 50% of market, my tolerance is much lower.

<comment><USER40> Then the filter would be "The skills of a Google Engineer, but can't get in there so might work here". All others need not apply?

</comment></comment></comment></comment><comment><USER42> Honestly drop the question/answer aspect for technical checkouts. Offer a problem then work with them to solve it. The most important aspects are two fold, What questions do they ask, and now that you are being cooperative and a team mate, how do they interact with you.

EDIT: But during the entire process keep in mind they are hopefully interviewing your company. Far too many companies forget this aspect and the entire process has become lopsided in favor of companies making candidates jump through hoops.

</comment><comment><USER43> Looking for a job has become a full time job. In depth technical discussions about the technicalities, then about technical quirks, onsite visits and time spend on researching what on earth the company is doing and what their project is about, then the curse of the industry - take home assignments. Once I signed my last employment contract I said to myself "I'm exhausted, there is no way I'll move a finger during the first months of employment in this company".

Also I learned to be more picky. "Want to see my code and apps? Show me your code, show me how you work!" Eclipse required? Bad workflows with weird limitations? "This is how we do it here, it works for us" attitude? High discipline environment with daily standups? Cheapskate workplace/outsourcing center? Sorry, I'm passing.

</comment><comment><USER11> >"After an engineer passes our process, they go straight to the final interview at companies we work with (including Apple, Facebook, Dropbox and Stripe)."

Can anyone from any of these companies confirm this? This strikes me as really odd. So only one employee from FB, Apple, Dropbox, and Stripe needs to interview a candidate that Tripplebyte say is a "Go"? I'm having a hard time believing that.

<comment><USER44> I don't think "the final interview" means a single person. I took it to mean the onsite round, with however many people that entails, skipping the recruiter screen, phone screen, etc.

<comment><USER11> So why does it matter whether the first round of interviews is done by this company or the actual company doing the hiring?

I would argue that as a candidate I would rather interview with as many of my potential coworkers as possible. Interviewing is a two way street. The more exposure to the actual people I would be working with allows me to make a better-informed decision. How is reducing my exposure better for me the candidate? It seems its really better for Tripplebyte though and maybe the company looking to hire if they are short-staffed but not the candidate.

<comment><USER6> > So why does it matter whether the first round of interviews is done by this > company or the actual company doing the hiring?

I think the idea is that if you do the first round with Triplebyte instead of with Apple, Facebook, Dropbox, or Stripe you are effectively doing the first round with Apple, Facebook, Dropbox, _AND_ Stripe.

<comment><USER11> >"... you are effectively doing the first round with Apple, Facebook, Dropbox, AND Stripe."

Except that I am not. By doing the first rounds with Tripplebyte I have squandered an opportunity to learn about and form an opinion about the people and team I might be working with in the future. The more answers I can get to my questions the better informed I am.

I guess I don't understand this whole "we will fast track you" as a value proposition. The only efficiency gain("fast tracking") is gotten by the company looking to hire. I myself am still subject to the same length of the interview sequence. Only one is with Tripplebyte and one is with the company doing the hiring instead of two or more with the company doing the hiring. And in the process I have given up the opportunity to have more exposure to meet and talk to the actual team I would be working with.

Should I be so grateful for an opportunity to work for "Apple, Facebook, Dropbox, AND Stripe"(Tripplebyte seems to beat this drum loudly) that it doesn't matter whether I think it would be a fit for me on a personal, cultural and professional level?

<comment><USER45> Assuming you don't pass 100% of on site interviews or you don't take the first offer immediately, triplebyte will save you some amount of time. Beyond the force multiplier for pre-onsite interviews, they also can predict which companies you will have a higher success rate with for your on site. It's not a guaranteed slam dunk for every single person (and you still have to pass their process) but I think the value proposition is pretty obvious to most people.

<comment><USER11> >"Assuming you don't pass 100% of on site interviews or you don't take the first offer immediately, triplebyte will save you some amount of time."

How exactly do they save me time? Can you elaborate?

>"Beyond the force multiplier for pre-onsite interviews, they also can predict which companies you will have a higher success rate with for your on site."

What is the "force multiplier" here?

Again this is a job where you will spend many hours of your life, should the only concern be the one whose interview I will have the highest success rate with?

>"... but I think the value proposition is pretty obvious to most people."

Again what is that? It's not obvious to me. I am asking sincerely.

<comment><USER46> Let me try to answer: Say you plan to interview at Apple, Facebook, Dropbox, and Stripe. Lets say each company requires 2 rounds of interviews. Without these guys, you're doing two rounds at each company = 8 interviews. With these guys, you do one round with them, and one round with each of the companies = 5 interviews. If that's how Triplebyte works, it would be a huge time saver.

<comment><USER11> Does every engineer unquestionably want to work for any and all 4 of those companies? Aren't these very different companies? Is there any significant commonality here other than Tripplebyte has some connection at all of these?

<comment><USER46> Pick N other companies, then. As long as TripleByte has this kind of relationship with at least 2 of them, it's a time saver. I could easily see myself interviewing for 20 companies in a single job search. Needing only one "pre-screen" for all of them would be nothing short of miraculous.

<comment><USER11> Let's say you avoided interviewing with 4 future team mates from company Company A by using Tripplebyte.

And come to find out most of those 4 people you didn't have a chance to interact with during the interview process are completely toxic and unprofessional. You only find this out after you have accepted the job.

If you find yourself looking for a new job again in month then Tripplebyte hasn't really saved you any time have they? I am not sure where this idea comes form that just because the company is "Apple, Facebook, Dropbox and Stripe" does not automatically mean that everyone on every team is a great personally or one you would want to work with.

When I interview with a company and I don't think I am alone in this I am also interviewing the company. I am thinking "are these people I could work with?" The novelty of working on Big S.V. Company eventually wears off and if it's a bad fit for you on personality or culture then you are either going to be unhappy, looking for a new job or both. I and I imagine many others are OK with a slower process if it means being able to make a better informed decision.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER47> Sometimes I ask candidates to come up with a question for the interview, something that would allow them to put their best foot forward.

Any thoughts on that?

<comment><USER48> The question is really under-constrained and it's not clear what you are trying to figure out.

I ask things like, "what's the most interesting bug you've encountered?" or "what have you been excited about learning recently?" to try to find a topic we can have a conversation about in a domain they are familiar with and interested in.

<comment><USER47> Oh, I forgot to add - I actually ask for a coding task they think will put them in the best light. Like, "hey, I can balance a binary tree, let me show you". In my mind if someone learned something like this very well they show their learning potential, and complexity of the task will tell me their self- assessed level of development.

</comment></comment></comment><comment><USER49> >I'm arguing for asking easy questions, but then judging fairly harshly.

I agree with this. Better yet ask a multi-part question that has an easy first part and a harder follow on.

</comment><comment><USER50> Interesting read from the POV of the staffing agency and hiring company. But why should I jump through those hoops when I don't even know if I'm interested in the job? I really think the hiring companies need to sell me on them before they ask me to spend an hour of my time.

<comment><USER51> I agree. I had an interview yesterday where they passed, and the reasoning was "You didn't seem interested in the job." And I sort of think that's hilarious, because nobody tried to sell me on the job. Nobody told me exactly what the job would entail. I never met the hiring manager, even though I was on-site for 5 hours. And clearly they weren't interested in me... It just seems weird that I have to be jizzing my pants to work for them, but they don't even have to try to sell me on the role.

And this goes doubly true for any company that reaches out to me first. Like, if I apply to your company, then yeah, you have an expectation of me being interested in the company. But if you reach out to me, then maybe you're the one who needs to sell yourself to me.

I don't really get that attitude by employers. Whenever I'm interviewing candidates, I really try to sell them on the role. I try to tell them what's awesome about it, why they should want to work here over literally anywhere else in the world, and why you WANT to sit next to us for the next six months and work with me and my team on projects. Part of my job as an interviewer is to not only gauge your ability and interest, but to convince you that we're the best place for you to be.

Or... do interviewers really think I selected their company is the only company I even considered talking to? We're engineers. We have options. You (the company) have to meet me at least halfway.

Incidentally, I've often wanted to ask my interviewers to solve a tech challenge. I don't want to join a company where the team is incompetent and I'm constantly cleaning up after them. Oddly, that's never a consideration that companies allow candidates... ;)

</comment></comment><comment><USER52> One thing I find interesting is the absolute conviction that every interviewer has that they got it right when the reject a candidate.

No "reject" decision can ever be reconsidered or questioned by anyone, ever.

<comment><USER48> If I were in charge of a giant company I'd hire every 50,000th applicant or whatever, just so we had a control to see if our interview process was worth the time.

</comment></comment><comment><USER53> At my company our engineers defined the following process.

First, we defined the skills we're looking for i.e. Programming / SysAdmin / Cybersecurity.

Our process goes as follows:

1\. We ask candidates to answer a quizz by phone, with questions in the 3 chosen fields. Duration = 1h.

2\. We ask candidates to solve remotely with Google Docs 5 real-world problems asking for skills in Algorithmics, Data Modeling, Object-Oriented Programming, Software Design, and Parsing. We also add a bonus question like "how many people can get into a train". Duration = 1h.

3\. We have a HR meeting at our office with a non-technical member of the team. Duration = 1h.

The quizz helps us to remove of our list the candidates that do not have the technical culture we're looking for, and to see what they already have worked on.

The 5 problems helps us to see how the candidates can code, the bonus question helps us to see how they approach new issues and manage their stress.

The final HR meeting is very typical: we try to see if we would be happy to take a 6 hours long flight with the candidate.

Most candidates do not go through first step, and roughly half on them do not go through second step.

This simple process definitely helped us to reduce the time spent on hiring and to make the really good candidates shine.

<comment><USER54> > how many people can get into a train

Can't speak for everyone, but I'd turn away and walked out the instant I hear this or similar BS (which is totally unrelated to "approaching new problems" or "stress management" in programming at least)

<comment><USER55> You're too forgiving. I turn down interviews when they list "linked lists, hashing, breadth/depth first search" on their study guide. I've never had to write a linked list EVER in my career, don't fucking bother me with that shit. Also, if the position is in a language where linked lists would be stupid (i.e. python), then I definitely reject that company.

I can explain what everyone of them is, and why you'd want to use them. But I've never written any one of them and I'm not going to spend the time to memorize something I can look up in my CLR book or stackoverflow.

It's embarrassing that tech interviewing is still stuck in a 1990s mindset.

<comment><USER56> I've written at least 5 linked lists in the past year. They're quite useful.

<comment><USER57> What were you using them for?

<comment><USER58> Not sure about GP, but very recently, an open-addressing hashtable that could be traversed in both reverse modification and reverse insertion time order. There are actually some interesting subtleties when doing this for open- addressing hashtables (i.e., entries (and pointers to them) move around when the table rehashes).

</comment></comment></comment></comment></comment></comment><comment><USER59> An alternative to an "interview" would be something more like an exam: have candidates try to solve a (relatively simple) problem in limited time, with or without external resources.

Candidates would be watched, would know they're being watched, but would not see themselves being watched, which would probably take a lot of stress out.

You could even test many candidates at the same time this way. And you could setup a system where each candidate could ask questions if needed, without being heard by other candidates (like in language learning classrooms).

This must have been tried? but I wonder why it's not even discussed in the post, as an alternative?

<comment><USER60> My current employer does this.

You're sat in the conference room, given a machine that has a screen monitor program running, and a set of tasks to perform on the code. You are told where to find the code in the introduction on the sheet of instructions. You are allowed to use any resource via the computer (so nothing you've brought in like a phone or laptop is allowed; basically, all work has to be "shown"). Then...go.

Outside the room, the dev team watches the process. We want to see how you go about each problem, what resources you use, etc.

It's always surprising the number of people who go for an hour or more and do nothing. Just sit there (or seemingly sit there - there's no keyboard or mouse activity).

When I interviewed, they actually gave me an online test; the job was supposed to be for javascript, but the online was in PHP (which my prior position used, and I had been using for years). Passed that, and came in for the on-site part. I thought it was odd that they first tested me for PHP. Did a bit of face-to-face interview, then they wanted me to do the watched javascript portion (single page app).

I first sat and read the problems, formulated some possibilities in my head, then jumped in. 30 minutes later I was done, and popped open a new file to write something to that effect (figuring if they were watching, they'd come back in). I sat for several more minutes, then they came back.

"How's it going?"

"Alright...umm, hey, I'm done."

"No way! Are you serious? Are you sure?"

Odd...

"Yes."

Apparently they had never had anyone finish the test that quickly, and get it completely right - especially someone who also had PHP skills, and had already demo'd them in the first test, which was also done correctly. I found this rather odd, as neither test was that particularly difficult.

Apparently, though, it's not uncommon in our industry. I'm not sure what to make of that...

</comment></comment><comment><USER61> > 9\. Make decisions based on max skill, not average or min skill

This is a strict specialist search - here, too you should make a decision depending on your requirements and future outlook: Do you need a generalist that can branch out and specialise, or strictly a specialist that only does the thing you need right now?

(Also let's not argue which is better, specialist or generalist - deep down, each of us already knows and made the choice ;) )

</comment><comment><USER62> You can ask someone to solve a rubik cube in under a minute.

Or you can ask someone to beat a Go bot that is ranked over 5 kyu.

Or you can ask someone to find adjacent zeroes in a matrix of numbers in under 15 minutes.

All those exercises, however tricky, do not correlate much with how smart you are or what your programming abilities are.

</comment><comment><USER63> Some engineers I interviewed got "offended" by ElonMusk-like questions and refused to answer :)

<comment><USER52> If you really ask questions like that then you shouldn't be allowed to be involved in recruiting.

<comment><USER63> Why?

</comment></comment></comment><comment><USER51> IMO, hiring is like a funnel. At the top of the funnel is the entire universe of people. At the bottom of the funnel is your hire. The goal is to filter out as many people as possible as quickly as possible. One key point is whether or not they can write code.

Keep in mind __writing code __is the _BARE MINIMUM_ required for a job. If they can't do that, they shouldn't be on-site in the first place. If you have your candidate taking a day off work and taking a day worth of engineering talent off engineering-related tasks, and you're spending that time asking them to write code, you've failed to apply the filter higher up in the funnel.

Ideally, you verify their coding ability BEFORE you bring them into the office, whether via a tech phone call, live-coding session, or take-home assignment. Before the haters start saying "but they can fake it!", hold your horses. Once you've established that the candidate can code, when you bring them on-site, you _quickly VERIFY_ your previous conclusions. You quickly _VERIFY_ that the coding assignment you gave them was completed by them. This should take no more than 15-20 minutes. Maybe you just have them walk through a chunk of code. Maybe you ask them to recreate their answer. Something. Anything.

But if you send in three different engineers, and they all spend the entire hour asking the candidate to solve programming tasks, you're literally evaluating the BARE MINIMUM of the hiring requirements. And there's so, so, so much more to being a good engineer than writing code.

Outside of a QUICK verification, your on-site questions, imo, should NOT be writing code (or even pseudo-code). They should be about previous projects, architecture, personality, professionalism, punctuality, communication, teamwork, autonomy, and collaboration skills -- all the non-tangibles that answer the basic question of "Do I want to sit next to this person for the next 6-12 months?"

If your idea of a good interview is to ask someone to generate a calendar between two dates or sort a list or find the minimum integer in a list, you're completely, totally missing the point. You're evaluating the bare minimum to get them in the door -- and if you're doing that in-person, you're wasting your time. You should have filtered that out before they walked in the door.

Remember, these candidates are often lying to their bosses and calling in sick or using up valuable PTO to take an entire day off work to come sit in your office. Don't waste their time with redundant tests and things that you could have figured out before they walked in the door.

(And dear god, some of the questions in these comments are... awful... at evaluating anything except, I dunno, getting the right answer. Yikes.)

</comment><comment><USER64> "There is not a single set of skills that define a good _programer_. ... No engineer can be strong in all _off_ these areas."

The ability to spell is one of them.

</comment><comment><USER65> I wouldn't use TripleByte to hire or get hired, but that was a well written article.

</comment><comment><USER66> I agree with much of this. Some additional comments:

> Ask questions as close as possible to real work: This is achieved by making > interview question as similar as possible to the job you want the candidate > to do (or to the skill you're trying to measure).

This "or" thing in parentheses is really important. Interviews should not be "as similar as possible to the job." They should be all about the skill you want to measure. And there's quite a difference between these.

People can be trained, assuming you have time and resources.

The point of standard algorithm interviews _is_ to measure a particular skill: intelligence. The belief behind this is smart people will tend to solve problems well in the real world. It's okay if they don't know all the skills they need; they can learn them. (And if there's a particularly challenging skill, then maybe you need to add that into the process.)

> Avoid hard questions: If a candidate solves a really hard question well, > that tells you a lot about their skill. However, because the question is > hard, most candidates will fail to solve it well. The expected amount of > information gained from a question, then, is heavily impacted by the > difficulty of the question. We find that the optimal difficulty level is > significantly easier than most interviewers guess. This effect is amplified > by the fact that there are two sources of signal when interviewing a > candidate: whether they give the "correct" answer to a question, and their > process / how easily they arrive at that answer.

You don't give examples of what qualifies as hard vs. easy, so it's a little difficult to judge this. But generally, I'd advocate for people asking harder questions.

When a question is easy, a little thing -- small point of confusion, etc -- can make a big difference in whether the candidate seems to have gotten to that answer well or not.

When a question is hard, this is when you can actually see a great differential between great vs. good vs. okay. You can offer help and see how effectively they pick up on that advice.

If your interviewers are just throwing out a question and then sitting back and seeing what happens, then yeah, candidates won't be able to tackle a hard question. But that's not what they should be doing.

To be clear here: hard does not mean "ask about some obscure data structure [skip lists, etc]." It means a challenging question involving common knowledge (hash tables, strings, arrays, maybe binary search trees).

> 5\. Ask every candidate the same questions: [...] there is no justification > for asking different questions to different candidates. If you evaluate > different candidates for the same job in different ways, you are introducing > noise.

I think this is overplayed a little.

If you're doing algorithm-style interviews, any question should be basically evaluating the same skill (problem solving skills). If I ask my favorite question and you ask your favorite question, but they're evaluating the same skill, then it doesn't really matter. There's nothing to make one question better than another. Why not let each interviewer ask the question that they like?

Now, if every interviewer asks a different question, you won't be able to give a well-defined metric on what good performance looks like for that problem. But that's okay. You can't really do that anyway.

When companies give well-defined metrics, they get too rigid. The candidate takes slightly longer to complete the code because the candidate thought things through more thoroughly, and now they're pushed into a lower performing bucket. And that's wrong.

These standardized metrics sound good in theory, but they don't work well in reality (for algorithm interviews, anyway).

<comment><USER25> So, we've gathered data on exactly these points over the last 2 years. And what we've found that the decision that gets the best signal is often not what feels most accurate to the interviewer.

For example, my guess before running these experiments would have been that simply looking at progress (how far a candidate gets through a problem) would be a bad measure of interview performance. I'd expect that things like style and how communication how careful a candidate was being would render pure progress a mad metric. However, when we compare pure progress to a subjective score the interviewer gives the candidate (ignoring specific reasons, does the interviewer think the candidate is a good engineer after the interview), we found that pure progress is more predictive of success at companies! (To be clear, we don't only look at progress at Tryplebyte. We've also found other things to be predictive.)

The same is true (among our candidates at least) for question difficulty. Easy, straightforward question (write a command line interface to store and retrieve key-value pairs) are more predictive of success at companies than question that try to target intelligence (calculate how much water would collect in a histogram)

<comment><USER67> Have you tried IQ testing instead of algorithm questions to measure intelligence?

<comment><USER48> There is no such thing as a single "intelligence". "IQ" is measuring at least three different forms of cognitive ability, is an inherently flawed and culturally biased tool and may be illegal to administer unless you can prove it's relevant to the work.

Additionally, what matters is not natural talent but the set of skills and techniques an individual has built up using those talents, compensating for their weaknesses and taking advantage of their strengths. I've met plenty of very, very smart people who flounder the first time they encounter a code base they can't hold entirely in their head at once: someone who was less "smart", with a smaller working memory, but who has been developing skill with abstraction and system metaphors since CS 101 is often a better actual developer.

The myth that developers need to be "smart" is pernicious, and the cause of most of the really horrific code bases in this industry.

<comment><USER68> > [IQ tests] may be illegal to administer unless you can prove it's relevant > to the work.

Not any more than any other means of assessment on which outcomes differ on a protected axis of discrimination like race; yes, the rule was first articulated in a case involving a fairly blatant use of IQ tests to effect racial discrimination, but it is by no means restricted to IQ tests.

</comment></comment></comment></comment></comment><comment><USER69> quiz != interview</comment>


Sprezzatura - <AUTHOR> http://sivers.org/sprezzatura <comment><USER2> That's a great word. It's really fascinating how certain words need a sentence-long definition when translated from other languages to English. So much is captured in one word!

And that's an incredible TED talk. I recommend to anyone who hasn't seen it that they watch it when they have a chance.

The best part in my opinion: "That's not what my creative process is - I'm not the pipeline! I'm a mule, and the way that I have to work is that I have to get up at the same time every day, and sweat and labor and barrel through it really awkwardly. But even I, in my mulishness, even I have brushed up against that thing, at times. And I would imagine that a lot of you have too."

<comment><USER3> That is one of the _best_ TED talks I've ever watched, and I've seen it many times. I read her book, "Eat Pray Love" and googled her, when I came across the TED video. If anyone reading this hasn't watched the video yet, please do.

<comment><USER4> can you explain more of the appeal?

(apologies, but i am going to explain my opinion here before waiting for you to answer. eit.)

i stopped watching 75-85% of the way through. i couldn't take all the "you know"s, "like"s and "um"s.

i'm not sure if the content wasn't appealing to me, or if her explanation was unexciting.

when i see great art or learn something awesome i feel something lift inside me. i have an emotional connection. this drew a blank.

i was a little surprised, since the blog post made sense to me. i agree with other commenters who mention have this fuzzy concept but not seeing it discussed in public much less defined.

for a "best" TED __talk __i'd recommend[http://www.ted.com/talks/jill_bolte_taylor_s_powerful_stroke...](http://www.ted.com/talks/jill_bolte_taylor_s_powerful_stroke_of_insight.html)

she's a good speaker. there are other excellent speakers, too.

maybe the "worked on 8hrs a day for 6 weeks" build up raised my expectations, but she sounded nervous, laughed at her own unfunny and irrelevant jokes, and didn't create anything wondrous or lifting inside either my heart or my head.

<comment><USER5> Perhaps it would be difficult to understand what she is talking about if you had never experienced similar personal dilemmas...

<comment><USER6> Indeed, the struggle with the process of creation, the fear of rejection, misunderstanding, failure, is at the core of many artists. I look at entrepreneurialism and hacking as forms of art too, so the topic is very on point here in my view.

But back to that vulnerability. As an artist, you can connect to that immediately. It's moving to hear another artist talk that openly and honestly about something so central to their existence. One of my favourite things she said was about being a mule. We're all mules. And we can be proud of the effort, of continuing to show up, regardless of the result.

I'm a fairly hard-line atheist (I am open to _actual_ proof ;), but there is something mystical about the eureka moment during the creative process. Sometimes it is a wave that comes at you when you hope to be ready, and you just try to catch it while you can. And several times I remember feeling the way she described the dancer becoming something more. I've seen that dancer before. Anyone who's created art for long enough has touched that, but as a logical person I'm almost ashamed to get that out-there describing my personal experiences. Hat's off to her for having the guts to do so and do so that openly.

</comment></comment></comment></comment></comment><comment><USER7> Somehow, it's fabulous to have words for concepts you've fuzzily known about for a long time.

</comment><comment><USER8> The TED talk mentioned reminds me of "You and Your Research" by Richard Hamming: <http://www.cs.virginia.edu/~robins/YouAndYourResearch.html>

Hamming asserts that people who have done great work fail to "plant acorns." They chase another great revelation instead of stepping back to the fundamental level where they started, and spend the rest of their life only working on great problems, not useful subproblems. I see no reason an artist's success would be different.

</comment><comment><USER9> As someone who as explored both "creative" pursuits such as art and the technical pursuit of coding, i explain to my techie but creatively challenged friends that pursuing art is like hacking your brain's kernel while it is running. A bad line of code can bring down the entire OS. It might be why traditional creatives have the reputation of being unstable. You can't really take your brain offline and debug if something goes wrong with refactoring your aesthetic assumptions. If a creative is hacking their visual identity, they can get to look pretty weird through the major releases and might require several dot releases to look "right."

But then we encounter the creative coder. Those people are freakiest of all and for that we are all better off.

</comment><comment><USER10> I'm not sure I like the idea of inventing external imaginary beings that grant us extraordinary powers for no other reason than _it makes it easier_ to accept those powers.

It seems dishonest.

<comment><USER11> Are you advocating total awareness of the world? Total immersion in both refulgent horror and terrible wonder? Constant consideration of ounce of harm you inflict on the world around you? An unclosing eye toward this miracle of entropy we call home? Unending empathy toward every single person you pass and even those you never meet. Total awareness that your own personal self has quite possibly culminated and now has only got forty years of slowly turning to dust.

At some point you've got to shield your eyes; or, put it differently, find an interpretation you're comfortable with and settle down. Who can claim to not lie to themselves every day just to put their next foot forward? Even if you can see the honor, the honesty, in living that way I highly doubt you can survive.

If you can, write a book about it. I think David Foster Wallace tried.

Life isn't science. If you can go to a museum and enjoy the paintings, you can embellish the way you interpret your own sight. And if you're going to do it, why not pick a beautiful story?

<comment><USER10> I'm not advocating total awareness, though that would be cool and it is achievable according to some philosophies. I'm advocating the pursuit of an honest interpretation of the world. We know there aren't little trolls living in our walls that grant us creative powers. We know that isn't true.

I believe it is possible to be aware of our impact on the world, even negative and continue to live. On 60 Minutes tonight there was a story about a recycling center in Colorado that was illegally shipping used computer monitors and televisions to Hong Kong. People there disassemble them and in doing so pollute their environment and damage their health.

But I'm using a computer. There are two monitors in this very room. My behavior indirectly harms the world. I am aware of that. Perhaps I am adding a bit of negativity to the world, but that doesn't mean I should choose ignorance of that. It doesn't mean I should invent a little troll in the wall that is actually creating that monitor.

I think it is okay to acknowledge the accomplishments of the creative. I think it is okay to accept responsibility for the good that we create and the harm that we inflict.

I'm advocating honesty and pursuit of truth. Sometimes that requires that we forgive ourselves for that which we do that harms others. Those apologies can be truthful as well.

<comment><USER11> Can you say there _aren't_ trolls in the walls that grant us creativity? Can you assume that genius still happens in a vacuum? Can you hope to describe these things fully, attribute it to humanism? Perhaps the human achievement is in becoming an antenna for the inspiration of our chaotic world?

I mean, no. I don't advocate intentional blindness to problems in our world. I would even go so far as to actually advocate a greater awareness of the weight of our impact in the world. We can learn something from knowing more what the impact of a dollar is.

But humans are nothing if not machines for selective attention. If every time I bought my lunch I thought about the fertilizers dripping into the ocean causing immense algal blooms full of asphyxiated fish and oh the smell! I'd probably starve.

If your life, the thing that puts you closest to your own understanding of divinity, is being creative; if you honestly have to face the idea of never being able to communicate like you did that one time not so long ago; if you have to keep going in face of that, well, I know what I'm _not_ going to expend my attention toward.

But even so, the speech wasn't about finding ways to ignore some nasty personal tragedy. _It's about finding an interpretation on the charity and capriciousness of the creative process._ What really is the best way to contextualize the immense amount of discipline and work and training that goes into creation that can all amount to precisely nothing without something widely considered to be external to us?

Genius is 99% perspiration, 1% inspiration. Even when we can assume the sweat, we're still might end up short one spark. What gives?

(I apologize for the waxing here, but god this is such a fascinating philosophical question.)

</comment></comment></comment></comment><comment><USER12> Might I recommend going back to the source on "sprezzatura"? [http://www.amazon.com/s/ref=nb_ss_0_11?url=search- alias%3Dst...](http://www.amazon.com/s/ref=nb_ss_0_11?url=search- alias%3Dstripbooks&field- keywords=castiglione+book+of+the+courtier&x=0&y=0&sprefix=castiglione)

</comment><comment><USER13> pronunciation (the red loudspeaker icon) <http://www.merriam- webster.com/dictionary/sprezzatura>

It's quite hard to pronounce, but the speaker makes it sound easy.

</comment><comment><USER14> <http://news.ycombinator.com/item?id=470695>

</comment><comment><USER15> This is brilliant.

</comment><comment><USER16> Kobe Bryant is the best example of sprezzatura in sports, especially when you see him drive to the rim with four defenders on him. Kobe also speaks italian.

<comment><USER17> Agreed. This account of his 4am workouts and non-stop icing routine on gameday is truly inspiring:

<http://sports.espn.go.com/espnmag/story?id=4068270>

I like Kobe more than Lebron more for this very reason. He compensates for his relatively inferior size with superior work ethic.

<comment><USER18> His work ethic is legendary (and rubbed off on Lebron at the Olympics last summer). FYI, Kobe is 6'5" which is exactly average for NBA shooting guards.</comment></comment></comment>


A Black Man Walks into the San Francisco CTO Summit… - <AUTHOR> https://medium.com/@shaft/a-black-man-walks-into-the-san-francisco-cto-summit-fbbc7474430e <comment><USER2> The crickets in that audience must have been deafening. What was the correct course of action for the conference organizers? Does registering require you to submit your gender/ethnicity? How do you know when you need to course correct for inclusion? Is that responsibility on the organizers?</comment>


Social Marketing Startup Badgy Raises Angel Round - <AUTHOR> http://pandodaily.com/2012/07/11/badgy-raises-angel-round-from-mark-cuban-for-social-marketing/

<comment><USER2> From the entrepreneur's perspective, I found Pando Daily's writer to be very professional, and very intentional about building good context around our story.

Also enjoyed their interest in a story in Atlanta, which has a good startup culture rolling, outside of the usual "startup cities".

<comment><USER3> Honestly I was pretty impressed with their writing even before this story. Glad to hear that they treat folks well. A welcome departure from the way other folks in that industry act.</comment></comment>


Monstrous Moonshine - <AUTHOR> http://en.wikipedia.org/wiki/Monstrous_moonshine

<comment><USER2> I wish I understood any of that, because it does seem like it would be fascinating :)

</comment><comment><USER3> why?</comment>


The Gambler's Fallacy of Customer Loyalty - <AUTHOR> http://handshakez.com/the-gamblers-fallacy-of-customer-loyalty/

<comment><USER2> I really like this post, but I think the take away from the Gambler's Fallacy is something different... I think it says a lot more about causation. Like the reason it should land on red is because it landed on black before this... you were close with your examples but I think it really says something more about believing that the reason A is happening because of B when really it isn't that clearly linked.

<comment><USER3> Great point Articulate! It's certainly true that causation (or, with the Gambler's Fallacy, falsely-presumed causation) plays a part in the post, but at the same time the importance of statistics cannot be overplayed. The correlation between preexisting and current trends is strongly emphasized; this can lead to that falsely-presumed causation you mentioned, and that in turn can lead to people treading water and ultimately failing. We're both in agreement that A doesn't necessarily equate to B though, and that's the overarching message behind the Gambler's Fallacy in sales and business. Just because a customer has bought from you before doesn't necessarily mean that they'll buy from you again; you need to wow them by being obsessed with them and their problems.</comment></comment>


Why does Adobe Acrobat take 15 minutes to open a PDF? - <AUTHOR> I do a lot of graphic design work. I have over 2,000 fonts. (Yes, I do use them.) Adobe Acrobat routinely takes 10 to 15 minutes (I'm not exaggerating) to open up a PDF file, whether it uses 1, 2, 10, 100 or no fonts at all. According to FileMon from Microsoft, it's because Acrobat loads every single font on my system before rendering the file. This makes no sense--especially because if I were to actually try to use one of those fonts not already embedded in the document by editing the file, it would re-load them all over again.
Some time is also spent reading and updating a local MySQL database called the "organizer." I've never used the Acrobat organizer. Not once. I suspect 99.999% of Acrobat users don't even know it's there, yet every time I open a PDF, I wait for it. There's no way to clear it except by manually locating the files it uses on your filesystem and deleting them.
Unrelated but equally infuriating: Acrobat insists on printing 100% black rectangles (meaning 0% C, 0% M, 0% Y, 100% K) as a mixture of C M and Y ink on my Xerox Phaser 6180MFP/N color laser printer. Illustrator prints the same exact PDF file properly using only black ink on the same printer.
Can someone from Adobe explain to me why this is reasonable? I've paid Adobe thousands of dollars over the year for its products. When can I expect to open a PDF in 2 seconds or less like I could with Acrobat 3.0 on my 100MHz Pentium ten years ago? When will Acrobat actually work?
(Before you say, "Use Preview!" know that I've already tried. It doesn't render my PDFs properly. It rasterizes things that shouldn't be rasterized and it draws lines that aren't there. Adobe made the PDF spec, I like PDFs, and I want to use Adobe's software.) <comment><USER2> This is Ryan Damico from crocodoc (YC Winter 2010), an online app for marking up and reviewing PDF files (as well as other document types). One of the reasons we started crocodoc is that Adobe's tools for working with PDF files (including Reader) are way behind the times (e.g. slow, desktop based, difficult to collaborate).

That said, crocodoc is still early in development and has some kinks of its own we're working on, but we think there's a lot of room for innovation in this space. Would love to hear any feedback!

crocodoc demo: <http://crocodoc.com/demo>

<comment><USER3> Cool concept, marking-up documents is big business. Legal depts we negotiated licenses with would _always_ do it by emailing a Word doc, with its diff/review feature that looks very nice, and comments. My book publisher also used it for reviewer feedback.

Unsolicited feedback: It looks beautiful!

It's _much_ slower than google gview and scribd (but they don't allow annotations, so it's apples/oranges... but still). Why don't you pre-scan the demo document? I know it's cheating, but it gives a better first impression (and, to me, it would feel reasonable if my own document took a few moments longer to process than the demo. Best foot forward etc).

I wish you'd have an "upload doc" textfield prominently on the demo page - without it, I assumed you had to open an account; it was just luck that I happened to read the FAQ saying that you could. But it didn't say how, so I'm scratching my head. Luckily, I tried going to the front page, there it was. You're making me think too much, just to get started, which is an easy place to lose someone: I think you're losing trials by not having it on the demo page either - that's the natural place for a "load" document.

Also, Your style of upload file/URL form is popular, but I really think there must be a better way! Perhaps one textfield, with two buttons (upload and file browse). You enter your doc, file or web, and the uploader sorts it out; the file browser is just a convenience. Maybe also have a google search, if people don't have the URL immediately on hand (must be a common case).

<comment><USER2> Thanks for the constructive feedback -- your comments are very helpful. If you ever feel like telling us more about what we can do to make crocodoc a no- brainer to use, drop us an email through our site :)

</comment></comment></comment><comment><USER4> Also, why is there always a new version of Acrobat Reader to install? Also, why does adobe launch a relatively huge app to detect and tell me this whenever I'm in the middle of doing something important. It's like it knows "Oh, the system is under a lot of load already, I should fire up now since the user is clearly at his computer"

I only have Adobe Reader installed to handle fill in form apps (IE, passport renewal). In the past, I've manually deleted the adobe autoupdater from my system to avoid the slow downs. It's worse than spyware.

<comment><USER5> I use foxit, for generic PDF viewing, also SumatraPDF is a whole lot quick too. I've never installed Adobe Reader in over 3-4 years and haven't missed it so far.

<comment><USER6> SumatraPDF is fantastic. Fastest PDF viewer I've ever used.

<comment><USER7> Sumatra is nice, but Preview on OS X is even faster. It loads PDF documents as if they were text documents.

</comment></comment></comment></comment><comment><USER8> It appears Adobe isn't interested in making software anymore. Flash is slow, Acrobat is slow and Photoshop will refuse to work for completely arbitrary reasons (like having a case sensitive filesystem).

Guys, looks like Adobe could use some competition :p

</comment><comment><USER9> Check couple of things:

\- Use procmon, not filemon - enable durations.

\- Use dependancy walker, load the acrobat executable from there. Check all checkboxes on. Press F7

<comment><USER10> Hey, can you expand on the tools to be used for investigating a resource hog? Bit off topic, but I feel that my system crawls with Firefox or Chrome in spite of having 4 G of RAM. How do I go about investigating what is the actual bottleneck?

<comment><USER9> Hi paraschopra,

There are many tools, depending on what you are doing (io, network, memory, cpu). In my case, the problems are with the tools written by us for our studio, so we just use our own profilers that the tools are compiled with (check DEJA, DressCode).

It's only for code where we don't have source code, or we don't have time to put profiling probes then we use external tools - for example VerySleepy for sampling, or some of the SysInternals tools.

But sometimes the answer is just few clicks of google, or serverfault.com / userfault.com, etc.

</comment></comment></comment><comment><USER11> Well acrobat loads not just fonts but a whole bunch of plugins, some of them unused or unnecessary for most users. If you remove those plugins (you will have to manually delete them from the acrobat folder - Google for it), you should notice a dramatic increase in loading times. (I have tried this and it works as advertised)

</comment><comment><USER12> Seems like Acrobat jumped the shark a few versions back.

It's a monster.

Sounds like you need to use some font management software, though, which will allow you to load up sets as you need them, rather than having them always available.

<comment><USER13> Actually recent versions of Acrobat have been rather snappy for me.

+1 for font management software. Yes, its a hackish solution, but if it works, then...

<comment><USER14> Yes, recent versions are snappy. I run Acrobat Pro 9.3.2 on Mac OS X and launch time isn't an issue. Acrobat delay-loads plug-ins, so the plug-in issue is mitigated.

I don't doubt the font-induced launch time delays, however. I think I've heard this one before.

Did you report the printing bug to Adobe?

</comment></comment></comment><comment><USER15> Don't know about the color printing issue, but I use Sumatra PDF reader instead of Adobe Reader for 95%+ of my PDF reading:

<http://blog.kowalczyk.info/software/sumatrapdf/index.html>

It's free, and it's light, and it's fast. And it doesn't bother you at inopportune times asking whether you want to upgrade. Given that, why would you want to use Adobe's software?

Every now and again a document won't render correctly, and then I'll use Acrobat Reader--which sometimes also fails to render it correctly. But what can you do.

<comment><AUTHOR> Well, it's not two-seconds fast, but it's better than 15 minutes. Thanks!

<comment><USER16> Huh?

 _Before you say, "Use Preview!" know that I've already tried. It doesn't render my PDFs properly. It rasterizes things that shouldn't be rasterized and it draws lines that aren't there. Adobe made the PDF spec, I like PDFs, and I want to use Adobe's software._

I thought you were running OS X, and that alternative PDF viewers didn't work for you because they didn't adhere to the PDF specs as strictly as Acrobat.

<comment><AUTHOR> I didn't say that. I'm running Windows on my primary machine and Mac OS on my office machines. Preview in particular doesn't do a very good job.

</comment></comment></comment></comment><comment><USER17> <http://dearadobe.com>

</comment><comment><USER18> Adobe bashing is quite a trend but in this case I'm pretty sure that it's not Acrobat per se which causing the slowness. Last time when I've seen a similar case some corrupted fonts were the core of the problem, but your hardware setup, OS, filesystem, number of files are also more likely to blame than Adobe.

</comment><comment><USER19> Try to use foxit reader (<http://www.foxitsoftware.com/pdf/reader/>) It's ultra fast. I use this product for a couple of years and forgot about the acrobat reader as a nightmare.

</comment><comment><USER20> Use a small trusty that does not phone home:

<http://www.oldversion.com/Acrobat-Reader.html>

<comment><USER21> ... and is full of known security holes. No thanks.

<comment><USER22> The OP is using Acrobat for graphics design, not for online-PDF reading. I don't think he has to worry about security holes that he or his coworkers can exploit.

<comment><USER23> But you have to actively disable the plugins Acrobat installs for online reading or else your browsers are wide open. Lots of bad sites (and ads) launch malicious PDF files that you never see.

</comment></comment></comment></comment><comment><USER24> Seems like you forgot to open scanned PDF files. It will take years to scroll one page.

</comment><comment><USER25> I think this was one of Zucker's feature requests.</comment>


Browser Wars Revisited - <AUTHOR> http://royal.pingdom.com/2013/03/21/browser-wars-2013/

<comment><USER2> I switched from Chrome to Firefox... tab groups, the extensions available, and actually being able to save and sync my search keywords across computers (instead of being stuck with a 2 yr old settings) are some big features for me.

Oh, also that Greasemonkey itself is very easy to use.

I might consider trying out Opera again in the future, since its mouse gestures are very responsive and the interface looks nice (to me). However, lots of web pages didn't render properly for me the last time I used it (3+ yrs ago)

<comment><AUTHOR> Me too. I switched back to Firefox after 2+ years using Chrome. But it's more because I like Mozilla's way of doing things, principles and filosofy. And I'm trying to avoid stuff that companies like Google offers.

<comment><USER3> I switched from IE to Firefox and, looking back, I don't regret it, for the very same reason. Mozilla is the only non-profit and Mozilla is by far the best FOSS browser. Besides, Mozilla keeps pushing for new and better schemes and is one of the few companies that won't track your web usage.

I just wish more people knew about these. Most people just look at the speed with one tab open and pick Chrome.

</comment></comment></comment><comment><USER4> The article really tries to be serious, with lots of charts and data. But they are all from StatCounter. There is an endless debate about which source of browser market share is best, and no clear answer, so why consider only one?

</comment><comment><USER5> I find it very annoying when I try to open a site and it says something like:

"Why the hell are you using IE? Please switch to a modern browser and come back later!".

It turns out I'm not using IE, I'm using Chrome configured to say it is IE (user agent) because the company I work for has a proxy that only answers to IE...

</comment><comment><USER6> The only thing that really matters is your site's audience. Our site has Safari in the lead at 39% (IE 24%, Chrome 17%). So, StatCounter's data is interesting, but Chrome is the least important to us.

</comment><comment><USER7> Please get rid of IE8 - ugh, hate to see that many still using it - doesn't look like I can drop support for awhile

</comment><comment><USER8> Isn't Opera missing here? I heard lots of people in Russia used it, at least about a year ago.

</comment><comment><USER9> Any Opera user here? What are the key reasons for you to choose this browser over the others?

<comment><USER10> Spatial browsing, fit to width, and being able to disable images easily.

</comment></comment><comment><USER11> I would be surprised if Chrome isn't the #1 browser in North America a year from now.

</comment><comment><USER12> I feel a bit sorry for Firefox here. They're doing things right but they cannot really compete with Chrome on a equal footing because Chrome gets bundled with almost every Java and Flash update and those are installed on 99%+ of PCs. Not to mention being pushed on high traffic sites like Youtube and Gmail and being bundled with some PCs by paying the OEMs.

I remember switching a lot of non-techie friends/family to Firefox but I see them using Chrome now. When I ask about Firefox the answer almost invariably is that they didn't know how Chrome got on their PC.

Site owners get as much as $1 per Chrome download that they're able to push their visitors to. I don't think Firefox has these kinds of resources against Google trying to minimize how much they pay Firefox by cutting down the middle man and building a moat around their search engine and ad profits. The next good search engine to come by will certainly not be the default on a large percentage of browsers.

<comment><USER13> It's not as straightforward as "they're doing things right." As a Web developer I have all the major browsers installed, and even in that fair fight I prefer Chrome.

There are certain things I like about FF better, but Chrome's minimalism really appeals to me. There are only two total rows of UI elements and each row contains only the bare essentials. I love that.

I won't speculate on others' reasons for switching, and certainly bundling has served Chrome's market share well, but I can't really feel sorry Firefox is lagging when I don't even personally prefer it on the merits.

<comment><USER14> Chrome's UI is also completely and totally inflexible. As you can see in this screenshot, <http://i.imgur.com/D8rMRBa.png> , my firefox's UI takes up less space and is only two rows. Chrome has three rows (the close/max/min buttons, tabs, and navigation). There is no way on windows to reduce that top height. Firefox is flexible enough that you can trivially do what I have with only some simple css. The defaults for firefox are roughly as minimalistic as chrome too. Also, on my linux box my firefox is thinned down even more, while chrome just looks horribly out of place since you can't alter its appearance to closer match the native environment.

I prefer firefox for quite a few reasons, but since you bring up the UI, that's the only one I'll mention here.

<comment><USER15> What windows is that? In windows 7 the tabs touch the top of the screen. You can't get any more minimal than that.

<comment><USER16> On my Windows 7 there's a big huge bar behind the tabs. (This was also there on OS X, and that's worse because of the OS X menu bar which is unremovable)

I really really want an easy way to squidge that background bar down a bit.

</comment></comment></comment></comment></comment><comment><USER17> They should've stated that the data comes from StatCounter upfront. I thought they had their own metrics.

Pasting from an earlier comment:

One big difference is that NetMarketShare tries to measure unique clients, while StatCounter measures web page hits.

Since the power users browse (probably a magnitude of order) more web pages than the normal users, Chrome and to a lesser extent Firefox is overrepresented in power users who browse a ton.

Toothpaste marketshare analogy. It's possible that 70% of people use Colgate and 30% use Crest, but Colgate sales by volume are only 40% vs. 60% for Crest, since Crest users tend to brush more daily and use more of the toothpaste when they do for some reason.

Or a car analogy: Toyota sells 40% of cars and Honda only 30%, but 60% of miles driven on roads are by Honda cars since they use it more. Which has a higher marketshare?

<comment><USER18> It depends what you're interested in.

"Market vs. Usage share" is a debate that rages every time these numbers come out. It's really apples and oranges. For me, market share is an interesting piece of trivia and usage share is a snapshot of the zeitgeist of more heavily engaged users. Which one matters most to you as a developer?

</comment></comment><comment><USER19> I can't tell you how many times I've told myself that I wish IE and FF would just die. One day, I'd love to just focus on building for Webkit and not have to worry about supporting all these other engines.

<comment><USER8> I can't tell you how many times I've told myself that I wish Chrome and Safari would just die. One day, I'd love to just focus on building for Gecko and not have to worry about supporting all these other engines.

Though I agree a single render engine would make things easier for most front- end webdevelopers, I'm not sure whether a monopoly is such a good idea.

<comment><USER20> I can't tell you how many times I've told myself that I wish Webkit and Gecko would just die. One day, I'd love to just focus on building for Trident and not have to worry about supporting all these other engines. Though I agree a single render engine would make things easier for most front-end webdevelopers, I'm not sure whether a monopoly is such a good idea.

;-)

Actually writing for STANDARDS would be a better idea....

<comment><AUTHOR> I can't tell you how many times I've told myself that I wish the INTERNET just dies. One day, I'd love to just focus on having a good real life and not have to worry about all these "virtual life" things.

Sorry for the joke but, sometimes, it is really what I think. =)</comment></comment></comment></comment>


Feedback on my music start up :) - <AUTHOR> http://songfountain.com/ Better url to start with: http://songfountain.com/site_feed <comment><USER2> First impression:

To be honest, the site itself looks a bit amateurish -- weird or no padding in the text boxes, cut off tags that don't fit into the .tags div, usernames sticking out of the boxes (at least in FF on a mac), eg. <http://songfountain.com/discussion/749>

The Site Feed arrow is below the fold on the home page, so my first thought was I have to register to even browse the site -- you might want to promote the feed more prominently to engage visitors before you make them join the site.

Your tagline ("Song Fountain is the most effective way to discover new music!") sounds too much like a marketing claim, especially since the site doesn't look to be a major player and it's hard to believe it's more "effective" than last.fm or Pandora.

In the video you're describing the functionality of the site like you would in a technical manual. You might want to try to talk from a user's perspective ("How do I achieve this and that with Song Fountain?").

So there, that's my first impression. What are your plans about the site? Is it a side project (for fun, not money) or do you want to make it big with it?

<comment><AUTHOR> Thanks a lot for the feedback, yeah the layout is in progress. Showing the feed at first could be better for people to see first. I'll work on the video too lol. It's serious.

</comment></comment><comment><USER2> Have you seen Dalton Caldwell's talk from Startup School 2010?

Part 1: <http://www.youtube.com/watch?v=pshTi9dk7Bw>

Part 2: <http://www.youtube.com/watch?v=TphryAOyY40>

In short: we all think creating a music startup is a fantastic idea, but it really isn't. :)

</comment><comment><USER3> The use of "information highway" in your text is a bad idea. It's a cliché that makes your site seem dated.

Also, the UI on the search dropdown doesn't make sense. You select a field to search, but then if you start typing in the box you can't remember what field you're searching anymore. Maybe you should just use a normal dropdown instead of rolling your own.

<comment><AUTHOR> Yeah it is a bit corny lol. Thanks, yea that can be confusing.

</comment></comment><comment><AUTHOR> Better url to start with: <http://songfountain.com/site_feed>

</comment><comment><AUTHOR> This is very impressive!</comment>


Ask HN: Can applications have a built-in VPN? - <AUTHOR> <comment><USER2> What kind of applications, on the desktop, on mobile, on the cloud?

Do you mean something like a forward proxy?

[https://proxy.org/](https://proxy.org/)</comment>


Show HN: Jsonf a simple tool to reformat JSON in a pipe-friendly way - <AUTHOR> https://github.com/AndrewGuenther/jsonf

<comment><USER2> Neat!

For the sake of completeness, I feel like I should mention jq ([http://stedolan.github.io/jq/](http://stedolan.github.io/jq/)), which covers similar ground quite expertly. It tries to stick to to its own query language though, rather than exposing the structure of the data to other programs. There might be use-cases for combining the two?

<comment><AUTHOR> I actually built this out of frustration with jq. I've been looking for something similar, but I wanted something that followed the "do one thing and do it well" philosophy and would play more nicely with other tools. jq on it's own is basically the end of the line since it gives you the same difficult-to- process format out the other end.

That being said, I can definitely see the two being used together. Pipe jq output into jsonf and you now have output that can be fed into other tools much more easily.</comment></comment>