Don't focus on the domain, focus on the coding. i.e. don't talk about what they were doing, talk about how they did it. Where there any performance considerations? concurrency? what did they do for testing? was it automated? How the thing deployed? do they maintain it? etc. etc.
In doesn't matter that in all of the above I'm talking about the code used to talk to little green men on Mars (which you know nothing about), but it matters how I used code to solve all the problems which are common across all kinds of software.
How much faith do you really have in these questions?
This could be your entire 45 minute interview:
Where there any performance considerations: Yes, the spaceship was extremely slow at first. After reverse engineering the launch protocol, we discovered that we could increase speeds by 5x simply by limiting the fuel cell usage. "Oh tell me about your rocket fuel cell usage"- Well, we have this thing called a fuel cell. It takes 5 batteries. 10 minutes of business logic later...
* Now let's spend 25 minutes talking about infrastructure and team dynamic *
Concurrency: None needed here.
What did they do for testing: We used Jest.
Was it automated: Yes.
How was it deployed: Github / Heroku / AWS
Do you maintain it: Yes, we maintain it with my little green friends. We each take turns writing code and maintaining the rocket protocols. It's actually quite nice.
* Oh, well I guess we're out of time. *
Congrats, you just hired a guy who read a few blogs and made up a few stories.
> How much faith do you really have in these questions?
It depends entirely on how you direct the converstation.
> After reverse engineering the launch protocol, we discovered that we could increase speeds by 5x simply by limiting the fuel cell usage
Tell me HOW you reverse engineered it. What tools did you use. What source did it wind up as. What problems did you encounter?
>Oh tell me about your rocket fuel cell usage
(Don't ask that question because you don't care about rocket fuel cell usage, you care about if this person is a good coder. Ask them questions about code and their person software process!)
>What did they do for testing: We used Jest. Was it automated: Yes.
Obviously it's on you to tease out more than one word answers.
If you want to have a conversation with somebody and learn if they're capable of something, the onus is on you to direct the conversation and get what you need. If you're willing to accept one word answers, then I'm thinking this "informal chat over a few hours" approach is not for you.
Agree with all your points, I'm just coming from the perspective of how I embarrassingly hired a guy who could answer a lot of these questions but couldn't solve the problems we needed him to solve.
And that, by switching to the "Hello, nice to meet you, okay let's open up Coderpad and solve this problem", as "inhumane" as it sounds, and I KNOW we will continue to see these forum threads for years to come, it actually WORKED to find some seriously amazing candidates who could actually showcase their skills LIVE.
It's like, there's knowing your implementation details, and there's actually implementing something.
Honestly, as a candidate, I prefer the technical challenge now. Partly because my brain isn't equipped to even remember deep implementation details of specific projects. Think about it, how much can you really remember from the last project you worked on? Is that result going to give you more concrete details than actual code on a small problem? I think companies will continue to use Coderpad because it just gets to a clear result faster.
Obviously the way this goes down is different for each interviewee and each interviewer.
I personally remember a lot of details from some of my favourite projects, but I wouldn't hesitate to say "let me grab my laptop and I'll show you" because it will be clearer. Then I'd walk the interviewer though all the details of the code, deployment, testing, etc. etc. etc.
I don't think we can evaluate whether someone can do a decent job in 45 minutes. Or an hour. Sure, we can spot and confirm a hopeless case in 20. But beyond that, an hour is simply not enough.
I've been involved in hiring and interviewing for close to 15 years. The best results have been with candidates with whom I've arranged to have at least 90 minutes, and where that time ended up being well spent. It takes a while to get comfortable, to warm up, to establish a common ground. And it sure as hell takes time to actually discuss a technical problem, whether it's design or a programming problem, as the solution unfolds.
The desire to shoehorn an interview into at most 1-hour slots is not designed to find the best candidates. From where I look at things, it's designed around the idea that most business meetings are booked for one hour each, and the cadence in the day must fit the business of, well, doing business. And it kind of works, because everyone (or near it) has the context and shape of the problem fairly clear in their heads.
But for an interview? A process, where by definition you are dealing with people who are not well versed in your business? Companies book 1-hour interview slots because it's convenient - for their employees, including those who have no part in the interview process, but who are expected to attend other 1-hour meetings with the people who are involved.
The gauntlet of 1-hour interviews feels like a very much intended consequence of the organisation thinking in terms of 1-hour slots for everything. The result is a grueling exercise very few like, and almost everyone with experience despises. It's bad for the candidates, it's bad for interviewers, and I'm pretty sure it's bad for the companies.
But it keeps getting done that way because the cargo-cult of 1-hour slots for everything can not be reasoned with, or deviated from, results be damned.
Just think how well you would do the engineering and programming part of your profession if you had to carve everything into 1-hour slots. After all, PG wrote about it back in 2009: http://www.paulgraham.com/makersschedule.html
I’ve done over a hundred technical interviews in the past 5 years. You can tell a lot about someone by quickly glancing over a project source code, comments, documentation, automation, etc vs talking to them for an hour or two. (to be clear I’m not talking about live coding or take-home problems)
There are bunch of people who can sound smart by just referencing stuff they read online or in the books.
I don’t focus on specific technologies or frameworks because everyone has different backgrounds. However I do focus on CS fundamentals and software engineering practices. These don’t say much about actual coding skills.
You can figure out whether they actually understand what they’ve done by asking the right questions. E.g. not “how did you do that” but “why did you do it this way and not that way?”
The model of precision and correctness being opposing forces that increase in strength the more you hone in on one is useful for me and something that I had never put into words before.
It simply isn't true though, they are rarely required together. His example of the location of a city could have been replaced with gps co-ordinates in the place of a descriptive phrase.
NASA deals with strength and precision together all the time, it's rare that they are both needed on the same task at the same level. The requirements for precision and strength to be shared in an essay is to construct sentences that are clear and cannot be interpreted in multiple ways and then fill in the descriptive detailing with precise information.
Strength takes from distilling multiple possible interpretations down into one clear and correct direction. Precision is about highlighting the qualitative properties and exact quantities of your subject.
They don't conflict. They are rarely needed together.
Reading random GPS coordinates in an essay without a map in a has high precision but terrible understanding. While it's highly accurate, it's almost useless to the typical reader who would have difficulty knowing that the GPS coordinate is within Colorado. GPS coordinates are for maps not essays.
I agree. The context of your essay would make clear both whether you need that much precision and what format to use for the precision.
Three miles east of the center of South Carolina is almost accurate enough? Who knows, not accurate enough for NASA and accurate enough for giving coworkers the idea of where your farmland is located.
it's a really simple problem honestly. Make a standardized test, but don't put an hour time limit on it. If you gave the exact same algorithm test with a 24-hour time limit vs. a 1-hour time limit then had a 1-hour interview explaining the solution to the problem you would be testing for something closer to programming acumen than memorization. I have no idea why tech companies find this so challenging.
The key bit is getting people to explain the answer, not the answer itself.
I have had interviews where the company has done that. I would rate all of those interviews to be very high quality. No nonsense trick/leading questions. Just simple: can this person actually program? What does he understand? What doesn't he understand? I felt like it was obvious what I could and could not do...there was nowhere to hide.
Btw, in terms of investment, this seemed far cheaper for the companies too. What is cheaper? Arranging an hour-long interview where you go through a simple problem that is focused and will clearly identify knowledge. Against an hour-long interview where you probe someone randomly about their life and projects that the interviewer has no idea about (funnily enough, no matter how good you are communicating ideas...interviewers almost always get it wrong).
Cheating? Even with phone screens, some candidates still cheat at these interviews (have some engineer with them answering questions, or looking up similar questions online).
I agree a full blown project over 24 hours would be better, but it's more costly to create questions and score them (if you want to do it in a way where cheating is hard/impossible).
I've seen startups do this, and it works well for them, but might not be scalable for companies that hire thousands of employees each year.
what even is cheating on an algorithm problem? looking up an answer online? asking someone in your social network to help you work through the problem? because that's what you actually do in the real world. as long as you can explain / defend your solution what does cheating even mean.
People would look-up solutions to that exact problem; it's very hard to come up with a unique problem that was never asked before, and questions leak pretty quickly. (especially at larger companies)
The goal of a test is to evaluate whether you'd be a good employee; I agree algorithmic questions are not representative of day-to-day work, but evaluating your friend's ability to help you is out of scope. Companies want to hire someone that has decent programming skills; you can't rely on other people to solve all your problems, you need to have a minimum level of skill.
[again, playing devil's advocate here; we all agree the process is suboptimal, but let's not ignore the negatives of some of the alternatives suggested here]
how many things did you learn by seeing / being taught the solution and how many did you re-invent as you're basically asked to do at an interview? To give maybe a bad example, I don't know how to do a quicksort. I've written it maybe twice in my life by either being taught by a teacher or by looking it up on wikipedia. I didn't have to think of the solution on the spot. I'm not saying I can't think of solutions but still, the majority of my knowledge comes from having been taught and then using that taught knowledge over and over, not from re-invention.
Note I agree we have the same goals to hire people that can do the work not people whose friends can do the work but I'm not convinced that the typical interview puzzles (find the longest segment of an array that contain 3 values) has anything to do with actual work skills. Maybe it would be better with more typical tasks? If the person claims to be back end engineer ask them to write a query to select all people between the ages of 30 and 35 in Nebraska? Maybe if they are front end ask them to implement a select/option UI?
> Cheating? Even with phone screens, some candidates still cheat at these interviews (have some engineer with them answering questions, or looking up similar questions online).
The only difference between these people and those who pass normally is that the latter group looked up the answers to the problem before you even asked them. Nobody comes up with things like mods of dfs or n-pointer problems on the spot. These problems were the subjects of doctoral dissertations the first times they were solved. We pass them because we've seen problems just like it. The system has been gamed and doesn't work.
I heard Peter Thiel make an interesting comment on this recently: that banks avoid political scrutiny because they fund both political parties, whereas Google is overtly biased towards one side (the blue side). This makes the red side hate them, and the blue side neglect them because they think of them as easy money.
The only way to survive political scrutiny in a two-party system is to support both sides, or at least have a plausible threat that you could support the other side if over-regulated.
What are you even talking about? Bitcoin is super liquid with high trading volumes. You can literally convert 100 Bitcoin to $1,000,000 USD in seconds, 24/7, anywhere in the world, without moving the market very much.
I work for a non-profit that has been trying since the beginning of January to get an account at an exchange that will convert a Bitcoin donation we received to USD. So far we have not had any luck, since many (most?) exchanges are not accepting new customers (or explicitly state that reviewing new account applications is their lowest priority) and those that do still accept new customers have multi-week wait times for opening accounts (at one exchange we've been waiting over 3 weeks ago with no reply yet).
As a result, we cannot "literally convert 100 Bitcoin to $1,000,000 USD in seconds", or even 0.001 Bitcoin. In fact, we can't even do so in 3 weeks (and counting).
Could you point us to an exchange that is accepting new signups and will verify an account for a 501(c)(3) non-profit organization within a day (or even a week)?
Thanks very much! That would work fine for us. I'll have to check with others at our org to ensure we can provide all the information, but at least they're upfront about what is likely to be required.
Per my above comment, do you know of such an exchange that is accepting new account registrations? We would be happy to open an account there if they can indeed complete a mid-sized trade (including any required account verification) for a 501(c)(3) non-profit organization within a week.
If you're buying stuff on darknet markets it's nice to be able to do it with freshly mined coins that don't have transaction histories associated with them.
This would only apply to solo-mined block rewards. If you use a mining pool, there is a coin trail through the pool. The pool likely has the IP address records of your miners and can link these to your payout transaction.
Mined coin is only just a little less traceable than exchange purchased coin.
Why does it matter? Once you do the transfer, why would anyone refuse to send you the goods? It's not like they can reverse the transaction - only send back the equivalent amount in the best case.
