Questions to ask a company during a job interview - <AUTHOR> https://github.com/viraptor/reverse-interview <comment><USER3> A problem that I've had is that every company says that they value code quality, emphasize developer growth, value developer's technical feedback, etc. even if they don't in practice. I've debated taking a page from old school behavioral interviewing and asking questions like:

Tell me about a time that you made a decision to improve code quality or architecture at the expense of a deadline.

Tell me about a time that you invested resources into an engineer's technical development even though there would be no immediate, short term benefit to the company.

Tell me about a time that you pushed back on a decision from business or design because one of your engineers said that it was the wrong technical decision.

<comment><USER4> I came here to say basically this. I've worked at enough companies to know that their ideas of what their values are may not be accurate.

Instead of asking about values, ask about behavior. No one is going to say no to "Do you value code quality?" Aking what they've done (and sacrificed) to support code quality will give you a better idea of what their relative values are.

Asking about their tech ladder will get you an HR answer. Asking "Who was the last person promoted to X? When?" will give you a better answer. And if they can't remember the last time, that's an answer in itself.

<comment><USER5> I listened to a podcast recently [1] that talked about "embodied knowledge", which is basically the idea that what we know is often very different from what we think we know.

The idea being that you will learn much more about someone / something if you ask questions that are anchored to a time and place rather than generic "unembodied" questions.

So the first question you list "Do you value code quality?" is an "unembodied question" and there is no hook for the person to dig into reality and give you an honest answer.

The second, "Who was the last person promoted?" is "embodied" in that it is anchored in time and place. And because of that, a person is going to use their memory, rather than their rehearsed "value system" answers.

Anyway, it's basically exactly what you said, but I just wanted to recommend that I thought the podcast was a worthwhile listen.

