CoderPad is really, really good. I've interviewed using a bunch of alternatives, and CoderPad is far and away the only one that works reliably all the time. It always cheers me up when a company tells me they're using it, because I know it won't lag, the vi keybindings will work, the built-in terminal will work, there won't be weird interface glitches, every language I need will be there, etc.
This sounds hyperbolic, but I've never wanted a feature during an interview and found CoderPad to lack it.
It always cheers me up when a company tells me they're using it
But how often in real life does a manager come to your desk and say, implement this feature RIGHT NOW and by the way I'll be standing over your shoulder the whole time? Would your first thought be, damn, I hope my key bindings work?
It doesn't matter how technically good a thing is if it shouldn't even be a thing in the first place...
An interview isn't a surprise attack, they're usually scheduled days in advance. Good interviewers will usually characterize what kind of questions you can expect to receive ahead of time. I'm sorry that you've had bad experiences during interviews, but the process is difficult for both parties. It can be very difficult to assess both candidates and companies without spending an inordinate amount of time in the process. CoderPad offers a particular cost-benefit tradeoff, and longer take-home assignments offer another. Onsite projects offer yet another, etc.
In real life, my manager tasks me with doing something, and then it's up to me to figure out how to do it.
Sometimes, there's already a library or SaaS product that I could use, but the catch is we have to pay for the product.
For something that isn't a core business expertise, I could take an afternoon, implement it myself, and then spend all of my time maintaining that instead of working on our company's product, which is ultimately penny wise but pound foolish.
Smarter companies will realize some things are worth paying for, and seeing a company that has picked coderpad demonstrates that they are willing to pay for quality software that works.
> It doesn't matter how technically good a thing is if it shouldn't even be a thing in the first place...
We should have universal basic income and I shouldn't need to have a job not to be destitute, but until then, I'm going to keep going in to the office.
If the job has a large coding component, the candidate must code at some point in the hiring process. Take-home problems work out worse than interviews, primarily because coding isn't a solitary practice.
Discussing a problem, getting a shared understanding and outline of the solution, and then seeing how the candidate turns that solution into code - that's the kernel of a coding-heavy job, and it needs to be observed during the interview process to make even an approximate evaluation of their ability.
Other forms of observation can substitute: strong personal recommendations from previous co-workers, or famous accomplishments visible from afar, where there's no doubt as to who exactly accomplished them. But observation must be made.
The job I'm recruiting for requires someone to be able to write code. Also, there are a lot of bullshitters in the world. Given these facts, I conclude that writing code in a an interview for a position where you'll be writing code is necessary.
Vincent says that building a solo business requires you to work on a boring idea, i.e. something everyone already knows the value proposition of, e.g. punch card on computer.
How does one learn about these "mundane" issues that small business owners face? The examples I've seen from Vincent / Patrick McKenzie (patio11) are happenstance (e.g. I happen to hang out in this community, so I know). Like many of us here, I'm an engineer in a tech company and does not naturally have small business owners in my circle.
So what's an efficient way to reach out and understand small businesses' problems? Online forums (which one?), local business associations?
I actually have a lot of thoughts about this that are hard to condense, so I'll just say this: curiosity isn't a personality trait. People tend to model curiosity as just something you "have" or not, but curiosity is actually a function of knowledge you already have. You can only really be curious about things that are adjacent to things that you already know about. I would say the best way to find ideas is to just do a lot of different things. There's no formula, but you can maximize your odds by just learning about as many different kinds of things as possible.
The best problems to solve are the ones you experience on a day to day basis, that you are personally invested in. That's what Vincent did here. It's much harder to build for other people because it requires a lot of user research & constant feedback & it's often difficult to even get honest feedback. The trick is recognizing a problem as worthwhile to solve.
Here are a couple of ideas from my day-to-day as a programmer:
- Code review reminder tool. Code reviews are great but there can be social friction to getting them done. I think the typical way this works is to @ mention someone which sends them an email & then ping them on slack if they don't review it w/in a certain amount of time, but I always feel at least a little bad about pinging someone on slack.
- Better software to sync local files to servers for development. A lot of devs run linux machines on aws, develop code locally, and then somehow sync their code from local to the dev server. I feel like people often just write their own scripts that amount to using rsync and some kind of system event watcher for file changes.
- More complex reminders. I want task and date specific reminders. So, for example, remembering to buy someone a gift for their birthday. I want the first reminder 3 weeks before and then a reminder everyday until I resolve.
I dunno if any of these ideas are worth solving though. I don't know if I'd pay for them..but they are things I want.
Focusing on your own day-to-day problems ends up with the various VC-funded "mom apps" to summon contractors who to come to your house, pick up your room, and do your laundry for you, make that statement old advice and not to be taken literally.
I agree that more complex reminders with the features you describe would be quite cool, for both code reviews and birthdays would be cool, but you admit that the business case isn't quite there yet. (There is a glut of reminder apps on the app store, those features probably exist between all of them.)
Better sync software falls under the category of development tools; even Visual Studio is free these days (in the form of VS Code) because selling to developers is notoriously difficult to sell software to, because they know how to code. (There is also no shortage of open source inotify+rsync based sync tools.)
I suppose it's also about broadening your own horizons so the space of problems that apply to you is a little wider than "mom apps".
Fwiw, it's also a lot easier to hate on every idea than to believe in it :-D. I'm the first to be pessimistic, but I learned that you have to try something & iterate on it even if all you can do is find fault with every idea.
These were also ideas I came up with in like 5 mins. Just showing that ideas are a dime a dozen and it takes exploration to actually find something that works.
Do you have a hobby that's orthogonal to your tech career? I try to go to photowalks and photo meetups as much as I can. I end up meeting a more diverse set of people and because I'm a "techie" they'll often open up about their tech problems. Giving a few suggestions for free then provides an opportunity to ask them about how they could improve the automation in their lives.
Another option is owning a house, or taking some interest in the various maintenance folks that run an apartment building. You encounter lots of people with no systems, but not enough knowledge/time to get something working on their own. Or, even better, those that have been burned with custom shitty software. I had to get a tree trimmed and the arborist was a goldmine of information on the software available, and the problems his company had with it. Markets like these are ripe for disruption with simpler and cheaper SaaS solutions.
I've been told that opportunities are easier to spot in areas where you don't spend a lot of time.
I'm guessing that this is because you haven't already accepted the status quo in those areas, and because people with your skillset who would beat you to it may not have spent a lot of time there yet.
I think opportunities are easiest to spot in places where you are newly spending alot of time. You are quickly coming up to speed on the status quo, but haven't been inured to it yet.
You also still have this sparkling energy at all of the possibilities that can only fade with time, whether you tackle a problem in the space or not.
I feel like the opposite's true for me (sample size: 1). I spent a bunch of time in tech support, then built a bunch of tools to speed up stupid manual time-consuming stuff. That got me a promotion into programming, and now I'm out of direct contact with the day-to-day issues in support so I generally rely on support staff to make additional feature requests now.
But then, I don't tend to accept the status quo. I think there are certain personalities that never do. There's always something else to challenge/improve.
check out what are the sw's your company is using? can you make a better version of it? what about the internal tools? your company might not be paying for it but they may be useful to other similar companies? can u create them? being in a bigger organization also gives you certain advantages whether u realize it or not is upto you. some good examples are kubernete and graphql. really big orgs had these issues and solutions way before it was realized by other medium scale enterprise.
This is actually a fantastic interview and I'm surprised it isn't higher up.
I remember first encountering CoderPad a few years ago and being immediately sold on it as a development hiring manager. It's an excellent product and I'm not at all surprised to see it achieve such success.
I actually ended up finding a security issue in it back then, and Vincent had it resolved within two hours of me reporting it, which I was extremely impressed with.
Two years ago I integrated CoderPad into a technical-screening-as-a-service product I was involved with; Vincent's responsiveness and focus were very impressive. I'm thrilled to see him making such progress!
In the event that someone else is looking to integrate CoderPad into their product, here's the Java client library I wrote for CoderPad in 2015: https://github.com/skidder/coderpad-java-api
> For instance, in CoderPad, there are a few ways to abuse our quota system to get more than you paid for. Clamping down on this would require making the product more annoying just to penalize bad customers. Every time someone tells me I should be more strict about this, I ask, "How much effort should we spend trying to extract value from people who clearly don't want to give it to us? Shouldn't we just try to attract better customers?"
This is actually pretty sneaky. It takes a long time for the corporate gears to grind and get a contract signed. Meanwhile the engineers are finding the product more and more indispensable because the product is fantastic and there's not anything really stopping them from going over the limit. Eventually a signature is inevitable, even at the (to me) eye-popping price point because everyone in the org loves it.
> In general, we want CoderPad to mirror a modern development environment as closely as possible, and we jump through a lot of hoops to make that happen.
I'm curious about your thoughts on Floobits, which provides a shared buffer using the developer's native IDE. If your goal is IDE parity then it seems like they'll always have you beaten.
I think that as an interviewee I would prefer my familiar IDE. And as an interviewer I want my interviewee to be as comfortable as possible. I don't do whiteboard coding, as it introduces a artificial barrier of difficulty that interferes with my evaluation. I think the same argument applies to making the candidate write Scala code without being able to determine the type of an expression at a keypress or step through line-by-line in a debugger, or even just to be unused the unfamiliar keymappings.
So what's your pitch for CoderPad in the face of Floobits? Reliability? Ease of set-up? The replay over time feature in CoderPad is really neat for the interviewer but I'd rather the candidate feel a bit more at ease than to have that feature.
BTW, love your product. We use it where I work! :)
Truthfully, I really just wanted to buy something instead of making CoderPad. I imagine it's certainly possible for floobits, or atom teletype, or something else entirely to get enough adoption to render our product mostly useless. We're nowhere near there, but I wouldn't mind that happening. We'll make something else or I'll switch careers.
A nice part of the Coderpad experience is zero-setup for the interview candidate. Being web based is a huge advantage here. I wouldn't want to waste any time debugging plugin issues, firewall configuration, etc.
Requiring the developer to install and configure software locally is a higher barrier than you think, especially compared to the experience of "go to this coderpad URL".
Came here to ask the same question. Been a while since I used the gem, but I remember it being very useful, and fairly extensible. Sounds like @akanet did not have the same experience. Would love to hear from others if they have run into the same issues, and if so any alternative gem/libs they recommend.
Yeah I thought that was weird. I love using Devise, and it has a lot of great plugins. It's very easy to set up things like OAuth and two-factor authentication. And it's not too hard to customize with your own warden strategies.
Love CoderPad and I think Vincent does the SaaS thing very well. It’s a product with a strong value proposition, a reasonable pricing model with free tier to get you hooked, and puts enough features and attention to UX in to stay valuable and ahead of competition. Furthermore, Vincent has done a good job of judiciously injecting his personality into the marketing and communications about the product, which shows he understands his market well.
If I ever aim to build a strong, low-overhead SaaS business, I would definitely look to CoderPad for inspiration on execution.
I'm impressed with everlane, the company he was working for at the time he implemented coderpad. Many companies, small or large, would have either prevented him from doing so, or would have tried to claim his creation their own property (with some credibility).
Mmm, I just checked what their business is and it seems to be totally unrelated to development, maybe that helped.
Everlane is a great place to work! There are lots of creative, interesting people there making products that people actually want (clothes). If you're interested in working there, I encourage you to apply: https://jobs.lever.co/everlane/2ea2ce6a-a85c-40e1-8504-c2d23....
He and dhh (of Ruby on rails) should form a club or something. There's so much buzz around startups but sometimes a business is the way the go. The issue is even a small business is much more difficult to succeed at than a regular job but it doesn't have the huge possible success of a startup..
I never do online tests, like with CoderPad. Why? The tests are flawed and subjective. I can give any interviewer 1 assignment that will make him/her fail miserably. Should I not do that first to see if the lead/manager is competent? Of course not! We are stupid applicants/beggars! We are not allowed to test our superiors for competence!
I cannot imagine the author of CoderPad would be happy to be in the position of an applicant again having to do such a stupid test. He is only happy because he now makes so much money of that process and never have to be an applicant again. Well done, we less lucky devs are f* anyways.
I did many interviews, and enjoyed most of them. I had some bad ones, which I either failed or refused to do. Software devs are very highly paid professionals and can afford to refuse opportunities with quite a bit of discretion. I encourage you to continue refusing tests you find stupid or poorly designed. We encourage our clients to ask fair, useful questions, but the only way to change the world is to vote with your feet.
> I had some bad ones, which I either failed or refused to do.
And that's the other reason I never do online tests. I don't know what the company and for example CodePad will do with the data collected from me. Will they store, sell and/or share it? Will CodePad reuse collected data in any way if I do an interview for another company? Etc..
I sort of doubt this will change your course of action, but we of course do not share your data. That said, any company that asks you an interview question has probably seen hundreds of answers to said question already and probably has neither the inclination nor ability to profit from somehow collating your answers.
If anything, companies are much more concerned with candidates sharing questions with each other.
Right, what you type is shared with the company interviewing you. Isn't that kind of the point of the product? Isn't that true in whiteboard coding interviews as well? Maybe I'm misunderstanding, but getting worked up about this sounds like being upset that GMail sends your messages to recipients' mail servers.
I think akanet was clarifying that CoderPad doesn't share your data with any other companies.
If you're worried about the company you're interviewing with doing shady things, I'd suggest interviewing somewhere else.
The interview process is a two way street, and a good onsite will include time for an applicant to talk to a manager at the company which will give you time to determine if that manager is competent, as well as a good fit.
Furthermore the interview test "FizzBuzz" was announced back in 2007, yet there are applicants who claim they can program but still fail such a basic test. (Failure modes include the applicant thinking they are "too good to take the test" and refusing to trivially demonstrate they are able to code. Choose your reaction carefully.)
>>The interview process is a two way street, and a good onsite will include time for an applicant to talk to a manager at the company which will give you time to determine if that manager is competent, as well as a good fit.
The candidate is never allowed to see how manager solves technical puzzles.
I was asked to complete a screening test on CoderPad earlier this year and got rejected because, from what I could tell, my edits didn't sync with their backend for some reason. Of course I couldn't prove it so I can't blame the company. It sucks because I came up with what I thought was a pretty good solution to the problem. Make a copy and attach it in a notification email to your interviewer!
Anyway, just one more reason to be weary of these types of tools.
Hackerrank tends to offer a different cost-benefit tradeoff in interviewing - less time invested on the part of the company, and more time invested by the candidate. I don't particularly like this approach because I think higher-skilled candidates are more likely to churn when given impersonal treatment.
We actually go a bit further in the interest of giving you more power - CoderPad uses ipython for its Python repl. You can read more about it at https://CoderPad.io/languages#python
terrific! i was rooting for this guy ever since i watched the youtube video. good to see that its successful in a tough market even though big players like microsoft have added these features in their own offerings.
This sounds hyperbolic, but I've never wanted a feature during an interview and found CoderPad to lack it.