Extra funding is great, but if they can't hire, they can't use it.
Take from that what you will about their attitude towards hiring (taking into account that this was 3+ years ago). That said, I haven't met anyone from Top Hat that I personally had a bad opinion of.
I also can't imagine someone whose in this field that doesn't "love the web". Github is good, but it's not the only way to do it.
But, in general, I think you should consider the other side of the argument. The "problem" is that people without public profiles are competing with people with. And if you're looking at candidates and someone has code online that looks promising after a brief examination, I think it's reasonable to take that into account.
It's not that the other person is lazy or "doesn't love the web".
The real problem here is that there is now yet another terrible signal being used as a measure of acceptability in the vetting and interview process.
"Have some GitHub/GitLab/etc profiles" is in the same category as "give the most personable person in the office promotions and raises".
Sorry, it's not at all in the same category, because it's actual output of work. Being able to look at actual code written by the person you're considering hiring is a really great measure of acceptability.
I think we are all agreeing that it's not reasonable to reject someone due to lack of published code. Latch is trying to point out the reality of the situation:
> The "problem" is that people without public profiles are competing with people with.
If you are considering two candidates, who seem more or less equal on every level, but one has an extensive amount of published good quality code and the other does not, it's less risk to hire the one with code.
It's very hard to judge someone's work quality based on personality. I've hired people who seemed good when talking to them but turned out to be not very great developers. I've also hired people who seemed questionable when talking to them, but had decent code samples and/or published code and also turned out to be good or great developers.
I guess to be fair I've never hired anyone who seemed like they'd make a poor developer, had no code samples to prove otherwise, and did badly on coding tests, so maybe I'm missing some great developers who aren't very personable or good under pressure. Frankly I'm okay with that, because I am absolutely positive most of the people in that category are in fact poor developers.
Unless you have a way to verify the source of the code is the candidate with some level of confidence this isn't different from picking the office peacock for promotion.
> If you are considering two candidates, who seem more or less equal on every level, but one has an extensive amount of published good quality code and the other does not, it's less risk to hire the one with code.
How is it less risk, assuming one came to the "equal on every level" decision by some means that evaluates their proficiency reasonably well? The only thing having self-published code signals is a willingness and desire to have one's code public. I haven't seen an actual argument justifying your assertion regarding risk.
This is why I specifically said 'less risk' rather than saying something like 'would 100% be a great hire'. You have to vet everything a candidate says and shows you, including their credentials and past experience. Some people lie on their resumes, unfortunately.
In the worst case, they are a good enough liar to get through the hiring process and you find out later they can't write code or don't actually know the things they said they know, so you fire them (and hopefully you figure this out during a probationary period).
> The only thing having self-published code signals is a willingness and desire to have one's code public.
I was conflating 'public' with 'available to be seen by the interviewer' in my argument, but it doesn't change what I'm trying to get across. Having code public has an advantage before the interview, when the employer only has the resumes to judge by. During the interview a candidate may also be able to show non-public code, but just being able to show any code gives an edge over no code.
Many, many, many people have no code show to show at all, generally because they wrote it for their previous employer. That's fine, but it puts them at a disadvantage over someone who can show code they wrote (public or not).
It's less risk because it's easier to judge someone by code than no code. I don't know why that isn't obvious. Let me put it this way: if you ask 10 programmers what "good" code is, you'll get 10 overlapping but distinct answers, and I think most programmers applying for a job are going to claim their code is 'good'. The trick is really figuring out if your definition of 'good' overlaps enough with my definition of 'good' that we can work together. We could discuss this for an hour or two and I could be 75% certain, or I could look at your code for 5-10 minutes and be 90+% certain.
Just playing devil's advocate.
But to reject a candidate, after he's interviewed by the CEO (so this would presumably be the last interview stage), because he doesn't have "enough" public projects and therefore doesn't "love the web" enough? I think that's stupid.
Edit: misread the parent, we are actually saying the same thing.
edit: hell, it's also already a norm that you have to perform a pro-bono coding assignment as part of the interview process. It's ridiculous to expect an extensive spare-time open source effort plus 2-10 hours of free work for an interview.
It's a bit of a misnomer to think that businesses expect (or require, as some put it). In reality, they can only weigh their options. Of course, the more options they have, the more particular they can be. It is not unreasonable to think that they had many suitable candidates, and the one who had the most visible evidence of past work became the preferred choice of the group.
Mentioning to the OP what helped cinched the deal for what candidate did get the job may have just been meant as a point of information. Of course, it's difficult to say what really happened without being an observer to the events that took place.
Quite recently, I had a conflict on social media, where some other programmer went halfway to doxxing me. Apparently, the worst thing he could imagine saying to someone was that "Your github sucks!" And in his mind that is sufficient for determining someone isn't a worthwhile person.
I remember when SourceForge held the same sway. Now look where it is now. (That said, I do plan on putting some more stuff up there. Though it would be hard to tell, I do have some code that is used commercially, even now.)
In YC, there was this saying (in the context of VCs): believe the rejection, but not the reason. There's little upside in being honest.
I can't speak for back then (I joined after the Top Hat rename), but I'd like to clear up our current practices. We definitely appreciate when candidates have projects or code publicly visible, but understand that not everyone hones their craft through open-source work for one reason or another and would not hold it against someone if their coding contributions weren't public.
They're no longer a startup, yet they act like it. If they didn't raise more cash I would suspect that they would be out of business in a few short years.
So it makes me wonder if Top Hat, claiming to be disruptive and different, is or will eventually employee questionable practices just like the current industry.
Hiring engineers is one of the most important things we need to get right, so I'd hate to think we're doing such a bad job at it. Really sorry that you've had a bad experience with us
First and foremost, don't arbitrarily block Linux users for web interfaces. McGraw Hill does, or did in the past and so do others. I spent hours contacting their useless support and playing politics with the college to get this changed, to no avail. At first, I could simply change my useragent and sneak in, with everything working well enough. When they 'smartened up' (or whatever) a bit, they effectively kept me out thereafter. This was a very nasty and persistent problem for me and one I won't forget.
Also, I never once found McGraw Hill software helpful. It seemed a cheap, shameful way to employ 'professors' otherwise too inept and uncreative to manage their own coursework and classes. At the undergraduate level, many colleges are becoming odious rackets (by my observations). McGraw Hill et al are indispensable allies here. Be different, be effective, be honest about education. Real education isn't a gravy train.
>Even as the big publishers work to increase the proportion of sales that come from digital products, they’re still largely dependent on physical books.
The other issue the large sum of money they want to charge per book. The cost of the books is so high that it is propping up "physical book" market. Mostly because publishers have offered no way to resell your digital or ebook. Lots of students buy used text books, and students that buy new often sell their books to recover some of the cost when they complete the class. The publishers see digital books as a way to prevent students from doing this so that everyone has to buy new (at the ridiculously high prices). The students are going to do what is economical for them, until the prices either drop significantly, or you offer an online marketplace where students can sell/trade digital books then physical college text book industry will be here to stay.
Also to consider is the marketing of student biometrics or other private data garnered through such software, e.g. SmartThinking https://services.smarthinking.com/login/login.php, etc.
SmartThinking also blocked Linux and, in my opinion, provided no benefits to students at all. It was actually used to manage and grade the majority of our assignments. Seriously, the professor would have most assignments pre-graded by SmartThinking; it told the professor what to think! The whole system seemed an embarrassment.
EDIT: I should add that for the amount of time spent in "smarthinking", many physical classes could just as well be conducted remotely. Many students pay for a traditional course, but end up with the majority of their curriculum occurring remotely/digitally. If this is to be so, then the tuition should reflect accordingly and presently it doesn't. Also, I misspelled "smarthinking" by adding two "t"s.
You just found out the truth about textbook prices. What students are really paying for is the test bank for their assessment, the workload for today's instructors is just to great to be able to do paper coursework. In the past, you would have delegated grading to student assistants or the courseload would be smaller, nowadays you have "Mastering Physics" and whatnot. That, friends, is what "disrupting the market" is all about.
Additionally, at my school there is a centralized online interface for professors and students to post notes, quizzes, updates about the course, grades, forum discussions etc. Myself and many students were upset when we had to pay for a 'premium' service which offered no features outside what was offered for free in all our other classes.
All I can say is in order for TopHat to impress STEM students they will have to be very creative in the features that they offer. Though they are sometimes liked by professors, interfaces like TopHat and McGraw-Hill/Pearson are almost universally seen as a rip off by students. Access to propriety notes isn't a feature when very few students pay for any textbooks in their STEM subjects.
The only reason our Quantum Mechanics prof used TopHat instead was because it gave him the opportunity to gouge an extra $100 out of us for a terrible "textbook" that in any other class would be considered lecture notes, full of errors and typos, proof-read by nobody and held to no standard, with atrocious equation rendering and a terrible interface.
He ended up uploading our assignments to TopHat as PDFs but since it doesn't support PDF-viewing we just download those as zip files anyway. Our in-house service supports PDF-viewing in browser, along with powerpoint and other formats.
Not really sure why TopHat exists besides a way to gouge more money out of us students if we want to be enrolled in a course. I could get by without my professor's poor excuse for a textbook, but I would lose 5% immediately if I couldn't participate in the silly attendance system, and more for the online quizzes (although we could use our in-house system to the same effect) so I have no choice but to fork the money over straight to my professor's pocket. As if my 15k tuition wasn't already enough.
They had him and a bunch of other come in on the same day, and write a 16 page exam.
From what I understand, my friend didn't like the atmosphere and was already overqualified so he accepted another position.
But this left a bad taste in my mouth about their hiring practices - but then again, if they are continuing with this, it probably means that it works for them.
1. how you'd handle customers for various problems? (which seems fair enough).
2. some coding questions (my friend did this in matlab but they wanted him to do it in python).
3. some IQ questions
4. some questions about the platform (which my friend didn't have an idea about as he'd never used top hat before).
I think it's useful to know whether an interviewee who has driven into your place of business is serious enough to spend 30 mins learning your platform.
Which culminated in this blog post: https://news.ycombinator.com/item?id=3061860
Call me weird, but I prefer the assignments than the mindless discussions about balancing trees and Big-Oh notation.
A well designed take home assignment, meanwhile can be a good filter, telling you immediately if the candidate knows the basics and has the added benefit of showing you strengths and weaknesses in their practice.
The interviewing process itself was somewhat time-intensive for a Toronto company (it had a do-at-home assignment, which is fairly uncommon in TO), but other than that it was a fairly average experience.
Ultimately I turned down their offer, because their offer was low (and going from the who-is-hiring threads, it still is lower than market averages)
With that said, I got a chance to talk to some of the developers, and the work-life balance seemed reasonable (although not as good as, say, working at CGI)
Apart from the madness that is housing prices, dev wages vs cost of living aren't too bad here. Hopefully that housing bubble pops, and then Toronto will really be attractive to developers.
After that, I went to work remotely for a company in Boulder, CO, called Human Design.
Money-wise, the better opportunities I heard about in TO were mostly from a recruiting agency called JobSprings (usually in the 120k range, usually in the queen west area). It's exceedingly rare to find anything above 150k. Tech wise, yes, it's predominantly Angular 1 jobs.
I interviewed at Top Hat 3+ years ago and I remember their hiring process was sad because it was a FizzBuzz test under conditions that were setup for me to fail.
I wasn't allowed to use my own laptop, editor of choice, or language of choice to complete the test. They wouldn't tell me what conditions they wanted eg. do they want test code?
I had to do the test on their computer, in javascript, no internet.
They said I was slow. Well you should have let me use MacVim and I would shown how slow you are in TextMate.
They said I didn't write test code. They wouldn't tell me, and they wouldn't even look at mass bodies of work of production apps where I had tons of test code I written with CI.
Sorry to hear you had an awful experience like that. We definitely want to provide a better candidate experience than that.
As I mentioned before in this thread I can't speak for interviews that long ago, but these days we have a standard process: we want to see you in your element, so you're encouraged to use your own machine and whatever tools and languages you're best at. We also currently do a pairing-style mini-project where you're free to look things up - Google has become another essential tool for devs, so we want to avoid forcing people into unnatural ways of working that won't reflect their actual abilities in an interview.
The one time I reached out to them though, I called it off before we could move forward because I got a promotion, raise and change of role (all of which I was specifically looking for).
I don't know much about the culture - but my understanding is that they've got good compensation & a reasonable work life balance. (EDIT: wow, reading the other comments here, my understanding may have been WAY off)
Actually taking on the textbook publishing industry would be a really big deal IMO. I could imagine a few really interesting disruptions there. Tablet versions of all textbooks via a "netflix" type model?
Maybe like $250/year for access at the university level rather than $600 for that one totally esoteric 30 page title on the mating habits of the African fruit fly.
Students save over the cost of all books, and the edge-titles get brought up.
Maybe that's a bit too Pollyanna an idea. I'm sure there would be an amazing volume-market if you did it at the high-school level.
One digital subscription account, all textbooks. No defacing, no lugging heavy books, access anywhere, always up to date.
If pages and sections were PDF exportable with low-impact DRM it really could be revolutionary.
The teams are small, yet the software we deliver is well tested internally before being put out into production. The best part here is that employees are encouraged to use the Top Hat products themselves, which really helps better the overall applications.
As for mentorship, team leads and the execs are very accessible and guide you through how the processes at the company work. New employees are encouraged to share their opinions while doing development which is a big plus. I hope this cleared up some concerns you had!
I'm not sure what your basis of a bad reputation is, but, I've been working at TopHat for the past 10+ months as part of their engineering team and it's been my favourite internship thus far (I've had 2 previous internships in development). As far as I know, myself and one other UofT student are the first PEY's to have been hired, and our current opinions of the company are quite high.
To highlight some extraneous comments regarding mentorship, it should be known that the teams are sized to about 5-8 people, with a team lead & product manager facilitating each team. Bi-weekly one-on-one's are in place to catch up with your respective lead and talk about your experience thus far, goals for the future, and really providing a basis of mentorship and growth. Higher ups such as the VP's are always accessible throughout the day to chat; we're pretty open.
If you have further questions, feel free to comment below and I'll get back to you ASAP! ^^
Do U of T students like the software TopHat produces?
That whole "85% personality, 15% skill" saying really applies here.
I've seen great developers get frustrated that they have to talk to a junior HR rep for their first screen and say things that were way over her head, or just flat out rude. (Not saying you were, or intentionally were at any rate.)
HR / Recruiters really piss me off too... I was working at a company as a contractor, helping to build their in-house dev team and transition them away from using contractors. I sent them one of the best devs I knew, and a great guy who had worked on very similar tech stack to boot. He didn't even make it to round 2.
His version: Well, the HR screener was 15 minutes late calling me, then wasted another 10 minutes asking questions about the wrong role -- an accounting role instead of a dev role. About the 4th accounting question in, I realized what was wrong and asked her if she was reading off the right question list. We got if fixed up, but she seemed really embarrassed.
Her version: He wouldn't have been a good fit for our company culture.
Total shame, but what can you do? The screener gets all the power in that situation... we trust her because we hired her, but she's clearly in a position where if she makes a mistake and doesn't want to own up to it... she can just sweep it under the rug. She has a bad day... wants to take it out on a candidate, what are you going to do about it? Her knowledge of tech is 100% limited to what sounds like a good answer relative to other answers other candidates have given her.
Culture fit, and the human side is important... probably a safe bet in most situations that if you can't talk with the bubbly 22 year-old recent college grad, you probably will have communication issues with others too. All you can do is be kind, move on to round 2 and hope you eventually get to talk to someone in your specialty smart enough to know how to actually rate your talent. =P
It was very bad as far as whole process was concerned. I didn't mind though since they were in their infancy and I moved onto a different position anyway.
There really are not that many tech companies in Toronto (and that are hiring unless you have 5+ yrs of experience).
Either 1. you have very very early stage startups (that expect you to work for free till they get funded),
2. funded startups that have a short runaway and expect you to work like crazy till they get to the next round of funding (during an interview with a fintech startup - it was mentioned that they expected me to work for ~12+ hrs / day but I'd still get paid for only 8 hrs. But when they scaled up, I'd be "rewarded" for my hustle, grit and commitment".
3. Big companies (Google, Mozilla, etc.) who are looking for quite a lot of devs but seem to be insanely picky about hiring them.
To add to this, there seem to be a lot of devs than jobs (or that companies can go for long without hiring for those open roles).
Did the #2 type companies offer any equity at all?
the first ones offer anywhere between 30% (if you are a co-founder), 15% - 1% (if you are in the first 10 to get hired).
The 2nd type offer equity (generally less than 1%) and in all honesty it's pointless - chances are they'll fail before your 4 yr vesting period (and if you work for 12 hrs/day everyday you'll probably get burnt out even before you hit your year 4). And even if they don't fail, if you do get equity (and convert it to cash) divide it by 4 + salary / yr, you are basically making less than the avg salary for your position / exp in your area.
First off, very few very early stage startups expect you to work for free until you get funded. Exceptions being that you're a co-founder or an unpaid intern that never touches code.
Secondly, while the startups in Toronto are probably less well funded than the ones in the US, not all require you to work for 12+ hours a day while paying you for 8 hours. It looks really shady to set these expectations especially since we have clear laws around overtime pay in Canada (describing such a work situation to friends will raise eyebrows -- definitely not the standard practice, whatever industry you work at).
Lastly, I'd say that any place worth working at (big or small) will be insanely picky about who they hire. Current employer included.
All of the above are from personal first hand experience. Of course I haven't worked for every single tech company in Toronto but I have worked for several (mainly early stage startups).
Obviously this is not something I have a lot of statistically accurate data for but, me and my friends are recent graduates and collectively have applied to quite a lot of very early stage startups in Toronto and out of those, we all have experienced the bait and switch of unpaid work till funding at least 50% of the time.
> Secondly, while the startups in Toronto are probably less well funded than the ones in the US, not all require you to work for 12+ hours a day while paying you for 8 hours. It looks really shady to set these expectations especially since we have clear laws around overtime pay in Canada (describing such a work situation to friends will raise eyebrows -- definitely not the standard practice, whatever industry you work at).
I didn't say all startups are like what I've mentioned. The one I'm currently working at is awesome! That said, it's more often the case that startups use their short runaway as an excuse to make you work long hours (and just to be clear - the 12hr / day was not an estimation - I was literally asked my thoughts about it during an interview - that company is still recruiting on HN Who's hiring for more employees and a quick google search shows they have increased headcount to 35 people this year and is profitable).
> Lastly, I'd say that any place worth working at (big or small) will be insanely picky about who they hire. Current employer included.
I have 0 problems with employers being picky. I worked closely with the CEO of a previous startup and I totally understand that. What I don't understand is the point of claiming you need to hire a developer (with a start date of immediately) and then leaving the position open for months altogether, or having crappy working conditions.
BTW I've interviewed at Nulogy (if that's where you are currently working) - Since this is a throwaway I can't give too much details, While I was still disappointed for the reason I was rejected it was one of the good interviews I've had (interviewer was knowledgeable, I learnt about the company and product, the tech stack, the problems they were facing, what was expected of me, and just some personal chit-chat during the coffee walk).
Last year we were named one of Deloitte’s Top 50 Fastest Growing Canadian Companies and CIX’s Top 20 Most Innovative Canadian Companies. Check us out!