[1] [https://www.thepermaculturepodcast.com/2019/1912/](https://www.thepermaculturepodcast.com/2019/1912/)

<comment><USER6> Without having listened to the podcast, another way to frame this is using the concept of yes/no questions, who/when/what/why/how questions, and open-ended questions.

Y/N questions are not very revealing and are likely to lead to dead-ends in the conversation.

WWWWH questions reveal a specific bit of information, but can also lead to dead-ends.

Open-ended questions ("Tell me about...", "What do you think of...", etc) will foster good conversations and uncover new threads to pull. In my experience, this is by far the best way to interact with other people, whether they are interviewing you or not.

Coming up with good/relevant questions on the spot is a skill that can be difficult to master, but is extremely valuable.

<comment><USER5> To expand on this, people will commonly give you unintentional "hooks" for where you can go to increase the depth of the conversation.

For example, people use common words as short hand for many things ("Work was stressful", "The kids are being a pain", "We had a really nice weekend"), and a mistake people run into when talking with others is that they assume the person they are talking with meant they same thing they themselves would have if they had used that phrase. This leads to lots of people "listening but not understanding".

So basically, offhand comments and common phrases are a great place to get a person to dig in deeper into their feelings on a topic. Usually they indicate something that is on the person's mind but that they probably haven't worked through enough to put into words. That means you will get a much more raw and unfiltered response from them.

Also it's always good to remember that people _love_ to talk about themselves, even if they say they don't.

</comment></comment></comment></comment></comment><comment><USER7> I've been interviewing with Google since 2006 or so, off and on, though I've never accepted an offer from them. I do this because I always learn several things from the rigorous on-site interviews, it's a lot of fun, and the machine that runs the process seems to not mind being turned down in the past.

Back in the beginning of that time period, I used to ask (fairly jokingly) the same question: "How many servers do you have?" I would use the response to gauge the interviewer, and mostly just for fun.

Of the dozens of Google interviewers I've spoken to over the years, only one responded with a number range, and the rest of the responses were largely grouped into either active playful discomfort.

In my last two rounds of interviews (with various companies, including Google), I asked three questions:

1\. What brought you here?

2\. What keeps you here?

3\. What keeps you up at night?

The responses to those three have been illuminating.

<comment><USER8> > Of the dozens of Google interviewers I've spoken to over the years, only one > responded with a number range, and the rest of the responses were largely > grouped into either active playful discomfort.

That's because most employees don't know, and the ones who do, know that it's a company secret.

<comment><USER7> Sure, I never expected a real answer.

</comment></comment></comment><comment><USER9> In my experience it's important to not ask "easy" questions that can be answered by a simple yes/no.

Instead of: Are you friendly to remote work? Ask: Will I be working with anyone who is remote, or who works from home on a regular basis?

Instead of: Is the work life balance good? Ask: How responsive are people to emails/Slack over the weekends and after 6pm?

Instead of: Can I have a good career path? Ask: Did any of your senior engineers start out as junior engineers here?

<comment><USER10> I've never asked it yet, but I've been thinking along these lines, and for the last one I think a good construction is "Do you work with anybody who was hired under a different title than they have now?"

</comment></comment><comment><USER11> One I am going to start to ask is "Are all developers allowed to have local admin access of their computers?" I've struggled against this in my last 3 positions. This is a dealbreaker for me, and should be for all developers.

<comment><USER12> From an infosec professional perspective, this one is always a challenge for security sensitive places.

I agree with you that developers need admin rights on their development machines, but I have witnessed first hand why many companies attempt to take away local admin rights.

When I'm responding to security alerts where developers have downloaded random .dll files from the internet, or some "troubleshooting utility" that is actually malware, it doesn't take long until the local admin conversation comes up.

This is one of those classic "technical solutions for bad human behaviour" scenarios where a small number of idiots ruin it for everyone. If you want local admin as a developer, then we need to be able to trust that you aren't going to do something stupid.

It seems the best way to do this is to issue developers multiple boxes (corporate laptop + dev box only for dev), and or use a good software whitelisting program that tracks elevations & the reasons for them, instead of just blanket giving everyone local admin on their own PC.

<comment><USER13> As a person whose straddled infosec and development, I always struggled with this. The multiple development machines is probably the best approach, but I've never truly seen it implemented correctly. I would love to not need admin access to my machine, but each time the companies I've worked for try this, it's always a struggle to do anything. This is everything from, "I need to modify/monitor core components of the operating system" to "The development tools came out with an update that needs to be installed." Most of the time, the response I've received was, "Enter a ticket, and we'll get to it." Often management seems to understand, "I'm waiting someone else" as "I'm behind, I'll work the weekend." You're right the downloading random things from the internet is an issue. Sadly I think a lot of this can be solved by the organization spending the money to buy all the needed tools and evaluate the correct open source ones, but there always seem to be budget and time constraints.

I think a lot of this stems from the fact that most of the managers in infosec for companies aren't developers and haven't ever been one. They really have no idea what developers really do. I'm not belittling them. It's just not the career path they took to get where they are. It's difficult to explain to them how frustrating being hindered is, and this causes a lot of good people to just leave an organization like that to find something better.

<comment><USER14> IT security people also have different incentives. If developers got bonuses for uptime while being compliant with all security policy requirements, while security and operations got bonuses based on features reliably delivered, you would have different results.

</comment></comment></comment></comment><comment><USER15> For many years I gave a talk titled "Questions Engineers _Should_ Ask"

This list is missing the two _most_ important [busines] questions:

1\. How do you make money?

If you can't understand, or the interview can't explain, then I'd run away. This can also lead to interesting questions about risks, competitors, etc.

2\. What's preventing you from making _more_ money?

The answer that you want to hear is _engineering_ _effort_. If not, you're (at best) a wallflower at the party. Don't be the chump that's at Goldman Sachs acting as a code monkey for the traders. Don't be writing code at a company (like Enron) which has its success based on digging holes in the ground.

I can dig up the slides if anyone is interested.

<comment><USER16> That's highly disrespectful to software engineers working outside of software companies. There are many of them and they are not necessarily less smart than others.

Working in the profit center of a company is often enviable, but let's not forget that cost centers in large companies can also offer benefits in things like work/life balance.

<comment><USER17> I don't think the GP intended to call engineers at those kinds of companies lesser. I think the point that was made was that working at companies where the company makes more revenue by having better software is a better company to work for. If your role is a cost you're treated (explicitly or implicitly) as such. It's a lot easier to show your value to a company by being part of the revenue side of the equation. Reducing costs is great but there is a bias towards investing to generate revenue vs investing to reduce cost.

<comment><USER18> \--companies where the company makes more revenue by having better software.

You can get vibe of a company by asking if IT is seen as a cost center. If software is a competitive advantage you know that it's green pastures for your and yours. But places where culture holds back engineering, like being slow on the uptake of GIT or CI/CD which is often talked about online, these are places to be wary of. Those latter companies are either going to have growing pains or will die out as digitization starts to take them on.

<comment><USER17> I think this may be a better way to phrase what I was thinking. It doesn't have to be directly related to revenue. The revenue relation just makes it easier to be counted as core to the business model. I think it's important to say business model too. IT is core to essentially every business now, but when IT is core to the how the company fundamentally positions itself in a market it really changes things.

Though in the context of this thread, I don't know a good question to ask in an interview to tease out that information when it's not already clear. If you simply ask "is IT/engineering considered to be vital to the business model or core to company success", everyone will answer yes regardless of how the IT/engineering is actually viewed.

</comment></comment></comment></comment></comment><comment><USER19> Problem: Interviewers lie.

I once interviewed with a company that brought me into a new, shiny, well- appointed building on the corporate campus for an interview.

I did well answering their questions. And they answered my usual questions correctly. Stuff like "Can developers here choose their own tools?" and "My title is going to be Lead Engineer, will I actually be a Lead Engineer?"

After I was hired, I found out everybody uses Eclipse, no exceptions, and I was absolutely not going to be leading anything (I was basically going to be used like an overpaid junior engineer).

The best part: "Oh, you won't be working in the new building..." and was taken to an old, windowless, leaky, mold-smelling building with peeling paint and flickering fluorescent lights (think the opening scene from "Joe vs the Volcano"). My office was a supply closet that was being converted into an office (by that I mean, "we just pulled most of the stuff out of here, but otherwise just rearrange the furniture however.") I was given an old 70s vintage desk that was too low, a sort-of broken chair, and a laptop and left to my own devices for three weeks while waiting for my new project to get started. Then I was suddenly moved to even worse accommodations - a cubicle, which belonged to an employee who had recently died (his stuff was still there, and it was a month before anyone came to take it away).

I started looking for a new job about 2 days in. Took me a year to find something else (I eventually had to move to a new city).

<comment><USER20> Recruiters will possibly say anything to get a sale.

But when talking to your future peers/team mates, I think you can expect a lot of honesty if you ask the right questions about how things _really_ are.

I know I'm always 100% honest, because _if_ they get hired, we'll be coworkers, and they'll know if I lied!!

PS It's weird that you didn't get the title in the contract

<comment><USER21> Sometimes they'll tell lies that their boss tells everyone willing to listen. Everybody knows these are lies, but they won't always give you that "read between the line" interpretation during an interview.

The most obvious one is usually "we're on an agile process", but there's so many other ones more subtle and hard to get a grip on, short of reading interviewer's clues when they answer the canned answer.

Sometimes the same words just don't mean the same things to them. Sometimes they don't realize how bad their situation is.

"Reality shock" in the first days at some workplaces is a thing.

<comment><USER22> Reality shocks I've seen personally:

1\. Workspace/office not the one you were shown/told. This is the most common one, in my few data points. I think people know it's a factor in appeal of the job, so it's mentioned, but the followthrough doesn't always happen.

2\. Person you interviewed with is leaving. (One of the people I hit it off really well with in interviews was a tech co-founder of the established company. When I arrive as a new Architect, he apologizes and says he had been looking forward to working with me (which is not something I normally hear), but he just got an offer for a supercomputer startup that he couldn't resist. Fortunately, some other great people remained, and I ended up working directly with one of the other tech founders. I supposed I might've been hired due to the company knowing that some people were looking to transition out.)

3\. Job not as described. (I've mostly avoided this common pitfall, but once got bit by it. I was recruited as the Research Scientist who'd execute on an idea that was sorta outside the scope of two professors who'd come up with it, but that they wanted to see it done, and it was up my alley. But, subsequent to discussion, when I'd been told I'd be the sole person leading&doing, one of the professors' grad students decided to do the idea for their dissertation, and I didn't find out until the first day on the job. It got worse from there, but the saving grace was that an all-around great 3rd person was also an "assistant" on the team, so, morale-wise, I was able to complete the entire year-long appointment I'd agreed to. I declined when the PI renewed the appointment for another year, and both us assistants asked not to have our names on the papers. It was unfortunate, because we did some good work, and the PI was willing to help me get my own ideas funded, but I couldn't commit to another year of the accidentally-bait&switch project.)

4\. Famous culture broken. (My anecdote wasn't a first-day reality shock for me, but first-year. A successful with-revenue early Web tech company in a university town had a locally well-known policy slogan about how you advance, which seemed much more widely quoted than the "don't be evil" of another company, and was repeated to me when I interviewed. Long story short, while I was working there as a Senior Engineer, someone in company leadership was willing to spoil culture and morale, to let someone's nephew (or similar) break the slogan. I went and talked with the head of engineering, who normally had amazing poise and charisma, but he had no good explanation for that one. This was when other dotcoms were hiring the then-rare experienced developers like crazy... but companies sometimes do things that employees don't understand, creating new reality shocks.)

5\. Representative from new parent company, walking around with representative from offshoring company, talking to employees about what they do, for multiple days. A bit like in "Office Space", but at an advanced Web tech company. (Also, I was concerned when they started asking me about an elaborate 3D puzzle that someone had assembled near my workspace before I was hired, they seemed skeptical when I said I didn't know anything about it, and then one of them asked where they might buy such a 3D puzzle, which I happened to know, and I couldn't resist being knowledgeable/helpful, even as I suspected it was just a trick.)

Reality shocks like these are another reason I'd rather talk with prospective employers, and get as much sense of the team and company as I can, rather than get distracted with one-way leetcode whiteboarding.

</comment></comment></comment></comment><comment><USER23> > Is there a support / marketing / other call-heavy team close to my new team?

This is so important.

I can probably live with most open plan set ups, sure there will be annoying times, but if there is a call-heavy team nearby, forget it.

I refuse to wear noise cancelling headphones all day long.

FWIW, interviewers will blatantly lie.

I asked at an interview about equipment quality and was told that they'd not heard any complaints.

This was 100% bullshit. I was given an ancient laptop, which seemed to re- ignite complaints about the quality of the equipment and were taken up with, none other than my interviewer.

<comment><USER7> > I refuse to wear noise cancelling headphones all day long.

May I ask why? Even when I work at home alone, and there are no stray noises at all, I'll still wear my headphones when I want to really focus. Years of mental conditioning has led me to a place where it's much easier to deeply focus when I'm wearing headphones listening to white noise.

<comment><AUTHOR> Not the op, but also wouldn't wear them. Weird ear shape means earbuds start hurting after a while, while the over-ear solutions make me sweaty/uncomfortable.

<comment><USER24> Not to mention earrings -- I've yet to find headphones that I can wear comfortably for a couple of hours that won't leave my piercings sore.

</comment></comment></comment></comment><comment><USER25> I would change the part: ``` Do you use source control? Do you test code? Do you use bug tracking? Do you use CI/CD? ``` to ``` How do you use source control? How do you test code? How do you perfrom bug tracking? How do you solve CI/CD? ```

For really good companies asking if they test code seems insulting :P

<comment><USER26> That also moves the question from being closed to being open - <USER2> leading to a secondary question that will highlight your ability to ask insightful Qs.

</comment></comment><comment><USER27>
      How much annual / personal / sick / parental / unpaid leave is available?

This is a great question; when I have searched for jobs, it's one of the more important benefits to me.

Sadly, however, I've found most places have gone to "PTO" \-- combining time off for illness and vacation into one bank -- how have others successfully negotiated an appropriate level of time off?

(Context: For a very long time, I worked for companies where sick time was essentially a non-issue; it was essentially unlimited, with appropriate rules around requiring a doctor's explanation or having to switch to short-term disability after a protracted period, but the occasional day or two to recover from a cold and not spread virus to the whole company without having to choose between that and visiting family.)

<comment><USER28> I just tell them how much time off I'll need during salary negotiations. I know you offer two weeks PTO and 3 weeks after 5 year, 4 weeks after 10 years etc. But I'm not restarting my PTO every time I switch companies. So I will come in with PTO equal to my experience at a minimum.

<comment><USER29> PTO is nothing special. It's just another benefit you can place a monetary amount on. If they won't give you more than two weeks paid time off and they will let you take _unpaid_ time off, add the amount that week of unpaid time off is worth to your required salary - of course take into account that PTO is a non taxed benefit.

I feel the same way about 401K matching.

<comment><USER28> yeah sure but depending on the company it's easier to take PTO than UPTO. People expect you to take all your PTO generally. That's not always true if it's unpaid.

<comment><USER29> I know, and I said _and they will let you take unpaid time off_

</comment></comment></comment></comment></comment><comment><USER30> Why doesn't the interviewee ever ask the interviewer a whiteboard or puzzle question, "to see how you think?"

<comment><USER31> Because unless you are some sort of celebrity engineer, "interview is a conversation between both parties" is nonsense.

Company is interviewing the candidate not the other way around, no matter what we like to think.

Edit: Sorry I should've clarified. I am specially referring to companies that don't really have to care about your feelings towards their interviews. FAANGs for example. They simply don't care and there are million others who are willing and happy to go though whiteboarding. They just don't have to put up with your stuff.

Ofcourse you have leverage when you are interviewing at your local java enterprise shop. But who cares about those jobs, pointless to interview them with your smartass questions, we all know they are pretty much all the same more or less.

<comment><USER32> > Because unless you are some sort of celebrity engineer, "interview is a > conversation between both parties" is nonsense.

I disagree. Unless the candidate desperately needs this job, he/she can walk away. The candidate is free to consider "company won't bother to answer my questions at the point when they have most reason to be nice to me" as a bad signal.

> I am specially referring to companies that don't really have to care about > your feelings towards their interviews

"This company doesn't have to care about my feelings because they are huge and have lots of applicants and a giant incessant interview machine chugging through them efficiently" is certainly something I'd consider in whether I want to work for them, because it tells me I'd be a cog in a machine. (And if enough people consider that, perhaps they will have to care.)

To the parent question: I wouldn't ask a whiteboard question exactly, but I would certainly ask some questions about existing architecture and rationale so I have an idea what I may be working on.

<comment><USER31> > it tells me I'd be a cog in a machine.

Aren't you a cog regardless though. Why would one work for half the salary just because of an interview. If one can get over the interview part, he/she can retire 10 yrs sooner.

<comment><USER33> Well, to take the metaphor too far, there's cogs that are greased and used only within spec, then there's cogs that are never greased and deliberately run beyond spec, rust ignored, etc., and in the worst cases, cogs that are used as, err, bulletproofing or something. Metaphors. Never trust 'em, they always turn on you.

For what I'm paid, I don't mind being a bit of a cog. Work is a means to an end for me, not my identity. But I would like to be kept greased and worked within spec, not constantly in crunch time. And while I am fundamentally disposable, I prefer to work in a place that sees I'm lot more valuable _not_ being disposed of. (Again, metaphor breaks down here; planning on your personnel being routinely disposed means you are planning on nobody ever actually developing any skill in your systems.) It's not all the same thing.

</comment></comment></comment></comment></comment><comment><USER34> I'll give a shoutout to [https://www.keyvalues.com/culture- queries](https://www.keyvalues.com/culture-queries) where questions like these are explained in more depth, for example:

Can you give me an example of a mistake you've made here, and how it was handled?

Ideally, your interviewer will answer honestly. If people are comfortable discussing big failures, it suggests that the company has created a safe environment for people to fail, and signals that it's an environment conducive to taking risks and experimenting.

On the other hand, if people are guarded when it comes to discussing failures, they might be working in a culture of blame.

You can follow up by asking about their practices around investigating issues, writing post-mortems, and overall documentation.

</comment><comment><USER35> That's a really good list. I really wish I'd asked a few of those in the past.

"Where do you plan to be in 5 years" is actually a really good question to ask a company. Many have no idea (which is possibly fine, but good to know)

Interviews can also be a fantastic place to get real feedback - but you have to do it during the interview; almost nobody gives real feedback after the fact.

"What would give you concerns about hiring me?"

"If you could have your dream candidate for this role, what would they look like?"

"What in my application caused you to call me in for an interview?"

Are a few that I've found helpful.

</comment><comment><USER36> I use the comment test. It's pass/fail and goes like this: "Suppose I'm reading some code and I see an obvious typo in a comment. What's the process for fixing it?"

(Note: I've actually gotten all of these answers, albeit sometimes only after I joined a group (prompting me to develop this test in the first place)).

Fail: "just edit the file lol"

Pass: "edit the file and check it in"

Pass: "edit the file, send a diff, get a +1, and check it in"

Suspicious: "edit the file, send a diff, get your code and style approvers, wait for presubmit, and check it in"

Hard fail: "file a bug..."

WTF are you even doing: "we can focus on code quality issues after this milestone"

<comment><USER37> Remember to ask about 'code lockdowns', some coding jobs have seasons of a sort.

</comment></comment><comment><USER22> > _What 's the status of / view on diverse hiring?_

As someone who believes in value of diversity (just to be clear), for both organizational and societal reasons, I think this is an important question, for a variety of reasons -- but also a question that candidates might not want to ask.

Candidates might not want to ask, due to not knowing how the asking will be perceived. Or due to not wanting to mention some unapparent quality (e.g., being gay), because they don't know how welcome that will be, or they just want to be treated as, say, a developer, at that stage of meeting prospective colleagues.

It's much better if the company communicates its real policies/practices/culture and status proactively (beyond the standard HR equal opportunity statements), so no one has to ask.

<comment><USER38> It could also be asked for the opposite reasons. For example, some developers might consider it a "red flag" that companies prioritize diversity hiring and will want to stay away.

</comment></comment><comment><USER39> I'd focus your questions to only the ones where answers might make a difference as to whether you accept the job. Are you really going to turn down a job because their on-boarding process isn't optimal? Or to a bad tech answer... would you turn down the offer, or help them improve from the inside?

I do like this list, but filter it down to what you need to respond to an offer. And that filter will be different for everybody.

Typically when I am in an interview, I explicitly draw that line with the interviewer, saying, "I have more questions, but I also have the answers I need to make a decision if you extend an offer, so we can get the rest answered later if we move forward together."

<comment><AUTHOR> Turn down an interesting offer because of onboarding? Maybe not. Choose between two roughly equivalent companies, because one has a good onboarding process which likely means both investing in growth and caring about documenting things for people who didn't have lots of existing context? Definitely possible.

<comment><USER39> Good point.

Like I said, everyone's filter will be different. There are probably valid reasons to ask every question on the list. And also valid reasons to skip every question. We all have different goals and preferences with our careers.

</comment></comment></comment><comment><USER40> I am now a Mr Manager Person, so I have a different but related set of questions:

1\. What is the demographic breakdown of the engineering team? And, what does the company affirmatively do to foster diversity?

2\. What resources do the founders have available — investors, board, mentors, for instance — to help them as the company grows?

3\. What is the near term vision for the company? 1yr/5yr?

4\. What resources are available for professional development for managers/directors?

5\. At $CURRENT_COMPANY, the company is serious about reviews upwards — as a manager, my direct reports are consulted in a formal process at review time. Is there a similar process at $POTENTIAL_EMPLOYER?

6\. What is the cadence and process for reviews?

<comment><USER41> What does "diversity" mean in your question #1 and how is it relevant to successful outcomes?

<comment><USER40> Demographic diversity, diversity of backgrounds, diversity of experience. Monocultures are actively destructive of successful outcomes, and lead to miserable working environments. The question is asked open-ended in that fashion because I want to discover what a potential employer thinks is important.

<comment><USER42> What about if you're a hiring manager for a software company in Japan or Korea?

<comment><USER40> I'll cross that bridge if I come to it.

</comment></comment></comment></comment></comment><comment><USER43> I wrote this[1] a few years ago. Since then I changed these questions quite a lot (I need to write a new post) but the concept is still the same. Whenever I'm going to interviews I never go as I will be the interviewee.

For quick reference:

\- What will my job be? At first and after few months?

\- What is your work policy for employees?

\- Software/hardware that I will get?

\- Can I participate on/run side projects?

\- Is there a budget for conferences, further education, bonus?

\- What is the history of this company and how do you see the future?

\- Will you measure my productivity and how?

[1]: [https://kostasbariotis.com/interviewer-vs- interviewee/](https://kostasbariotis.com/interviewer-vs-interviewee/)

</comment><comment><USER44> Hmmm, I did discuss some of the technical questions from the list and I have to admit that it's not easy to make a decision based on them. It's a great start for discussions, and definitely something to consider but your time is limited, the other side will beautify the answer, the same as you do, and you might end up in another totally different team than this of your interviewer.

Remember that things tend to be fluid, re-organizations happens often, having a bug tracking system doesn't make bug handling efficient and CI/CD doesn't mean your time to deliver is necessarily short.

<comment><AUTHOR> Completely agree. Would you mind if I stole your second paragraph? (Or could you submit it as a pr?)

Those are definitely seeds of conversations rather than something you can 100% rely on. But if you have doubts about the organisation and then hear "no bug tracking, we don't need it" without explanation, then something's definitely fishy. That's one of the red-flag questions. Then again if they don't but have an explanation, maybe there's something really interesting behind it.

<comment><USER44> Sure no problem, go ahead and steal it

</comment></comment></comment><comment><USER45> "Does the company provide hardware and what's the refresh schedule?" \- I really wish I had thought to ask this on my first remote job. Everyone is surprised when I show up at company meetings and don't have a laptop I can develop on. I work on a desktop, if you want me to have a laptop capable of running windows docker at the meeting we have every 6 months on the other side of the country, buy me one.

</comment><comment><USER46> Ask a question like "Given a non-negative integer numRows, generate the first numRows of Pascal's triangle." If they can't answer without using Google I end the interview as they didn't pass the round. :-)

<comment><USER47> I'm not sure if this is satire. Sounds like it may be, considering your emoji.

Getting asked questions like this, in most cases, is enough for me to end the interview. I don't want people who can cite off memorized answers to random questions. I want driven people who are excited to learn what needs to be learned in order to push the company forward and make work a fun place to be. Confident people can learn to solve difficult problems on the fly, with ease. This is more valuable than being able to recite a textbook answer during an interview.

One of my favorite interviews of all times:

Interviewer: "Hello. I have your resumé in front of me. I am going to ask you a bunch of questions in rapid succession, and I just want yes and no answers. Are you ready?"

Me: "No."

Interviewer: "Excuse me?"

Me: _click_

</comment></comment><comment><USER48> I tried this in my last round of interviews. It is very difficult to get any meaningful information from this process, because, just like candidates, interviewers are incentivized to not tell the full truth. Except in the worst cases when the interviewer just dgaf, they can't really share negative information for fear of reprisal. (And it doesn't benefit them either.) Your best bet is to ask a question that allows them to answer honestly, without sounding like they are answering negatively. The problem is it's hard to come up with such questions.

<comment><USER49> "If I was hypothetically a person that likes to refactor/maintain confusingly tangled mess of a code, would I enjoy working here?" :D

</comment></comment><comment><USER50> > What's the on-call plan/schedule? (what's the pay for standby and call-out)

I've never been in a position where we were paid for on-call (i.e. fix prod at 2am) work. Is that not typical?

<comment><AUTHOR> I've never been in a position where I've _not_ been paid for each call out. (And only one place which didn't pay for standby)

<comment><USER50> Whoa.

That gives me pause. It makes absolute sense, but it never occurred to me.

<comment><USER51> When I have seen this done, the amount is often inconsequential in relation to the amount of effort to be on-call. I don't love this incentive structure because the cost of being on-call is somewhat fixed up front. Needing to avoid being out of page coverage / availability and having a computer available is a high cost paid by the employee regardless of actual page-out workload. Paying for standby certainly helps, but I haven't seen standby pay match well with the perceived effort. Maybe some companies do this right, but higher negotiated upfront pay has appeared more effective in my experience.

</comment></comment></comment></comment><comment><USER52> Meta-comment: I'm increasingly suspecting that it's not tech hiring that's broken, but the tech labour model.

Specialisation is high, training is long, skillsets frequently expire quickly (at least relative to careers / education), certification lags worse than training does, in many instances, and information aquisition costs on _both_ sides of the hiring line are high: employers have difficulty in finding good/suitable candidates, candidates have difficulty in finding and/or assessing good employment fits.

Rewards _once on a gig_ are highly disproportionate, with some high-paying companies, a strong gamble on equity (usually fails to pay off, very rarely does), and increasingly draconian employment terms and contracts (again, California law is exceptional, but as labour gets priced and simply slotted out by housing prices and unavailability, other centres with far less favourable working conditions may gain traction).

The idea of working as an individual at a given company for 18-36 months, then moving on (typical job tenancy) seems highly inefficient.

Chunking labour into a force that can be deployed might address that. Less a union than a guild, perhaps. Structuring that (and accommodating various state's and nation's employment and organisation laws) is an interesting challenge.

</comment><comment><USER53> At a faang you'll never get the chance to ask the team you're joining this many questions directly, unfortunately it's also really heavily dependent on the team and manager. HR will usually give you some of these answers and will often stretch the truth except for benefits. Even then expect things like promotion processes to evolve, many things are never statically configured, even down to the small perks you receive every day. So here's the #1 question you need to ask, esp. at large companies:

1) How long has the team/project I'll be joining been around?

Are you joining a team that's in maintenance mode or are they projects other than just refactoring/simplifying or migrating code to the latest and greatest <programming language/stack(cloud)/jdk version/whatever>. As an eng and even manager you _really_ want to join very young teams and large teams >= 6 people (is the company serious about this project? burn rate > 1 million year). That gives you most runaway to develop something new and then brag about all the features you landed at promotion. Most large companies give fledgling teams 2-3 years to become viable. Try to stay away away from teams that have been around for a long time unless it's your area of expertise or you're excited about the project/work.

2) What's the churn rate? Who's the oldest eng. team member (in terms of how long they've been on the team of course) and was the person promoted while working on the project? The higher the level this person is on the team the easier it will be for you to get promoted.

</comment><comment><USER54> I'd love to ask, "Why do people quit?" during an interview, but can't think of a way to phrase it without sounding accusational or pretentious.

<comment><USER55> I think asking something like "when people don't work out and end up leaving the company what are some of the typical causes of that mismatch?" wouldn't raise a red flag.

<comment><USER54> That gives the interviewer a reason not to say 'well we messed up'

</comment></comment></comment><comment><USER56> I hate these typical questions which hiring managers or candidates ask each other with no real meaning behind.

E.g. "how do you use source control"?

What is the intention of this question. What value do I gain from this question? It implies that I have a specific way of interacting with source control in mind and if they don't follow the say way then I'm unhappy or what?

Interviews take such a long time, I am of the opinion that I only want to ask questions which genuinly help me later to make a decision.

e.g. instead of "what tech do you usually use?" I'd ask "I've been recently playing with X and think it's a brilliant use case for doing Y. If I were on your team and I'd want to do Y with X, would that be an option, or what's the protocol in tech decisions in your team?"

With a concrete question like this the interviewer has to explain to me how they _actually_ decide on tech and give me a more or less yes/no answer to whether what I want would be possible. I find this a lot better than a generic tech question and then get bombarded with a ton of buzz words which don't really say much about how open the tech teams are to picking their own tools for the job, etc.

</comment><comment><USER57> The phrase 'hiring is broken' seems to have become synonymous with companies improperly judging candidates.

BUT! This problem pales in comparison to the difficulty involved for candidates trying to judge companies.

Now, I won't go as far as some of the other posters here and point to rampant deceit. However, interviewers will generally try to be positive, and it's very difficult for an interviewer to say "don't work here".

</comment><comment><USER52> What's your disaster recovery plan?

What circumstances does it cover?

What is your threat model?

(Depending on response, address missing elements: external threats, natural disasters, power out, hardware failure, fumbling fingers, network-based attacks, insider threats, APTs. Acknowledging _and not further addressing_ some particular threat is acceptable, ignoring it completely is not.)

How frequently do you drill for threats / failures? Practices such as Netflix's "chaos monkey" are close to best of class. Not at all is unfortunately the norm. Here I'd _like_ to see some positive answer, but a widened eyes "oh, we should do that" would be encouraging, Dismissal would be many red flags. People respond to disasters according to their training and drilling, and failure to do either leads to poor response.

What is your professional development process? Name specific programmes / practices for entry-level to senior staff.

"What's a really good day?"

"What's a really bad day?"

Who's been promoted recently? Why?

What reasons have you had for making staff redundant?

What reasons have staff had for leaving?

</comment><comment><USER58> Has anyone tried to get the company they are interviewing for to provide written and signed answers to any of their questions relating to the company or job? Maybe even have ramifications if what was written turns out not to be true? Seems like this is the only way to keep companies from falsifying everything they say just to get a hire.

</comment><comment><USER59> So, am I actually going to start laying down track for this new product you hired me to do? or are you going to kidnap me to work on legacy software emergency patches the second I walk in the door?

An invaluable question if honestly answered.

</comment><comment><USER60> For companies that offer "unlimited" PTO, it is good to ask what is the average number of days actually taken off by employees. Are multi-week vacations doable? Have vacations ever been denied (happened to me)?

</comment><comment><USER61> I'm slightly bothered by the "reverse-interview" concept. To me interviews should be bidirectional you are there to find out about the company as much as they are there to find out about you. It should be treated as the starting phases of a negotiation where you gain information about the value of the asset you are going to acquire.

I'm certainly happy that viraptor shared this valuable resource, don't get me wrong, every little step in the right direction is a good thing. I simply would have liked it to have a better name in order to convey a different message.

<comment><USER62> Interviews already are bidirectional, even if the interviewer thinks they're not. If you're so keen for the job that you don't ask any questions, then you look a) desperate and b) like you're trying to bs your way through the interview, which isn't great. My only objection to these questions is a some of them are essentially negotiating the terms of employment, which isn't appropriate for most interviews.

</comment></comment><comment><USER63> One of the most important questions:

What is the attrition rate for the manager and for the company in general. If a manager has high attrition rate, that's definitely a red flag.

<comment><USER64> wdym by attrition rate?

</comment></comment><comment><USER47> Why should I work here?

It's a forward question, but your time is valuable. If you are going to spend a large chunk of your foreseeable future working at a company, they should have a good answer to this question. If they hop around all awkwardly while trying to come up with an answer - next. I want to work with people who are excited by the work they do. Plain and simple.

Always remember, the interview goes both ways. Be sure to interview the interviewer.

</comment><comment><USER65> How often do you load to production? What's a project here you are most proud of? What was your last prod issue, how was it observed, how long to resolution, what changes did you implent to help going forward?

These are sre focused, the first one indicates if sres are toil driven or overloaded.

The second shows that you have agency as a sre and can have a positive impact.

The third goes into their culture around mistakes, monitoring and on call.

</comment><comment><USER66> I think, the "source control question" comes from the Joel Test which is 19 years old. Almost every company uses source control now so it doesn't make as much sense.

A better question would be "why do you use [the source control they use]". The answer, if coming from a knowing person, may tell you quite a lot about how the technical decisions are taken in the company.

<comment><USER67> There was definitely a time when that was an important question, because the answer could be "CVS", "nothing" or even "what is that?". Nowadays the answer is practically always "git".

<comment><USER66> Indeed. But why git? I worked for 3 companies that adopted git for completely different reasons.

The first was open sourcing parts of their code so they just started using GitHub. Makes sense.

The second used to work with Subversion, and they stayed with it. The process was built around having one and only one server with all the CI, and the hooks, and the locks. Git was used with the SVN gate purely for developers' convenience. Makes sense.

The third one was on TFS, and they couldn't quite align their process with it. So they thought "our process is a mess so let's do git". This is a red flag. If you can't get your process straight with relatively simple tool, some more sophisticated tool will (and it did) only make it worse.

<comment><USER67> > _" why git?"_

Honestly? Because it's become accepted as the industry standard. People who need to make the decision without having knowledge about the topic just go with whatever everybody else is doing. In the past, that used to be whatever IBM was offering, then whatever Microsoft was offering. In that respect, git is a lot better. It's flexible enough to adapt to different kinds of workflows, at least.

</comment></comment></comment></comment><comment><USER68> I'd like to see a section specific to large projects. It's not uncommon for companies to hire for specific projects, especially in the contracting world. ERP, SAP, and other projects come to mind.

Something I wish I asked during my last big interview: Do you have a project schedule? Can you show that to me?

If there is no schedule, or a very ambiguous one, that's a big red flag.

</comment><comment><USER69> In the past when I was unsure I've asked to just have a candid chat outside of the office with my prospective co-workers.

Worked well.

</comment><comment><USER70> For early startups, these are important:

        - Are you profitable
        - If not, how long is your runway

<comment><USER71> I did that. Turns out, things change fast. (Or the answer was not truthful? I don't know.)

<comment><USER40> Sometimes, it's both!

</comment></comment></comment><comment><USER72> Let's be honest, most developers are not in capable of performing at interviews at such a level that they can actually get to "choose" where they want to work. They get one offer out of a round of interviews and that's and you either take it or leave it.

</comment><comment><USER73> I created a short questionnaire with TypeForm that asks some of these questions and linked it to my LinkedIn profile. Now any recruiter either answers ten or so qualifying questions or skips the questionnaire and goes straight to trash for not even reading my profile.

</comment><comment><USER74> 'how do you know that somebody has done a good job at your company' and follow up questions on what kind of processes they have: in build automation and CI / bug database etc / are unit tests required for fixes? Do you do integration tests?

</comment><comment><USER75> "Definitely don't try to ask everything from the list."

^ I wouldn't agree to this. If the interviewer can ask many questions about my working style, why can't I ask the same about the company with whom I am going to spend the most of my daylight with?

<comment><AUTHOR> It's more about "choose what's important to you and respect each other's time". Not all questions will apply to a company. Many of them you can answer by reading company's website/blog, maybe looking at public repositories.

If you ask something that shows you did no research or don't understand the role description at all, that's actually going to count against you later. Same for holding someone busy with simple questions if you had a scheduled interview slot.

</comment></comment><comment><USER76> I normally ask what opportunities for growth exist, eg training/certs/online courses etc, and what they like about the company, can normally tell if they like the job/you by how enthusiastic they answer or whether it comes across as scripted

</comment><comment><USER77> OP: I am too lazy to file a PR, but here are some of my questions, feel free to use as you wish: [https://pastebin.com/7ztvPwnY](https://pastebin.com/7ztvPwnY)

</comment><comment><USER78> I usually like asking what their staff turnover is like.

It was very telling many years ago when I was told "very low, almost non- existent" and then promptly learned from my new colleagues that it was extremely high....

<comment><USER79> I wonder if you could ask something like "Do you have going away parties for departing employees?" Can be very telling.

</comment></comment><comment><USER80> Now that I'm the interviewer, I think it's better to not ask questions than ask a question you don't really want the answer for. Most questions I get asked by interviewees lower the impression I get of them.

</comment><comment><USER81> Pro tip: Get the stuff that is important to you into the contract!

</comment><comment><USER82> * how many aws account do you currently run across your entire company?

* how much time does it take to approve/create certificates?

* how many engineers quit within first year of joining company?

</comment><comment><USER83> There is a question about funding. So I'll assume the company is a startup at some stage. But I'm surprised there aren't any questions about stock.

<comment><AUTHOR> Actually it wasn't supposed to be about a startup only. Established companies also grow through external funding, whether it's a loan, partnership, selling shares, or something else. Each of those may change how the company works and whether you're comfortable working that way.

<comment><USER83> Not only. But if you're going to ask about runway then some intelligent questions about stock are in order.

</comment></comment></comment><comment><USER84> When was your last vacation? Where did you go?

When was the last time you thought about changing jobs? Why?

When you joined this company, what were your goals? How many of them have you met?

</comment><comment><USER85> I asked about turnover on the last one, recruiter wasn't at ease. Is it a lack of tact on my side or were they hiding something ?

</comment><comment><USER86> My 2 favorites:

\- how many quit in the last 3 years (followed by "why so many" or "why so few")

And

\- can I sit with someone that shows me some code I'll be working on?

</comment><comment><USER87> Data science version of this is highly required and must be asked with every company one is supposed to join.

<comment><AUTHOR> I'm not familiar with that environment, but if you have specific questions - there's always space for more sections :-)

</comment></comment><comment><USER24> I -just- started compiling my own list as I head back out to find a new job. This will be so helpful!

</comment><comment><USER88> "Can I talk to the last dev to work on this?"

"What happened to the last dev to work on this?"

</comment><comment><USER89> > Is there a support / marketing / other call-heavy team close to my new team?

What does that mean?

<comment><USER17> I assume the author meant that since those teams will be speaking a lot to people as part of their daily work they add a lot of ambient noise to a workplace. That could matter to some people in open office plans or cube farms where you can't separate yourself from that noise.

<comment><AUTHOR> That's it. "Is the office loud" is subjective. "Is there a team handling calls a few metres away" has a simple objective answer... usually.

</comment></comment></comment><comment><USER90> it's insufficient to know the questions. to gauge whether a company is the right fit, you must understand what it is that you're looking for. this is a culmination of past experiences and lessons learned. the questions will follow.

</comment><comment><USER58> What affects does it have on a company to not hire ANY junior level developers?

<comment><AUTHOR> One effect I'm familiar with: lack of documentation. Everybody is experienced with the system, everybody knows how things work... until they don't. Having someone around to ask the simplest questions and prompt for explanations is very healthy.

Another is that people with lots of experience know and rely on straightforward, correct, reasonable solutions. It sometimes takes a someone new to say "why don't we try X?".

Finally, sometimes there's just work to do, not new things to figure out. If everybody is senior but lots of work is pretty basic, at some point they'll get bored and leave.

</comment></comment><comment><USER91> What are the hardware specifications of the average developer workstation?

</comment><comment><USER92> Do you pay for this job?

</comment><comment><USER93> One thing to note with these is that they seem to target companies/jobs where you will work on a single product/suite of products. A lot of these questions would be out of place in many agencies or the interviewers would not have answers or the answers would just not be as good as you would expect from a more focused team. Of note:

\- What does the onboarding look like?

In large part because of how rapid development is in agencies, how often you change projects, and how small agencies tend to be, onboarding is often non- existent beyond showing you the software they use and showing you how to set up your Vagrant or Docker. Most of it is on an as-needed basis and you'll be given the information you need for each project you work on, thanks in large part to how ad hoc each job can be. I've experienced this myself at all three agencies I've worked at, I have friends at two others who say the same thing, and it's what I was told to expect in school.

\- How do you test code?

This will almost always be "put a dump in the code and see what's wrong". Agencies don't often unit test and because of how often they switch projects, having a consistent debugging environment is often more trouble than it's worth. You should still ask this, just don't expect the greatest answer.

\- How do you integrate and deploy changes? Is it CI/CD?

Due to the quantity of projects, this will often be "no" unless the agency primarily focuses on larger, months/years-long projects. For the most part, clients don't want to the time it takes to pay for automated tests/deployments and often don't host with you anyway, so it's usually either "run a git pull and compile assets" or "package the code in a zip and send via Dropbox".

\- How do you prepare for disaster recovery?

Disaster recovery is often an after thought at agencies. Usually the disaster recovery is "spend a few days restoring backups and eat the costs". Unless you are interviewing for a security or senior position, this question doesn't really make sense to ask at an agency anyway as you are unlikely to be involved in any recovery.

\- How quickly can you respond to security issues in the code or dependencies?

Because everything is paid for by the clients, if they don't pay for it, they don't get it. Don't expect much more of a response from your Agency interviewer. If you get an intricate response, I would suspect it's exaggerated. There are exceptions, but agencies don't make money making sure the sites and apps they build are up to date, unless the clients want them to be (and most clients do not see the value in it)

\- What's the product/service schedule? (n-weekly releases / continuous deployment / multiple release streams / ...)

Again due to how many projects you work on regularly, this may not get a good response. Maybe a "Our Wordpress sites take 2-3 weeks to build, 1 week to test and fix, and 1 week for client review" type response, but anything more standardized than that likely isn't happening.

\- What are some ongoing challenges the team is experiencing that you are yet to resolve?

This one also likely won't get much of a response due to how many projects there are and given that most of the team is working on different things than their neighbor.

\- What's the promotion process? How are requirements / expectations communicated? \- Is there a separate tech and management career path?

Agency structures are generally really flat. 1 guy at top, maybe a few seniors below him, then everyone else (but everyone, including the seniors, report to the 1 guy at top). Don't expect promotions, but raises will happen regularly. You can ask this one, but you'll probably be more interested to hear when/what to expect from your raises (agencies are often generous in this respect)

\- Are there any company-wide resources for learning available, like ebooks subscriptions, or online courses?

Regardless of company type, know that this will depend entirely on company size. If you're interviewing with a 300 employee company, you should expect it. If it's a 10-40 person company, you probably shouldn't and it may not be worth asking and may make the interviewers think you're looking for something they aren't providing.

\- Can I contribute to FOSS projects? Are there any approvals needed?

This is a GREAT question to ask during the interview if you are hoping to work on FOSS. Agency rules on this vary greatly and it's one I personally like hearing from candidates.

\- Are there any non-compete or non-disclosure agreements I'll be asked to sign?

Another great one to ask simply because you will work on so many different projects from so many different clients from so many different industries. My previous employer tried to get me to sign one saying I wouldn't work with any competitor of their customers for 3 years after I left. That would have killed my ability to find a job at another agency afterward. It was part of the reason I quit there. My current agency is basically "Don't talk about specifics that may be confidential during development, don't steal our customers after you leave" which is more reasonable and acceptable.

\- Are you profitable? (+ the other financial questions)

If your interviewers are developers at an agency who don't also own the company, they likely will not know any financials specifics

\- Remote Work

If this is important to you, make sure to ask about it in the interview. It varies greatly from agency to agency. I interviewed at a place that only expected you be in the office once a week and work from home 4 days a week. My current place prefers if you keep the remote work to a few days a month at most.

</comment><comment><USER94> Interviewing the interviewer has been THE best way to get the job. It just oozes a confidence that you already know you're good enough to get the job, and you're trying to figure out if they are good enough for YOU. Figure out questions before hand that describe the type of good working environments or fixes for bad ones that you've had in the past. The interviewer will quickly shift and try to sell the position to you (harder than normal). It sounds silly, and like something they'd probably be used to by now, but in every case I've done this it's landed me an offer. This is coming from someone who needs to interview well because my degree/experience doesn't usually perfectly line up to the jobs I'm applying for.

<comment><USER95> At my job, we have "do you have any questions for us" part as a standard part of every interview -- and my experience shows that most people always have at least one question.

<comment><USER96> I suspect most candidates have at least one question because it's pretty widely known that many employers will ask "do you have any questions for us" at the end of an interview, and so will have prepared something that makes them sound interested in the employer in some way, even if they don't necessarily actually care that much about the answer. (For instance the advice on [https://www.wikijob.co.uk/content/interview- advice/interview...](https://www.wikijob.co.uk/content/interview- advice/interview-questions/questions-ask-your-interviewer/) suggests "Have two or three interesting and intelligent questions prepared before the interview, to show that you are interested in the job and eager to find out more" etc.)

<comment><USER97> I'll give my anecdote on this:

When I used to not have any questions after the interview - I got rejected what felt like a weirdly high amount and definitely a weird tone from the interviewer.

When I started asking questions - the interviewer seemed to have a much more positive outlook on me and my acceptance rate went up.

I've interviewed a lot and there are people you have to ask questions to or else they will reject you.

<comment><USER98> As an interviewer and hiring manager, a candidate not asking questions indicates a lack of interest in the company/role. I appreciate when a candidate interviews me about the role, the team and the company. It demonstrates a desire to take advantage of an opportunity to gather more information about whether this is the right opportunity for them.

</comment></comment></comment></comment></comment><comment><USER99> I have a similar problem about the question "mention 5 advantages in you and 5 deficiencies in you".</comment>


Learn AngularJS with free interactive lessons - <AUTHOR> http://www.learn-angular.org/ <comment><USER2> CodeSchool recently launched a (Google sponsored, free) Angular course with exercises too:

[http://campus.codeschool.com/courses/shaping-up-with- angular...](http://campus.codeschool.com/courses/shaping-up-with-angular-js)

The more the merrier!

<comment><USER3> Looks promising, but the videos don't seem to buffer for me at least. My internet isn't strong enough to play it continuously so I normally just pause videos, wait a few minutes, then try playing them. Doesn't seem to make a difference with their videos for some reason. Any tips?

<comment><USER4> They're probably using DASH[1]. The video is split into several segments and therefore the player will fill the bufer only until the end of the current segment.

Below each codeschool video you have a download link, so you can view them offline.

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

<comment><USER3> I see that's probably what it is, thanks for the info. I will probably just need to download them.

</comment></comment></comment></comment><comment><USER5> Look at the pages indexed in google: [https://www.google.pt/search?q=inurl%3Ahttp%3A%2F%2Fwww.lear...](https://www.google.pt/search?q=inurl%3Ahttp%3A%2F%2Fwww.learn- angular.org%2F)

Now look at the source with ctrl+u. (example url: view- source:[http://www.learn-angular.org/#!/lessons/binding-css- classes](http://www.learn-angular.org/#!/lessons/binding-css-classes))

Now you know why he needs server side rendering (:

Anyway I never tried angular, and this tutorial made me try it. Is explains very very well how to get started, that's true.

<comment><USER6> Seeing how I figured out how to index angularjs pages for searching myself in one evening I imagine it won't be too long before google improves on this.

<comment><USER7> I'm not sure it's Google's job to.

Or rather - even if Google figures out how to index these pages, why should every other consumer of web content have to also figure it out when it's the fault of the content itself.

i.e. don't break the web.

<comment><USER8> I would argue that Google's job now includes executing javascript and evaluating dynamically loaded content.

Break the web.

<comment><USER7> Be careful what you wish for.

<comment><USER9> Flash. _shiver_

</comment></comment></comment></comment></comment></comment><comment><USER10> Great tutorial. I love these interactive lessons, but one thing I'd love to see in this tutorial (and many others like it) is something that Michael Hartl does in railstutorial.org, which is an extra credit section.

In the later sections of the tutorial, the addition of some suggestions for extending each example would be great. You don't need any "stuck" functionality or anything like that here; just some casual examples of how else you could use the subject of the tutorial would really help solidify the concepts.

</comment><comment><USER11> Awesome resource and great lessons. I just went through a lot of them, but I have to say the quality of the new CodeSchool course is amazing (and a lot more comprehensive than this one).

</comment><comment><USER12> I was using the CodeAcademy courses, they are equally good. Although I have looked into only the first few lessons on learn-angular.

</comment><comment><USER13> Is there anything like this for other languages and libraries? I know about try ruby, js & python. Any others?

<comment><USER14> Go has a omnipresent compiler not just in the Playground:

[http://play.golang.org/](http://play.golang.org/)

But also in their tutorials:

[http://tour.golang.org/#1](http://tour.golang.org/#1)

</comment></comment><comment> full-of-foo Great, bookmarked and thank you.

</comment><comment><USER15> I might take a look at this, have not yet looked into Angular.

It is a little disappointing to disable javascript and refresh the page at www.learn-angular.org, it's just a blank page. As much as I'm a javascript fan, and have made single page apps, a completely blank page without JS just feels wrong. I'm guessing this isn't the fault of Angular.. or is it?

<comment><USER16> While Angular can certainly be used for simple progressive enhancement-kind interactions, its strength lies in single page/fat client apps, and in this case not having javascript and still getting basic functionality would mean duplicating it on the server. Still, it would be a good idea to display a noscript message alerting the user about the JS requirement.

<comment><USER17> Blank landing pages = bad CEO,no matter how much escape fragment or trick one pulls. And CEO still make a difference,when the social echo dims.

<comment><USER18> While I agree that having a good CEO is important for any company, it this case SEO would be much more relevant ;)</comment></comment></comment></comment>


Steve Yegge: Lisp is not an acceptable Lisp. (2006) - <AUTHOR> http://steve-yegge.blogspot.com/2006/04/lisp-is-not-acceptable-lisp.html <comment><USER3> it is still Yegge: shallow and mostly wrong.

People who actually use Lisp (opposed to people who only write about it) have no problem that there are extensions to the standard. The whole point of Lisp is that it is easily extended in many ways: the programmable programming language. Sure it brings a bunch of problems, but that's what it is and why people use it.

The stuff he writes about CLOS is mostly wrong. CLOS is not implemented as a bunch of macros. CLOS is actually a three level architecture: the core is written object-oriented in CLOS itself, on top is a functional interface and for user convenience there is a bunch of macros for easy definition of classes, generic functions, methods and some other language objects.

Then, macros are no problem. They are a feature. No, 'hygienic' is fine, but not needed. No they don't need to be rethought. They do a useful job like they are.

No, Lisp will never be massively successful (because it is a bit too complicated, too dynamic, too powerful for many users) and bending the language trying to make it 'massively successful' won't improve anything. No, I don't want a dictator. Lisp has choice, various alternatives and a more democratic approach.

Lisp is still a good choice for computing with symbols. If you don't need that, then you might not need Lisp. But that's not a reason that Lisp should change. Should a helicopter be changed in design because someone does not use it, but drives a car? Should the helicopter be changed, because more people drive cars, getting a drivers license for cars is easier than getting a pilot's license for helicopters? Lisp is different, for a reason and this difference will ensure its survival for many years. We have now fifty years that the basic ideas have proven to be useful and I don't see that this will change in the coming years.

<comment><USER4> >>Lisp will never be massively successful (because it is a bit too complicated, too dynamic, too powerful for many users)

I have a hard time buying your explanation, since the scripting languages of today can be described as lisp subsets.

I am a fan of Perl and enjoy my life. The other usual scripting languages are quite similar, in most ways.

Still, I'd love to get a job using Common Lisp, which I haven't really touched since I studied. Why can't I do that?

Edit: I don't mean to whine, it is just that there is something wrong here. Lisp should be a, well, "contender".

<comment><USER5> Try listening to Matz talk about his experience with Lisp and (subsequently) his inspiration to make Ruby. Basically, he said Lisp sounded great in theory... but actually when you have to use it it's a huge pain in the ass. And Matz is a pretty fucking smart guy, so it's not just that too many people are too stupid to use it. Lisp actually has problems. But nobody is willing to talk about them.

(I'm trying to hunt down that talk, but not having much luck.)

<comment><USER3> I saw that talk and I can tell you that he looked very confused. He was just in the need for an excuse to develop just another scripting language. You could see that he had not much experience with Lisp and that Lisp was not something that he actually needed. I think he knew Lisp mostly 'in theory'.

If you think that he is a pretty smart guy, then I would say that there are many Lisp implementations that are way ahead in terms of implementation technology - Matz's Ruby implementation is in the Lisp world several decades behind the state of the art. Ruby is one of the slowest scripting languages and has a very much ad-hoc design. It does useful things for many people, and that counts. But from the technology it is Ruby that is a huge pain in the ass. Just see how people struggle to write a decent compiler for it. Instead it is just another simple interpreter with a C core for the interpreter implementation and parts of the library. Ruby is fast where you stay in with the library functions that are implemented in C - otherwise it is a pain.

The better Lisp systems are also written in Lisp and their performance is sometimes 10 to 100 times of what Ruby offers - while Lisp offers also lots of dynamic features and the code as data paradigm.

<comment><USER5> If you did, indeed, see the talk then i think you missed the point.

<comment><USER3> <http://rubyconf2008.confreaks.com/matzs-keynote.html>

He sounds confused.

Started with BASIC: 'I could Make Intelligence'. ???

Then he found Lisp in a magazine article and 'fell in love with it'. 'BASIC aristocracy' vs. 'Lisp democracy'???

He liked Lisp from a book, but 'unfortunately he did not have a computer that could run it'. In University he used Emacs Lisp and it did not make him 'happy'. Parentheses? No? He had no problems with it. Macros? Partially. 'Smart people just underestimate oridinarity (sic) to use Lisp'. 'We are too ordinary to use Lisp'. Aristocracy. He is happy with aristocracy, as long as he has power.

The whole video is so painful...

<comment><USER5> The whole point is that there's more to languages than just "technical correctness". Lisp is great technically and theoretically, but in other respects it is quite a ways behind (for instance) Ruby. So Ruby has some big problems (speed, to use everyone's favorite example) but just saying "Ruby is slower so we should all use Lisp" is a bit ridiculous. That's what he was trying to say.

(He's also not a native English speaker, so i cut him some slack on that front.)

<comment><USER3> I was not talking about 'technical correctness' (though the literature how to implement languages does exist - just start with Steele's papers - <USER2> describes efficient compilation some thirty years ago), but about 'technical capabilities' - and it that area Ruby is lightyears behind Lisp implementations. I'm also not saying 'Ruby is slower so we should all use Lisp', I'm saying: Ruby is much less capable than Lisp, so it neither is a Lisp nor is it able to replace Lisp for the tasks where people use Lisp. For an expert Lisp programmer there is little reason to use Ruby anyway. Ruby has a larger user community, but that does not help me when Ruby simply does not provide the capabilities I need - the user community could be ten times larger and the number of libraries could be also even larger. It does not help if the libraries that I'm interested in are not available and probably never will.

Matz designed Ruby for so-called 'ordinary' people with him to do the language design. I can tell you for sure that I neither like his design nor do I want him as the language designer. In the Lisp world the implementors role is to empower the user, not make them dependent. I need a new control structure? I write one myself. I don't have to wait for some benevolent dictator, who probably does not get basic designs right - just look at the confusion of blocks, lambdas, etc. in Ruby.

(also there is no excuse for putting confused stuff on slides, even when he is not a native speaker - lots of people (including me) are no native English speakers and I haven't sensed this amount of confusion Matz shows)

That Lisp is too complicated for some people is not news, still Emacs (which he tried) now comes with a standard library of a million lines of Emacs Lisp code for all kinds of editor extensions. Emacs Lisp code that has been written by very different people and obviously a lot of them learned enough Lisp to write sophisticated applications based on Emacs (like GNUS, calc, the various mail modes, org mode, ...).

Lisp is also not only great technically and theoretically, but some people found it practically. There weren't ten maintained Common Lisp implementations if there were no users for it. For example the talks at the Lisp Meeting last sunday here in Hamburg described several applications in Lisp: an airline reservation system (developed by a team of hundred people, fifty of them Lisp programmers), a visual reactive programming system, an aircraft analysis tool, a reasoner for the semantic web, a visual simulation system, machine learning applications and some more.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER6> It's always bothered me how imprecise we are with words as computer scientists. Lisp is not a language in the sense that Python or Java is. PLT Scheme is much (much!) farther from elisp in feature sets than Python is from Java.

The only thing unique to Lispy languages (and really _not_ at all that hard to understand) is the language syntax and the way the compilation rules are late- bound. That is, the compiler is intended to be extended by the user. Roughly, you're intended to be able to say "unless (...)" will translate to "if (!...)".

The rest of the design decisions made aren't even that outlandish: you still have text which is parsed and either interpreted or compiled into machine code, which is run. More foreign (and interesting), I think, is the research being done at Alan Kay's lab now:

<http://piumarta.com/software/cola/>

</comment><comment><USER7> "My prediction: someone will get tired of waiting, and they'll Torvalds Arc into obsolescence before it's ever released."

This is what Rich Hickey did with Clojure, more or less. So this was a pretty accurate prediction.

<comment><USER8> I wrote a blog post about this very thing about 6-7 months ago: [http://blog.fogus.me/2009/02/06/yegge-clojure-arc-and- lolita...](http://blog.fogus.me/2009/02/06/yegge-clojure-arc-and-lolita-or- days-of-future-past/)

</comment></comment><comment><USER9> Don't miss Pascal Costanza's opinion in the comments, to put things in perspective from an expert Lisper:

 _My impression is that you [haven't used] neither Common Lisp nor Scheme on a regular basis, and/or in a considerably sized software project. Most of the issues that you mention are "academic", in the sense that they are theoretical problems which tend not to bite you in practice_

<comment><USER10> I am particularly amused by this guy's ranting about hygiene and macros. I have written quite a bit of lisp, and debugged plenty of macros, and once you have some experience with gensyms you really don't look back and wish there was a hygienic system.

<comment><USER11> Hygienic macros are a bigger deal in Scheme, where everything is conflated into single namespace (you know, the land of LST). His rant about macros and namespaces is a good hint he didn't practice Lisp that much.

</comment></comment></comment><comment><USER12> I wish he still wrote this blog.

<comment><USER13> I really wish that he did too. Seems that All the negative comments made it not worthwhile which is just a damn shame because the rest of the world has to lose out now.

<comment><USER12> I was hoping he would have done what other controversial(Zed Shaw) and not so controversial(Joel Spolsky) blog authors have done and just turn off the comments and moved on, rather than shut it down.

However, he is not indebted to us to keep writing so my opinion doesn't really count in that regard.

</comment></comment></comment><comment><USER14> An interesting follow-up: Eric Kidd on "Why Ruby is an Acceptable Lisp"

<http://news.ycombinator.com/item?id=825809>

<comment><USER10> The OP was a followup to the article you cited. Is that what you meant to say?

<comment><USER14> I meant to say what I said, but I like what you said as well :-)

</comment></comment></comment><comment><USER15> This article was published in 2006. Why is being posted again?

<comment><USER16> Don't worry, it will soon grow a (2006) in the title, so people will know it's obsolete.

<comment><USER14> With respect, _old_ is not synonymous with _obsolete_. I find this especially ironic since we are talking about a post written less than half a decade ago talking about a language invented more than half a century ago.

Of course, if you feel that the post is obsolete due to progress made in Lisp since the post was written, I'm extremely interested in hearing how things have changed.

<comment><USER15> The article does not mention clojure, which is an acceptable Lisp.

<comment><USER6> Clojure is _not_ an acceptable Lisp. It's a step in the direction of Lisp from Java, but is a step backwards from most other Lisps.

<comment><USER17> How so?

I've been pondering Clojure as "Lisp with Java libs! Hooray!", but if there are notable flaws in its Lispiness I'd like to hear about them.

<comment><USER18> I think the common complaint is that that it isn't really Lisp all the way down - it's Lisp syntax that drives the JVM. Therefore, it is a False Lisp; it dresses like Lisp, and convinces the unwashed that it's Lisp, but it's actually leading us astray.

See <http://www.loper-os.org/?p=42> for more.

<comment><USER6> _it's Lisp syntax that drives the JVM_

See, this wouldn't bother me so much if it assumed the user knew the JVM instruction set and built up abstractions around it. But no, that's not what it does. It creates another "language", meaning "obscuring abstraction" that _isn't_ friendly to inspection.</comment></comment></comment></comment></comment></comment></comment></comment>


iStartup@HK - <AUTHOR> https://istartup.gov.hk/

<comment><AUTHOR> The Hong Kong government have been promising to help grow the Startup community in HK, and this is finally what they've released?</comment>


Functor is now a superclass of Monad in GHC HEAD - <AUTHOR> http://darcs.haskell.org/libraries/base/GHC/Base.lhs

<comment><USER2> It's no longer April 1st in most of the world.</comment>


Plan B?! - <AUTHOR>

so it looks like there many good startups that didn't get accepted. perhaps for the simple reasons of too many aplicants, single founder, bad application writing skills,  etc...
Also, many will not be discoraged by this and continue to work on there stuff.
anyway I was thinking maybe we can create some sort of a group and just get together based on the same model as yc. of course without evrything that YC provides but just working with other founder is realy good.
I have some thoughs on how this might work, like we could vote on startups to join in, select a physical place or just remotly, invite experts, pich in in funding for small expenses, etc.. but first I like to hear your thoughts... <comment><USER2> you need a limitus test to keep out the dreamers (only people who are actively working on something). but a simple weekly dinner between a half dozen startups could work as a great motivator and forum.

<comment><AUTHOR> You are right. I thought mabe we would vote on eachothers work before accepting.

The bigger problem is location and if we'll be ready to move :)</comment></comment>


Ask HN: Siri to become search engine to compete directly with Google Search? - <AUTHOR>

I had this thought last night during dinner and maybe it's already been discussed but is it Apple's plan to use that new massive data-center to expand Siri to be an online search engine intended to compete with Google (eventually)?<p>It would seem that they could take this approach and it would be a fitting way for Apple to 'attack' Google on their homefront the way Apple/Jobs felt Google attacked them on mobile/Iphone. <comment><USER2> Actually i see Siri as more of an interface revolution than a search play, although in a mobile OS search would be a key feature of an operating system. What gets me excited is the idea of Apple creating an API so that functionality can be added to third party apps. I do game stuff and the idea that you might be able to talk to a character is very powerful. But also if you think about other apps there are so many possibilities.

</comment><comment><USER3> There is already a discussion that you maybe interested to follow-you can find it in the front page:

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


Will There Be a Draft? Young People Worry After Military Strike - <AUTHOR> https://www.nytimes.com/2020/01/03/us/military-draft-world-war-3.html <comment><USER2> Absolutely not.

Combat mass is no longer about raw human numbers.

Plus nomenclature and terminology around war is backwards and confusing.

Let me explain.

Conventional conflicts(WW1, WW2, Korea, Iran-Iraq 80-89, etc) requiring big human numbers are incredibly and increasingly uncommon.

Unconventional conflicts(Iran-US, 40+ yearS and counting) requiring fewer/better trained humans are incredibly and increasingly common.

This is an ongoing unconventional war entering its 5th decade with roots extending back 7 decades(Mossadegh coup in 1953 Iran) and incongruent ideological conflict extending back millenia.

And even IF there were a draft, the vast majority of fighting aged men and women are dangerously unsuitable for military service due to very poor average health and fitness.

IF there was a draft, the overwhelming majority would fail to meet minimum entry health & fitness criteria.

<comment><USER3> To get it out of the way: there isn't going to be a draft.

Nevertheless, maybe there should be.

Not mass enlistment for large scale combat, but drafting people who have critical technical skills should be considered.

The current approach of filling gaps in technical knowledge with contractors is toxic.

If people have rare, technical knowledge necessary to safeguard our country, they should be required to be in the reserves.

I believe Switzerland has a system where citizens hold a role in the military analogous to the civilian position.

That's a great freaking idea.

<comment><USER4> So the pay goes down, the work becomes forced, and non-military technology innovation continues to pay the same high rate as before and you think this would be an efficiency gain? The government can't just will cheaper work into existence by saying it, everything has its cost eventually.

If your goal is to cut costs then just lower budgets. If your goal is to get people because nobody wants to then maybe you shouldn't be at war since nobody wants to support it.

And yes, you're civilian skills are considered for your role in most any military. Most places just don't have mandatory service.

<comment><USER2> I'm not a big fan of mandatory service.

But the 5 Eyes militaries don't do a very good job of leveraging civilian skillsets of their Reserve/National Guard soldiers, sailors, and airmen.

We talk about it all the time, and we try, but we haven't been consistently successful.

A few halo casts to brag about?

Absolutely.

But consistently?

Nope.

Tons of latent intellectual and SME value waiting to be captured and focused.

</comment></comment></comment></comment><comment><USER5> Of course there will be. "It may not happen overnight, but it will happen."

Wars of choice (i.e. most US wars) can be turned on and off when required. Those can be waged without needing to use the draft.

Other wars, that continue with a determined opponent (Vietnamese War, for example), can not be turned off unilaterally and must proceed till a defeat or victory.

Those wars will always require a draft if "the war situation has developed not necessarily to [the US's] advantage". (Paraphrasing Hirohito's Speech regarding Japan's surrender.)

</comment><comment><USER6> No</comment>


HN Feedback on Dojo Learning's new developer API, FB app, and major UI changes - <AUTHOR> http://www.dojolearning.com/siteblog-post-action/id.28/title.announcing-dojo-learning-1-5

<comment><AUTHOR> Today we've launched a ton of improvements we've been working on for the past few months, including a complete developer API (includes client libs for Ruby, Python and PHP), and a Facebook app to correspond to new social learning features we've added (and lots more).

I thought it would be good to get a fresh bit of feedback on our site from the HN community, who've been a great source of inspiration throughout our development.

</comment><comment><USER2> I was expecting this site to be about the Dojo javascript toolkit and was really excited that someone had finally written Dojo documentation that didn't suck...

<comment><AUTHOR> Sorry to disappoint you there. Although, we do support source code highlighting in lessons, so some Dojo toolkit docs could easily be made with Dojo Learning. For example, here's a lesson that has code in it:

[http://simian.dojolearning.com/course-contents- action/id.33/...](http://simian.dojolearning.com/course-contents- action/id.33/chapter.2)</comment></comment>


Tell HN: ACTA negotiations to conclude in 2010 - <AUTHOR> http://en.wikipedia.org/wiki/Anti-Counterfeiting_Trade_Agreement#6th_Round_of_Negotiation.2C_Seoul.2C_November_2009 Everybody here knows if the leaks from the treaty are real ACTA will be a very bad thing. Since negotiations are supposed to conclude in January 2010 it's probably best people start raising hell now. I've called and emailed all the congressman and the senators for my state. Here's what I'd do if I knew how:
1. Make a website where you type in your zip code and you get contact info for all the senators in your area, as well as a message explaining why it's important to stop ACTA.
2. Free VOIP from website to congressman/senators.
What do you all think? Any other ideas as to what we could do? Even if you don't think it'll make a difference it's better to at least do something. <comment><AUTHOR> The text I posted isn't showing up for some reason. If this is a double post sorry about that.:

Everybody here knows if the leaks from the treaty are real ACTA will be a very bad thing. Since negotiations are supposed to conclude in January 2010 it's probably best people start raising hell now. I've called and emailed all the congressman and the senators for my state. Here's what I'd do if I knew how:

1\. Make a website where you type in your zip code and you get contact info for all the senators in your area, as well as a message explaining why it's important to stop ACTA.

2\. Free VOIP from website to congressman/senators.

What do you all think? Any other ideas as to what we could do? Even if you don't think it'll make a difference it's better to at least do something.</comment>


Millions in cryptocurrencies frozen after Canadian founder's death - T-A https://www.reuters.com/article/us-crypto-currencies-quadriga/millions-in-cryptocurrencies-frozen-after-canadian-founders-death-idUSKCN1PU025 <comment><AUTHOR> Discussed 3 days ago:

[https://news.ycombinator.com/item?id=19060985](https://news.ycombinator.com/item?id=19060985) (178 points/125 comments)

</comment><comment><USER2> Wait really? [https://text.npr.org/s.php?sId=691296170](https://text.npr.org/s.php?sId=691296170)

$200m, and only one person had the password? Is this really how crypto exchanges are run? I had a co-worker who worked at one explain a much more thorough process to me.

This story almost makes me want to go apply for a job at the SEC.

</comment><comment><USER3> "Death" from Crohn's disease while he happened to be in India, and had the only private key for 90+ million dollars. Sure.

<comment><USER4> It doesn't sound fishy at all

I'm 95% sure this is a bizarre exit scam

<comment><USER5> If the money moves everyone will know.</comment></comment></comment>


Show HN: Basic Feature - <AUTHOR>

Being a dev and covering support means I see a lot of feature requests. A lot of them are totally valid requests written by nice people. On the other hand, there's also a lot that fall somewhere between silly and insane, and often hilarious. It happens often enough that I want to curate a list of the funnier stories, and so the idea for this site was born.
http://basicfeature.com/
Of course, the site is nothing without content. If you're a programmer you've probably got a few good ones, so consider this a call for submissions. I'm only looking for dev-related stuff, not design; clientsfromhell.net is already doing a great job in that department. Any feedback about the idea is welcome! <comment><USER2> Have you considered getting content on there using your own knowledge? Being first, or even somewhere close to first, is weird on a site..

Neat idea, though. I would read it in the same vein that I read clients from hell.

<comment><AUTHOR> Yes, I am digging up some gems from my inbox. You're right, I should have done that before sharing the link. Submissions are anonymous so I hope that lowers the barrier to posting.

</comment></comment><comment><USER3> Much prettier than thedailywtf. Hope you get some more posts. Looks nice.

</comment><comment><USER4> Cool, submitted one...</comment>


Spreadsheet-style Programming with Lisp - <AUTHOR> http://common-lisp.net/project/cells/

<comment><USER2> I've written a small tutorial about cells: <http://github.com/stefano/cells- doc/tree/master></comment>