Hacker News new | past | comments | ask | show | jobs | submit login
For anyone who has been turned down by 38 companies (hackerrank.com)
247 points by rvivek on March 30, 2016 | hide | past | favorite | 294 comments



The current state of the hiring process in tech companies has really affected me. I'm, by nature, a very shy person who doesn't deal with rejection very well.

Because of this, I tend to apply at jobs where my hiring is a slam-dunk because it's so routine and easily within my skill-set.

It results in jobs that aren't particularly fulfilling but gives me plenty of time to work on technology I'm interested in my spare time for personal projects.

In essence, a day job of simple Linux administration may pay the bills, while in my spare time I'm working on large infrastructure automation, deep learning, developing new blockchain technologies, etc.

I don't know how sustainable this is. I have three children and a wife, and I'm getting tired of only being paid for work I can do while asleep just because I'm afraid of rejection.

Any suggestions on how to "toughen up"?


There is only one way to toughen up: Practice. Be it interviews or sports. Be it negotiations or cooking. Practice and practice perfectly.

1. Take mock interviews from experienced engineers

Go one topic at a time e.g. Recursion or Trees or DP or Multithreading etc. Before you walk into the interview, practice well. Do at least 20 problems on that topic, if not more.

2. Do practice interviews at companies you don't want to work for

Don't feel an imposter in doing this. Realize that companies also go thru several candidates before they pick one. They are normal people like you, they have a learning curve to fill the position, and so do you. Finding the right company, at the right stage of your life, is not a trivial thing to do; it's a project and needs to be managed like that.

Going thru various interviews hardens your skills of negotiation, your understanding of business models, and more importantly, gives you clarity about what your strengths and limitations are.

3. Practice the right mindset

Never go to interviews with a loaded agony of getting a job. Go simply with the intent of solving interesting problems with interesting people ("to add life to your character"). Nobody explains this better than Bryan Cranston (possibly one of the most successful TV actors of recent times): https://www.youtube.com/watch?v=v1WiCGq-PcY

I make these observations based on my experience running a successful bootcamp for interview prep (http://interviewkickstart.com) and also being an early engineer and a hiring manager (Director of engineering) at Box prior to that.

[Edit: specifically mentioned Bryan Cranston by name, based on the comment below]


> Nobody explains this better than the meth guy: https://www.youtube.com/watch?v=v1WiCGq-PcY

That clip just increased my already substantial respect for Bryan Cranston, though I feel as though calling him the "meth guy" does him a disservice. Yes, Breaking Bad brought him a great deal of exposure, but I think that even his role in Malcolm in the Middle showed how capable he is as an actor. The fact that he performed both roles excellently is also a testament to his skills.

He's also won a Tony, and was nominated for a few director awards. (https://en.wikipedia.org/wiki/List_of_awards_and_nominations...)


Thanks for posting this clip; it is surprisingly universal and applies to a lot of things outside of acting.


Wise words: "You are not going there to get a job, you are going there to present what you do... then walk away."

I think if more people took this attitude of employment being an arrangement of mutual benefit that both sides are engaged in, the world would be a better place.


I think this could be applied to many encounters; dating seems to be the most obvious.


So long as you don't use PowerPoint.


Ice always treated interviews as a way of getting to know a bit about the place I might work. I haven't had a whole heap but had always assumed that it was a two way street.


> I haven't had a whole heap but had always assumed that it was a two way street.

It absolutely is a two-way street, as you describe. When I go on interviews, I get into the mindset that I should interview them as much as they interview me. It's actually saved me from taking on a couple of bad roles.


This is very good advice. The only problem with it is - he will be spending enormous amount of time practicing, preparing for interviews, and end up learning stuff that he might never use in real life. Unless he gets a dream job, I don't know if that is a great use of his time.

The other option is to look for companies that put emphasis on past projects, open source contributions, take home problems etc and apply to those positions. At least this way, he can spend time making things he is interested in.


One would think so, obviously. Most people don't need to work with BSTs on a regular basis.

However, once you start practicing, a funny thing happens: assuming you're doing it the right way, with the right mindset, you start to enjoy doing those problems. Your intuition hardens and a certain level of system-design clarity sets in by seeing similar problems across topics.

In some ways, that's what I'm looking for as a hiring manager, by definition: do you enjoy a problem that is new to you, but still up your alley? Do you have an urge for efficiency? Can you express your thought process and work with me to build a solution? The problems asked in the current interview process are good enough to tease these things out.

Take home assignments and OSS contributions are also another credible method of interviewing, and has its own pros and cons. To see a good treatise on different ways of interviewing, see this: http://www.gayle.com/blog/2015/6/10/developer-interviews-are...


I actually found 'toughening up' the wrong mental strategy, but rather "not giving a damn".

You're in a position where you have a job. Anything you interview for you -don't need-. You may want, but you don't need. You also sound very comfortable in a specific role. That's a great place to start from, because if someone rejects you...what are they rejecting? How does it effect you? You know you're good, at least in certain areas. Either they don't need your knowledge in those areas and aren't convinced you'd be an asset in others (which is fair, and a reflection not on your abilities but your experiences), or their process is broken. Neither is a reflection of you.

I've gotten a lot more comfortable in interviews just recognizing that, that I have successes under my belt, I've already proved I can learn and adapt and get difficult things done. So if in an interview I don't get an offer...that speaks more of their process, or the minutiae of what they're looking for, than it does of my capabilities.

And what's funny is that that devil-may-care attitude, has made me both more willing to speak confidently about what I can do, -and- to more readily admit what I can't. I don't fumble and stutter when asked do I know about (a thing I don't know about), and give some half-truth, I just flat out say "I don't. What is it?" And that has led to better interviews, and more offers, than I ever got when I was a scared junior dev looking for work.


> I actually found 'toughening up' the wrong mental strategy, but rather "not giving a damn".

I believe this is called having a great BATNA. You always want to have a plan B, and preferably a plan C. That's why you should always be networking (and, if you are a company or hiring manager, always be recruiting: http://avc.com/2012/07/mba-mondays-guest-post-from-chad-dick... ).

I find that contracting is a great way to practice "not giving a damn" because you can cycle through 3-5 contracts (of various sizes) in the time that 1 w2 job would take. That means you get all kind of experience with different colleagues and processes and tech sets.

Also, the act of repeatedly putting yourself out there will thicken your skin and let you realize that sometimes it isn't about you, but rather is about the company/client.

That's to say nothing of the benefits of learning to run your own business and marketing and budgeting. (If that floats your boat.)


Amen with respect to cycling contracts. Landing a great job is essentially about reducing information asymmetry, and this gives a great means of doing so.


It also means you can move on from several different situations without having a series of short term jobs on your resume. Which still matters.


This works for me, and is generally how I've dealt with high pressure situations throughout my life. I just sort of go into "eh, don't give a fuck" mode, and try to joke around with people about how I don't give a fuck about the outcome (if comfort level with said people is appropriate, like fellow students). It's just a way that I calm myself so that my brain can effectively recall my practice / training to help me execute better at the critical moment.

Interviews are much like tests in school. The pressure is high, you only have a moment to recall the information and act correctly, you have very little leverage over the situation... and in both cases they are probably poor indicators of what is being measured :-)

Maybe the similarity to tests in schools is the origin of programming interviews came to be the way they are...


Exactly. Interviewing is a lot more comfortable if you do it from the security of having a job. If they don't want you, then no problem.

And more than that, the interview process is also to determine if you actually want to work for them. You can reject them, even if they want to hire you. Interviewing becomes a much more symmetrical affair. You have power too. You can afford to say no, and you can afford them to say no.


I think the "not giving a damn" statement belies that you do actually care.

Like someone saying "I don't care" implies... yes, you do care, otherwise you would not state such a thing.


Being a bit pedantic there aren't you? Sure, if I wasn't interested, I wouldn't be interviewing. But recognizing that the interview's outcome doesn't reflect who I am, nor does it mean 'my life is over and I'll never get a job I like', or any of the other anxieties common to those first few job hunts, means I am not so invested in -succeeding-, and far more invested in just scoping the company out, seeing if this would be a good fit, and accepting a "no" as in no way a reflection of my quality.

Obviously, "not giving a damn" is hyperbole; as I said, if I really didn't give a damn I'd not be interviewing in the first place. But it is the most accurate description of the attitude I find myself having when interviewing. "Toughening it out" was what I did as a college student and junior dev, trying to fight the impostor syndrome as I try to convince strangers I'm worth hiring, and trying to hold down the feelings of depression and self-loathing afterwards as I criticized every single thing I did that I thought was a mistake in the interview (even successful ones that in hindsight I realize I absolutely aced), and tried not to think about how I just blew my chance at a dream job (because every company that I talked with was a dream job, after all; someone who would actually -pay- me to write code and solve problems!)

I instead describe my current attitude as "not giving a damn" to demarcate it as very much different than that prior experience; my feelings now are "I am good, I know a lot, I learn fast, and I have a track record to prove it, and if you say no it means either you want someone with different experiences who is looking for something very different than what I am, or you've been interviewing for (and thus hiring for) the wrong thing; in either case I don't think I'd enjoy it here. So, while I hope this works out in the affirmative...I will view a 'no' from you as a positive as well, because it tells me more about you than it does about me. Regardless of your response, I am relieved to hear it, hence, I don't give a damn what it is".


Did you notice that this thread is about mental strategies?


Go do theatersport or "impro". It may sound scary, but when in a small group without spectators, you start easy, make small steps, and it helps you get out of your shell. One of the mottos is "to fail with pleasure". You will fail here, and they design games where everybody will fail. You will practise rejection here. Plus you can practise social status with status games.

I had stage fright. In several weeks I'll do my second public show, for a small audience. It can really turn your view of yourself around.

You can read books about it, but you have to do it, experience it. It's much less frightening when you do it then you think, because of the small steps. But you need a good teacher here, one that knows what he does and has done it for years. In general, it's really fun!


Instead of toughening up, I'd suggest two things:

* Try to get ahead in your day job. This doesn't necessarily mean making the big bucks. It means being someone who deserves the big bucks. To find better work and more money you'll probably have to leave. Maybe not, but probably.

* Find new jobs through word of mouth, networking, etc. In my experience, this does not equal a slam dunk hire, but it'll get you an interview and they will actually converse with you. They want to find out why you were recommended, and that's a whole different feeling that being "screened".

Potential sources of recommendations and job leads include former coworkers (and bosses!), people you meet at user groups, interest groups, etc.


Rejection is just a part of life.. I was really scared of rejection till one day I just gave in and told myself that, I'll never get anywhere playing the safe hand.

My advice is go on interviews you don't even care about in hopes to get rejected. Some places might tell you to leave like half way through an interview which is awkward, but most will shoot you an email or you just never hear from them.

Once you get a few rejections under your belt, you learn its not a big deal. I've know some incredibly smart people get rejected. Most times you get rejected because its not a culture fit so its for the better.


> My advice is go on interviews you don't even care about in hopes to get rejected.

This was an immense help when I recently decided to switch companies. I applied to places I didn't really want to work at so that I could either:

1. Get rejected and get used to hearing/reading those words while not taking it personally.

2. Work on my negotiation skills if I actually got an offer.

Either way it was a win-win for me in terms of what I was really trying to achieve.

You may come across a dream job posting one day and if you can block out the worry of rejection you'll have a higher chance of success.


I've recommended this to everyone I've mentored, even when I was their boss. Interviewing is a skill that can be honed. Some people are naturally better than others, but most people can at least get comfortable.

Up until recently I would take two or three interviews a year at minimum just to see what people were asking about, how they asked, and just to stay comfortable with the process.

Worst case scenario, they say no, and you might get a hint as to why. So now you have an idea of something you can improve on.

Best case scenario you wind up interested in a new company, get a raise, and learn something new.

Either way, it's time you're spending to improve your career- and it is likely more monetarily valuable than the same amount of time you would have spent writing code.


>Any suggestions on how to "toughen up"?

Keep doing the admin work to pay the bills. Switch off when you leave.

Work towards turning the other work into a viable consultancy/small business.

Stop thinking like an employee.

If you're running your own micro-startup - and it sounds like something you're perfectly capable of making this work - you won't need to worry about getting rejected.

In fact you'll probably get recruiters reaching out to you.

This may not result in a job, but it's a lot easier not to care what happens in an interview if you have a secure income stream as well as an impressive resume.


Apply for jobs you've no intention of taking if offered. Use them as practice. Use them to toughen up. Knowing in advance that it doesn't matter, and that you'll never see or hear from the people involved ever again, and that the final outcome - that nothing will change and you're risking nothing - might be liberating enough that you can do it.


> Apply for jobs you've no intention of taking if offered. Use them as practice.

This runs afoul of the same mental-block when it comes to worrying about your self-identity. It's trading the possibility of "Oh man, what if they think I'm incompetent?" for the self-certainty of "Shit, I'm a horrible person who lied to them and deliberately wasted their time."

Anybody already self-assured enough to "be the jerk" probably isn't that worried about "being rejected".


This is actually kind of a bad thing to do, since you're intentionally wasting other people's time.


Companies interview multiple candidates looking for the best one, and they'll solicit applications from candidates that will never make it past a phone screen.

Why wouldn't you do the same with companies?


Companies don't go into the interview saying "we'll never hire this person, we're just talking to them for the practice".

It's fine to interview at multiple companies that you might consider taking an offer from, but interviewing at a place you know you'll say no to strikes me as, yes, wasting their time (and money, as we usually have a few people interviewing one candidate at the same time).


I believe companies certainly do interview people they don't intend to hire, to get a feel for things like what the field is like, or what the expected salary for prospects with certain skills are. I've heard there are situations where they have a person in mind for a position, but because of corporate policies they're required to post the job and interview people.


I've seen these sorts of shenanigans happen at a public university, where they already know whom they want to hire, and even create a new position specifically for them, but are required to post the job opening to their public-facing jobs website, and are forced to interview at least X number of the people whom apply.


It's never "I will never take the job". I am sure if offered 2x current salary (or 3x if work is especially unpleasant), most people will jump.


... while getting better at interviewing and saving your own time, money and career in the process.

No reason to feel bad about it especially if it is a big corp. These days employers throw careers under the bus at the whim of asshole mba's. And, no, employer's won't agree to "informational interviews" any more.

In any case no one has to know except the interviewee.


Lot of advice below on how to toughen up for interviews, but I'm going to give a contrarian view: you can't toughen up if it's not in you already.

Tech interviews are an exhausting, often humiliating experience. Some companies claim to do it better (e.g., see Asana's post a few days ago) and more humanely, but by and large the process is designed to break the candidate: to see the limits of their skills and aptitudes. Excellent in theory for the company, but very hard on the candidate.

Even if you do mostly-great in an interview, you'll probably not quite finish the programming assignment, and feel like a dunce for it (and you'll know the answer on your walk back to your car). If you don't get an offer, it will serve as confirmation of your ineptitude and you'll kick yourself for it.

It's super tough and I have very good friends --and easily world-class 1% engineers-- who have crumbled during the process.

My advice: you seem to know yourself pretty well. That's so valuable. Play to your own strengths and don't bother trying to toughen up for interviews.

Oh, advice #2: get into an awesome job via a friend, if you can, and maybe your friend can make sure they don't haze you too hard.

Good luck!


I don't think tech company interviews are purposefully setup to be brutal gauntlets but I think what in reality occurs is a team needs to hire quickly, members tap into past experiences and then build a process. This process may be wildly inconsistent or draw from past negative experiences. Before you know it you've built a brutal hiring process. I think the real problem is developers lack hiring and interview training.


I think you have hit the nail on the head, my interview experience at a single company (currently employed, didn't interview anywhere else) had a very high variance in terms of questions/approaches so I can see this playing a significant part in determination of appropriateness of a potential New Hire.

Personal experience is important in terms of rapidly evaluating a candidate! If a team is composed of 10 people and you interview with each and each brings something a little different to the table, that seems OK to me. It gives a candidate exposure to the people they would be working with, kind of like dating.


Have someone else apply for you. Your wife probably.

You find the job and tell her you are too nervous to apply, let her know it's OK to apply for you.

Sometime seceding that bit of control is enough to get over the problem - especially when you have self awareness of it.

Once she applies you will probably feel an urge to take over and continue the conversation with the employer - so do that, and take it to an interview. (Or have her do it for you, while you hover in the background looking worried and telling her what to say :)

It's kind of a way of forcing/tricking yourself.

(Hopefully she doesn't say something like "man up and do it", ask her not to if you think she might, tell her you need her to help you with this.)


How do I apply for a wife? I'm pretty nervous and I get rejected a lot.

Honestly getting a job is way easier.


What are you more afraid of? Rejection from a company you never have to talk to again OR your family being unhappy as a result of you 1) being unhappy with your job 2) feeling like you aren't doing as much as you can or should.

This might just be something you have to confront. But I think constantly confronting your fears is healthy, even if it's difficult and stressful.

It sounds like you're genuinely enthusiastic about engineering and computer science. I think talking about your side projects (deep learning, blockchain, etc) will show this very effectively. Actually, having side projects to talk about is sort of like a secret weapon at job interviews. You'll find if you learn how to talk about these your interviews will go really well, so long as you can do a somewhat above average job on the technical questions (which can happen with practice and luck).

That being said, I can't give much help on being shy as I've never really dealt with that. I did used to be kind of.... not the best with social situations, and I found that by being chatty and going out of your way to meet people randomly, you end up getting good at it pretty quickly. Of course I sucked at this at first, but I had a friend who was extremely chatty and whenever we hanged out in public he would always be talking to random people. By joining in I sorta got the hang of it, and that helped a lot.

Also never be afraid of being silly. Making mistakes can make people feel more comfortable around you because they stop worrying about keeping up their own image of being a normal human being (what does normal even mean?). That works more for meeting people and MUCH LESS in job interviews, but meeting people will make you less shy, which in turn can help with interviews.

Don't fall into the trap of believing you can't change yourself. Simply by acknowledging what you'd like to change about yourself, you've already begun the first step. I think you already know you need to do something. Hopefully this is the impetus. I've seen friends totally change personalities and go from being shy to confident, or silly to mature. You can overcome your fear of rejection. Just get rejected a lot so that it becomes a trivial thing you can laugh at.


Do you like working on those things in your spare time? The flip side of what you seek is that with a more challenging day job, you may not have as much energy or desire to tackle those projects in your spare time.


This is essentially an anxiety issue. It's definitely possible to hack anxiety - it might be a good idea to see a psychologist/psychiatrist to help figure out how, cause that's essentially what they do.

And if CBT doesn't work there's always beta-blockers, heh.


It is not an anxiety issue. Interviews are structured ridiculously, most being the equivalent of a dick wagging contest or a beauty pageant. Companies are falling over themselves not to hire the best talent, but just the youngest people who can recite the algorithm to find a subtree in a tree.


Yes. So last time I was looking for a job, I became good at reciting algorithms, looking like a "team player", whatever the fuck they wanted. I didn't like it, I felt some degree of trepidation over my interviews, but I didn't have crippling anxiety or anything.

Jumping through arbitrary hoops is completely normal for most professions. The main issue here is being so anxious that one finds it impossible to work up the courage to interview in the first place.


I suggest you build up your network of contacts at your current job. That means get to know others, help the out, make sure they know your career interests, etc. When some of those move to a new company, they will think of you when opportunities open up. Usually hires through internal referral get special treatment at many companies if the referring individual feels strongly. They can allay any concerns the the interviewers have.


Look at interviews as an interesting opportunity to learn. Try to make sure that the company who is interviewing with you respects that. If it's going to be all one sided / grind you in front of a white board, I'd skip it. Make sure they let you ask questions about their stack, their development methodology, etc. That way interviews are always a profitable experience.


> in my spare time I'm working on large infrastructure automation, deep learning, developing new blockchain technologies, etc

Sounds interesting! Did you try to give presentations on these things? Start with small conferences/hackathons/user groups. Use YouTube if there is nothing local available.

Also, theater worked really well for me as well.


I assume you're describing some variation of anxiety. Social anxiety is helped tremendously by exposure. Go do stuff in social settings you're uncomfortable with (not anything dangerous or against your morals obviously). It will gradually get better. More interviewing practice will also make it better.


Oh man, oh man. You asked a doozy of a question. 'Toughness' is a heck of an ill defined term in Western Society, but still hearkens to something we all innately feel. I'll not bore you with a long essay, but give you some resources to start on the journey, should you choose to proceed with earnest.

My biggest recommendation is, of course, google: https://www.google.com/search?q=how+to+toughen+up&oq=how+to+...

For a better site, I'd suggest The Art of Manliness. Brett McKay likely has a degree or 2 in Men's Studies at this point on his site. I like him because he gives good advice, tell you when something is not going to be easy to think about, and he lives what he talks and tracks changes to his advice, sometimes calling out old posts of his as wrong. Here are some links on toughness, but the whole site is great:

http://www.artofmanliness.com/2015/10/26/the-sioux-guide-to-...

http://www.artofmanliness.com/2015/05/07/men-and-scars/

http://www.artofmanliness.com/2014/07/17/keep-your-head-4-ex...

http://www.artofmanliness.com/2013/10/03/you-may-be-strong-b...

http://www.artofmanliness.com/2013/11/04/dig-deep-youre-stro...

http://www.artofmanliness.com/2015/03/12/podcast-105-resilie...

If you's like some reading on toughness and the more historical view on it, no better book is there out there than Dr Carlin Barton's 'Roman Honor: The Fire in the Bones'. Her book is really a masterpiece in manliness, toughness, and much more. Available here: http://www.amazon.com/Roman-Honor-The-Fire-Bones/dp/05202252...

Finally, no real discussion and initial voyage into toughness would be possible without mentioning the patron saint of toughness and hardihood, Teddy Roosevelt. The Edmund Morris Trilogy on our manly lord is the best biography I know of, though I think the 1st one is the best: http://www.amazon.com/Edmund-Morriss-Theodore-Roosevelt-Tril... (bonus points for the Churchill series too: http://www.amazon.com/Last-Lion-Box-Set-Churchill/dp/0316227...)

Hope it helps!


Interviewing is a number game. Treat it as one and it will make your live easier.


There is a game for rejection that's definitely worth checking out: https://news.ycombinator.com/item?id=1754790


I went out of my comfort zone recently, it helps and you won't end up working at cost-centers/body shops aka ad-agencies and "consultant firms"


One very important thing strikes me about this. Getting 38 job interviews is very much a sign of the times. In 2002 I was a highly skilled senior linux/aix/hp-ux/Solaris admin and PHP programmer and I got laid off. I submitted my resume more than 1000+ times in the first year and ZERO interviews.

I hate to sound alarmist but, I fear many younger tech people may not realize how lucky they are currently. If the economy turns south you are not going to get 38 job interviews unless you seriously have some needed skills.

Don't be like this guy and accept you are bad at interviews thinking there is plenty of opportunity. Don't blame the white board if every job in your field expects you to be able to white board. If you plan to survive during the next downturn or bubble burst you better be someone companies really want to hire. You may be lucky to land one job interview and it will be hard to stay motivated as months start to go by.


>Getting 38 job interviews is very much a sign of the times.

I've noticed that many employers have copied google and have stated to interview with as many people as possible. Lots of them take pride in their acceptance ratio, some even advertising that on their careers page. Def a sign of times but might not in a way that you are suggesting.

Getting an interview is not all that hard these days, you can get an interview with google/facebook ect pretty easily.


Many companies are swimming in cash and can afford to have 5 high paid Engineers sitting in interviews for hours each week. When stock prices go down that luxury fades. We saw this in the late 90s.

Yep getting an interview isn't hard at all these days. The economy is great and jobs are dime a dozen. My point exactly, it's 1997-1998 all over again. I've practically stopped using my phone and had to get a new email address. The recruiters have literally been driving me insane.


> and can afford to have 5 high paid Engineers sitting in interviews for hours each week

Plus, companies expect you to work more hours if interviews have delayed a must have feature.


> Getting an interview is not all that hard these days, you can get an interview with google/facebook ect pretty easily.

Maybe... I got contacted by 2 google recruiters in 2 separate instances. I replied to them, but I never heard back.

I would've probably failed at the whiteboard, but I never even got a chance to attempt the interview.


Google -scheduled an interview -forgot it -scheduled another -forgot that one, too -after a few annoyed emails, they scheduled another. -they remembered the next one, but the guy seemed stupidly disinterested. -never heard back.

What the fuck.


Yeah, that just happened to me this week. I'm sitting here wondering what I said wrong in my reply email.

Was I not enthusiastic enough? What was it?


You should get a reply; it is possible the recruiter is no longer working there, or something else. Or maybe they're just being slow.

Some more info: https://www.quora.com/Why-does-Google-recruiting-take-as-lon...

Also down with kt, long live cj. :(


lol despite my username, I'm more of an MVP fan. <3 Taeja, HerO, Life!


the trend i've seen lately is that internal recruiters are now as flaky as the typical 3rd-party recruiter. everyone is just spraying and praying. (though, personally, my experience with google recruiters has always been amazingly positive.)


For my current job I interviewed with no less than 12 people, some of them twice. This was face-to-face interviews over two visits, and does not include the initial phone screen by the recruiter or the company itself. It's awful, and as far as I know I'm the only one who went through that.


While there will definitely be downturns and upswings in the future I doubt we see the kind of tech wasteland that we saw from 2002-2004. Software/the internet/computers are just too involved in today's society and we can't even keep up with the demand right now.

The only way I see software engineering (or at least quality SE) not being a scarce resource in the near future is if we dramatically rehaul our education system within the next 10 years, dramatically increase programmer efficiency, and potentially invent an AI to do basic CRUD style work. Even then though, we're going to need legions of programmers to maintain the crap we're building today, and most of that will require highly specialized and rare knowledge (I, for one, can't wait until node.js programmers are the new FORTRAN maintainers).

Honestly, in the future the only true full time job might be being a programmer. This is probably not a good thing for people like us, as everyone else will be free to pursue their interests while we still bang our heads at syntax errors.


Eh, I can't pay for interviews right now. Maybe I'm just applying to the wrong jobs, but I feel like you have to be a part-time marketer in this industry right now to get interviews for jobs wherein you do not match the company's laundry list.


I am in Brazil.

I graduated in 2009, never had a legal job (according to Brazillian laws).

Also I too sent thousands of resumes since then, and since 2009 I got like 6 or 7 interviews in total (some that landed me a contract instead of a job...)


And, it's not like the job market is that rosy now either. Sure, every tech company on earth is interviewing, but few of them are actually hiring. Getting 38 job interviews these days with companies that are not serious about hiring is fairly easy, but pointless. Companies have a lot of cash and it's fairly cheap to interview people, so they all seem to be kind of playing the market and fishing for the bargains.


Depends on the company, I guess. I interviewed with Fidelity Investments Dublin in June 2015 for a .NET programmer contract (they are mostly Java but also have some VB.NET code). They told me that the Dublin office had 300 programmers at that time but they were looking to reach 1000 by the end of the year.

The job market in Ireland is nuts :)


Did you send it out 1000+ times without making any changes?


I didn't really make any changes and I'm still using the same resume 14 years later. At the time it had 10 years of job history. Obviously now it has 24 years but, my experience level is the same and I'm still basically working with the same technologies.

I haven't looked for a job in one year and my resume/profile is posted no where online. I get about 30-40 emails per week and 5-10 phone calls because I put out the resume last March when I was looking. This was the same result with the same resume in 1997-1998. Post 2002 I never got a call and rarely an email back acknowledging someone received it. Also recruiters found me jobs in 4-5 days in 1998. Zero jobs from 2002-2004 (2008 was also pretty miserable). Again today recruiters can find me a job in under a week.


This is highly location-dependent. I get a fraction of your volume even when posting mine on careers sites and constantly tweaking my LinkedIn profile. Of course, I'm in Dallas and wee seem to be invisible to most of the tech world.


Just wanted to say - cool handle! World War 1 history fan?


Wrong von Moltke. General military history fan, mostly 19th and 20th centuries.


Ah the Franco-Prussian war then. Nice


So I've been on the flip side of this. I've worked at a company (multiple) which had no F-ing clue how to hire. They'd constantly hire terrible people who couldn't do the most basic things.

I think one of the most important aspects of hiring is getting potential candidates in front of the team and letting them talk to the team, to see how they handle questions from other developers (and yes there is always that guy who tries to make the candidate look dumb for some reason).

The most telling question I typically ask when interviewing is what have you worked on recently, why is it cool, and how have you added to the project. This gives the candidate a great opportunity to dive into their own experience. This way if they didn't answer my questions well it will give me some idea of their background. Oh hey this guy didn't know basic Javascript stuff off the top of his head because he's been working on the back end for 3 years. That's cool.

I'd personally take someone who can talk to me about practical design decisions they've made on a project rather than knowing how to solve basic algorithms. If you graduated 8 years ago and you STILL know exactly how to implement a Binary Search Tree without needing a 10 min refresher then you are a better man than I am. I forgot that about 3 years ago.

I don't mind that we expect developers to study for a tech screen but how much does that really tell us about them? They can study and know the basics, but have the ever worked on a large scale project where you have to make something work now vs, having time to do a perfect implementation? Where is their ability to tell their manager no, or their ability to weight COTS vs Custom Build?

Sorry this touched a nerve, I just had a bad interview with a company. The tech screen was outside my IDE, couldn't copy paste (which sucks when you want to move a line or do some refactoring) and it was on topics I haven't looked at in 4 years. Luckily I'd spent 15+ hours studying so one of the questions was a gimme.


Still my favourite interview process was a small coding assignment and presenting the resulting code in front of the devs, who got to ask questions about it and then vote in private on whether to hire.

Everybody got the same assignment, everybody solves it in a different way, and everybody makes mistakes[0], but how they handle that and explain it tells a lot about how they are as a programmer.

[0] Except for one who was insanely thorough and still apologized for really minor imperfections in his code. He got the most enthusiastic votes ever.


So, how did you get to where you are today?

I’ve always been passionate about coding, starting from my early days at Olympiad teams in high school and ACM teams in college.

Anyone who's made it onto an Olympiad team[1] of any significant geographical scale, in any category, shouldn't have to deal with this whiteboard nonsense. Maybe a few lightweight-to-medium rounds to verify that they are what they say they are. But that's about it.

[1] We don't know if that's the case with Alibek; the article didn't drill down into that aspect of his background. I'm just talking to the fact that generally, there are plenty of easy ways -- albeit somewhat subjective, and in any case not uniformly applicable to all candidates -- to be at least 87% sure that the candidate isn't a a self-deluded poser, or outright liar about their coding skills (which seems to be the default stance many interview teams take).

And the due diligence one should do to remove that 13% of uncertainty can be made far less time-consuming and grueling than it generally is. Really, if you know how to read the signals, you can much more -- and much more easily, for all concerned -- about someone's coding skills by giving them a single medium-hard, but short-and-sweet exercise... than rounds and rounds (and more rounds) of progressively harder ones, as seems to be the current craze.

EDIT: Overall this is a very heartwarming piece; if a company like Booking -- known for having had several exceptionally talented programers on its staff over the years -- can not only take on someone like Alibek, but apparently consider him to be something of a find -- then that's a pretty damning indictment of the filtering processes used by the 38 of 39 companies that rejected him.


If only that were true. I'm a U.S. national event champion in Div. C Science Olympiad (Road Scholar), and I not only have to deal with whiteboard nonsense all the time, but also, the spouse never really believes that I know how to get anywhere from anywhere else. (Sure, argue with Siri/Google, rather than allowing that I might possibly know which direction north is.)

Credentials are only as good as the trust other people put in them. And I'd guess that a good portion of interviewers are completely unaware that non-athletic Olympiad competitions exist.

And anecdotally, it seems like tech interviewers wouldn't believe you could code your way out of a paper bag even if you walked into the interview over rose petals thrown on the floor by Kernighan and the ghost of Ritchie. I've had plenty of them remark "you are the only candidate that has answered that question correctly" and then never speak to me again.

It really makes me wonder what the point of the technical portion of the interview really is. I have had only one interview where the interviewer actually cut short a technical screen because "clearly, you know your stuff". But no offer there, either.


They're not looking for good people, they're looking for cheap people. 1 good person will cost as much or more than 5 bad ones and somehow it got into managements head that 5 'B' (or even 'C') players is better than one 'A' player for the same money.

Which of course isn't true but good luck convincing people otherwise. (Source: regular clean up jobs after all the money has been spent and the company is on the skids and I get called in at a very large multiple of what an 'A' player would have cost to clean up the mess. I don't mind, it keeps me employed and brings home the bacon but it certainly does not seem to be the most efficient way to run an IT department...)


Ah, this brings back memories. I've had two interviews (many years ago) where I was told "you are overqualified for this job, you're going to be here three months and leave". I was hurting for money at the time so that wasn't great to hear.

Unfortunately, the only solution I found for this is "charge more", which seems to be psychologically difficult for programmers, with all of patio11's efforts :)


I think you got your second sentence a little twisted around. I've never seen an "A" player command a 5x multiple on a median or "B" player.

I think "A" players are the best bargain in the software world...


> I think "A" players are the best bargain in the world...

They are, but try explaining to your average PHB who doesn't even begin to understand the complexities of the 'simple' piece of software they intend to write that Charles here can do the job in 3 months and will cost 50K and that the five guys over there in the corner will take the job for 30K and will take a month longer (or so they think). Then, after 30K becomes 90K and the company is slowly sliding downhill that original 3 months and 50K estimate starts to look pretty good, but then the sunk cost fallacy kicks in and for an additional 10K (over the 90K) this time they'll get it right. And then finally the time will be up, the money will be gone and they'll have to shop for someone who will take on the task to fix it on a contingency basis in the next month or so.

This plays out over and over again for some strange reason.

So yes, A players are a bargain, but only after the money to pay for them has been pissed out the window.


Two issues:

1) The market has imperfect information. The expensive developer could be great or terrible, but the same is true for the inexpensive developer. Even if there is theoretically some way to tell the difference, most employers don't have the skills to do so.

2) Bad management is at least as likely to kill a project than bad developers, so even a developer who is 10x in theory will on average deliver much less than 10x in practice.


(1) References

(2) Very true.


I did not do Olympiads, but I did score highly in math modeling competitions and won a competitive PhD fellowship.

I have had the exact same experience. I will get comments like, "That's the best submission we've seen for that take-home test" followed by literally no response of any kind after that. I've had places say, "you are absolutely perfect for our needs on Team X and you will help us meet our deadlines by the end of the year" and then make a job offer with a salary less than 80% of my current salary, worse equity, and worse benefits.

Companies sometimes want on-paper credential, but they almost never care about actual productivity or talent.


> I've had plenty of them remark "you are the only candidate that has answered that question correctly" and then never speak to me again.

Stop right there :-)

I think that's where you need to do some deep introspection.

There's A LOT more to a job than technical aptitude. It appears that you're excelling in one aspect of the evaluation but failing in another. There's a reason WHY they're not following up. Find out what it is.

Consider doing mock interviews with seasoned folks that you trust who are willing to give you honest feedback. You might discover a lot and improve your interview game.


I'm pretty sure that if a company cuts off all contact after an interview, there is at least one problem on their end that I cannot fix, no matter how hard I try.

Believe me, I have tried to find out why they vanished from the face of my planet. But there's only so much effort I can put into throwing politeness and courtesy into the void of unimaginable rudeness.

You have to do mock interviews to get real feedback. Real interviewers are so absolutely terrified of telling you even one thing that might help with your next interview that I have never heard anything, good or bad, about myself in the wake of a real interview.

This is not an occasional problem. This is epidemic in every city I have tried looking for full time employment, to the point where I am actually shocked--shocked--if someone follows up with me after an interview when they do not want to extend an offer.

The only reason I can think of for this is that someone out there is actively counseling companies and HR managers to conduct their interviews in this manner. Perhaps it is to cut costs. Perhaps it is to minimize liability exposure to workplace discrimination laws. Perhaps I am on some sort of blacklist. Maybe something on my credit report is bad. There is literally no way for me to find out, because I am already blackholed by the time I might get a chance to ask, and I have no expectation that they would answer honestly if they would even answer at all.


Yes, a serious problem but not insurmountable. It is something that you can at least address with yourself if you understand what it is.

It is true that you can't expect actionable feedback in a real job interview. Mock interviews when done with the right person really help. Of course it means that you have to be open to criticism and handle it with grace. Some folks have reported success with a career coach for this stuff, but that will cost you.

There's also another way to get some feedback. If you develop some rapport with a 3rd party recruiter who sets up interviews with their client, you _might_ be able to get debrief on how it went and what your strengths/weaknesses were.


Good advice. I know I've turned down candidates that aced the technical questions but were so opinionated that it seemed unlikely they'd able to work as part of the team.


Maybe they're not all that opinionated in real life. They just get nervous in interviews, and unconsciously feel the need to show their individuals in ways that they otherwise (under less confrontational circumstances) do not.


It appears that you're excelling in one aspect of the evaluation but failing in another. There's a reason WHY they're not following up.

If he failed some other part of their interprocess -- that's fine, they can send a polite and professional rejection letter. Even a soulless form letter will do.

But to not follow up in any way with the candidate, after that? Unless the candidate vomits in the interviewer's lap, or something similar -- that's just pure rudeness, on the company's part.


I'm pretty sure the parent poster was talking about things like the IOI, IMO, etc., which are ridiculously difficult and prestigious and are competitions that occur on an international scale. Each nation only sends a handful of competitors. Not the "Division C Science Olympiad," which is US high-school based.


Well, doing a high school olympiad didn't get me into the university I wanted, so why would a university-level olympiad get anyone into the job they want?

It doesn't work as a credential unless it actually produces results.


Uh.... the IOI/IMO/etc. are for high schoolers. Doing well on the IOI (bronze or higher medal) will get you into any university you want. Doing well on the IOI is something that you'd also put on your app if you were applying to a PhD in mathematics.


Ah. I see what the problem is. The IOI started in 1989. The US first participated in the IOI in 1992, and has sent a total of 65 contestants. The first opportunity I might have had to be selected would have been 1993. My AP Computer Science teacher was the baseball coach, who presumably wasn't looking to sponsor any other extracurricular activities.

I had therefore never heard of it before this thread, despite it being around for 27 years now.

At the time I was in high school, US Science Olympiad, Indiana Academic Super Bowl, and the Rose-Hulman Math Competition were about the only games in town. And it was a big school. We might have had a US Chemistry Olympiad team if the chemistry teacher wasn't a few moles short of a balanced reaction, if you know what I mean. The biology and physics teachers were the Science Olympiad sponsors.

I'd think that even just being on the IOI team would be enough to get you accepted anywhere, given that you would have to be one of the top 4 students in the US for that year (by the best screening process that several university professors can manage).


Look basically none of the top tech schools or Ivies blink an eye at Science Olympiad especially in comparison to IMO or IOI or IPhO - besides the actual difficulty of the events you have to consider the relative sizes of the pool they are drawing from as well.


That's true. I got rejected from at least one top tech school for not being great enough on paper, despite all the medals from my high school non-athletic competitive extracurricular activites clinking on my chest. If I ever become even mildly successful, I eagerly await the opportunity to throw that back in their faces.

But for now, and the foreseeable future, it would appear that their decision has been validated. Although I'm not entirely certain whether that is because I am not actually good enough as a person to claw my way into the upper middle class on my own merits, or because my accumulated credentials are not prestigious enough for a gatekeeper to lower one of the ladders low enough for me to jump for it.

Like it or not, there may be people out there blackholing my resume just because it doesn't have the right university name on it, or because the year I graduated is in the wrong millennium, or because it doesn't have the right company names on it.

There's nothing that any of us can do about it individually. Stopping that kind of useless credentialism by employers is squarely in the domain of a cartel enforcer--union, professional association, or government--and even then it might not stick.


Just because you are smart enough to compete in an Olympiad doesn't mean you can function practically on a software engineering team. Whiteboard coding helps the interviewer see how you think and function as well as "can you solve this problem"; though I agree that it's not necessarily the best way to evaluate those capabilities, it's the best tool some companies have.


I don't really see that. I think whiteboard coding is one of many ways a team could function and that how a candidate performs on it is not generalizable. For instance, I have never written code, pseudo or otherwise, on a whiteboard outside of an interview in over eight years of writing code full-time. Hell, I used a whiteboard more in my four years as an EE and two years as a SysE than I have as a SysE/SwE.


It depends how you evaluate the exercise -- for example, don't mark the candidate on correct code and syntax, but reasoning ability, communication, and problem solving. Whiteboard code interviews also have the flaw that the type of problem they tend to cover is not one you might run into in daily coding, so the way the candidate thinks and communicates is seen through a very particular lens - but my point is that given an Olympiad-level candidate who can clearly solve those kinds of problems, I think there is still value to be had from watching them solve them.

I prefer whiteboarding systems design/architectural concepts, which is definitely something I do in the course of my regular work.


Whiteboard performance (positive/negative) doesn't correlate all that well with practical performance on engineering teams, either.


Oh, I can believe that. But the way said performance is measured -- both types -- is extremely varied. I'd summarize my viewpoint as "whiteboard interviews tell you something about how the candidate thinks and communicates, which you can use to jump into deeper explorations". Just because you know someone is smart enough to solve a problem doesn't mean it's not valuable to see how they do it.


If you were on your country's IOI team, you shouldn't be complaining about whiteboard problems. I think the major flaw of interviews is that if you did competitive programming ever, they're super easy. If you did Olympiad training and are still bad at whiteboard/algorithms, I think that's actually a reasonable signal.


Spot on! Every good competition coder I've met loves the whiteboard part of the interview and would happily crack away at problems for hours.


If you think the only good coders are competitions coders... then put that in your posted job requirements:

"Must l-o-v-e solving hyperidealized problems with clearcut answers, under gratuitous time pressure, while being watched with others (who already know the answer). For hours on end. Because that's what we do all day here. Serial olympiadists, hackerrank aficciandos, and other competition coders only need apply."

It's really quite simple to do, and will (by drastically narrowing your candidate pool) make your filtering process much easier, I'm sure.


I was responding to what the OP said about how he has lots of olympiad experience but didn't like demonstrating coding in interviews, which sounds bogus to me.

I'll be honest, I did rate coding interviews as very important, but I changed my mind after working with some really great people who do really badly at them.


From my reading of the blogpost, I don't see any reason to infer that he "didn't like demonstrating coding in interviews", per se.

He did suggest that some of the problems one gets asked to solve are gratuitously hard, which correlates with my own experience. He also fairly acknowledged that he was getting a lot of rejection for other, e.g. cultural reasons.

So it would seem that it's getting rejected, not "demonstrating coding in interviews" that he doesn't like.


I see the whiteboard coding test as an attitude-test. If you have too much attitude to sit down and write some code for an hour, then you aren't someone I want in my company. It shouldn't be hard if you're skilled. Sorry to be that way, but that's the way I (and we) see it.


Do employees at your company write all their code on whiteboards, without access to documentation, the internet and etc. And then when they have perfected the code they transfer it to a computer? If not, then you are not really interviewing for the right skills are you?


you've just failed my attitude test because you started talking about attitude :) The reason for that is that chalking something up to attitude as a first or major explanation usually is just mental cheating on your part - in the particular case of whiteboarding issues there may be a lot of reasons for different people other than attitude, i'd venture to guess that attitude is never a reason (until of course it is a director/VP candidate and one of my friends suggests the candidate to write a sort, any sort ... even here i think the first was [lack of] such ability and the attitude was only masking it :)


So, if they aren't willing to go through whatever random whiteboard bullshit you decide is due, then they can't join your company? Sounds like you're doing them a favor, not the other way around...


Probably one of the most insensitive posts I've ever seen written on here. There are many people who have crippling anxiety and social phobias, and your post chalks that up to them having an "attitude".


Not to be harsh or anything, but this kind of proves the point. Crippling anxiety and social phobia are not things I would want in an employee, all else equal, because they will need to be able to communicate in meetings and present findings/work to different teams / executives.

Reply: baseline social comfort is not a generic personality type.


Crippling anxiety and social phobia are not things I would want in an employee, all else equal,

It's not that their anxiety is crippling; it's that for various reasons, the hiring process is typically conducted in a way that is at best often careless and inconsiderate to the candidate -- and quite often needlessly stressful and confrontational.

In other words, the people who sometimes get tripped by such processes aren't demonstrating "crippling anxiety"; they're demonstrating perfectly normal, human traits.


Isn't that your job as a manager, though? To balance the various personality types on your team?

Seems like you just want one generic personality type on your team to make your life easier.


That's not how anxiety works. You are crippled while interacting with strangers, not with teammates you've spent 8 hours per day warming up to.

You should really give anxiety sufferers a shot. There are some real gems there which you are dismissing out of hand.


Yes, you should give them a shot, if they are exceptionally talented. That's why I said all else equal. But they will need to interact with people from other teams they've never seen before. They will need to interact with executives they've never seen before. They may need to interact with new hires, they may even need to interact with outside contractors.


That cuts both ways, hombre. If you're not willing to think about the serious problems with conducting interviews that way, I don't wanna work with you either.

Plus you literally just came out and admitted that it's not actually about measuring technical skill, it's some run-you-through-the-gauntlet "attitude" bullshit. Gimme a break.


This kind of proves his point. All else equal, someone who communicates like this ("hombre", "gimme a break", "bullshit") on the Internet is not someone I want to be working with.


What is the point again? If benign turns of phrase spoken on an internet forum factors into a company's hiring practices in any capacity, I'd say it's pretty much assured that it's a terrible place to work.


It's a very rude tone of voice. It's not a collegiate tone.


If you have too much attitude to sit down and write some code for an hour, then you aren't someone I want in my company.

Whiteboard sessions are typically done standing (an unusual posture for most people), in a non-interactive environment and importantly, in front of other people (which is quite different from coding, alone, in a development environment, in the sitting or standing posture of one's choice). Who also expect you to explain to them what you're thinking as you're coding, interrupt you with questions or hints, etc. An entirely different workflow from just sitting down and writing code.

Even so -- traditional whiteboard sessions might sort of be OK, if they kept it to a single hour. The thing is, these days, the sessions (whether using a whiteboard per se, or some tool like hackerrank) can typically go on for multiple hours, like 4-6, being stared at by 5-10 people throughout. And are sometimes very poorly coordinated (either the problem isn't properly stated... or it seems no one bothered to check that you've already done the first 2-3 hours of "idiot testing", and make you do it all over again when you get referred to another team, etc).

And this sometimes on other pointless exercises (like a full hour of solving pure logic puzzles, being administered to you by a fresh graduate).

At some point it just gets to be unnecessarily exhausting and humiliating. And no, it's not a symptom of an "attitude problem" if one starts to feel less than enthusiastic about the way some companies conduct these sessions.


Call me old school but before starting out writing code I much prefer to find a quite place, take out a pen and paper and spend the hour sketching out a few design thoughts on paper.

That entire process many only produce one or two sheets of paper, with many more sheets ending up in the bin, but I find it is time well spent as it makes the coding step much easier.


> Anyone who's made it onto an Olympiad team[1] of any significant geographical scale, in any category, shouldn't have to deal with this whiteboard nonsense.

Oh yeah? I've interviewed my fair share of self-righteous prima-donna "I shouldn't have to deal with you plebes" sorts before to know you'd better put them through MORE of this whiteboard nonsense rather than less.

And if they get all huffy, you know that when they make a pile of shit, they'll be the quickest out the door to run away from it leaving those of us with work ethic behind to clean it up.

Credentials mean precisely jack and shit to me. I want someone bright and humble.


You sound unnecessarily angry and your interview style seems far more formal than it needs to be.

Think their issue might be with you? ;)


You'd be wrong. A vast majority of people find me very personable. I'm only talking about this microcosm of human interaction.


That's the thing -- lots of personable, well-adjusted people do all kind of weird things when plunked into that bizarre "microcosm" of human interaction known as the hiring process.


Yep, and to add - interviews are almost never as reciprocal as they should be.

I've been to 20 interviews or so in the past two months and the common pattern with the worst companies is a near complete lack of reciprocal respect and almost hazing (like GP does). The best listen to what's said and evaluate the content and the character at the same time without the need to do "extra whiteboarding" to prove some...thI'm not sure what it actually proves. What does it prove? I'm really at a loss there.

Another thing about those nonreciprocal interviews is that they they tend to be led by significantly less talented folk in comparison. My friend Peter might know why.... ;)


Well I don't look at Olympiad performance as credential per se -- not in the traditional sense (like admission to an elite school, say). It's only a special kind of a geek that gets drawn to these competitions during their formative years; typically the kind that doesn't give a shit about "credentials" in the usual sense.

In other words, exactly the "bright and humble" type you're looking for.


I read the article as:

"It's not enough to be a mediocre engineer for a mediocre paying job. If you want to play in the local tennis league, you better be Roger Federer (without his pay)"

I think software engineers should counter-question the interviewers. Interviewers should be allowed to judge the candidate only if they can answer the candidate's questions to them. If the interviewer cannot, he/she is not qualified for the job of interviewing.


I think sometimes people forget that sometimes the interviewers don't actually want to hire someone.

- They might be afraid of someone who might outshine or compete with them.

- They might not want to train or mentor someone.

- They might think they don't need help.

- They already have someone they want to hire and are just going through the motions of "looking".


> They already have someone they want to hire and are just going through the motions of "looking"

Exactly, even when you show them (through a mostly well-done interview) that you are up to the job.


On one interview where it felt like that, my wife straight asked if they have someone lined up and her part is just a formality. The manager denied it but was visibly upset.

(Oddly enough, she (a construction engineer) was never asked to solve a few PDEs on a whiteboard or calculate a beam deflection over the phone)


I have done this and have done interviews I did most of the questioning as the interviewee. In my experience, this approach turns off a lot of people.


The point is:

If the candidate asks a relevant question that the interviewer cannot solve in time, the company failed at its own game because the candidate proved that he/she is better qualified than the company's representative, given the rules of the game.

What excuse does the company have for not hiring the candidate now?


The company is paying you money. The company is the customer of your services. This is why.


Except they're not. Companies rarely, if ever, pay interviewees.

Sure, it's true if you become an employee or contractor... but til then they're speculating (as are you).


Kind of like a salesman trying to sell you something... Enterprise software companies don't get paid until they say buy, and in the mean time the company hasn't been paid anything.


The 'excuse' that there are better or equally qualified candidates out there.

Many companies hire to fill in expertise, so the person who you are interviewed by may be less experienced than you in a particular technology.


> The 'excuse' that there are better or equally qualified candidates out there.

In that case, these companies should be ok with registering their names in an online registry saying they rejected a candidate for someone who is better qualified. For the following 6 months, they cannot complain that that cannot find qualified candidates.

> Many companies hire to fill in expertise, so the person who you are interviewed by may be less experienced than you in a particular technology.

So the interviewer should be asked a question by the candidate in that particular technology and if they can't answer, the candidate should be hired.


Suppose I have two technologies that are relevant, foo and bar and that I'm weak on bar, so seek to hire someone with bar expertise. If I'm constrained to hire the very first person with more bar expertise than my least bar-skilled interviewer, I probably won't make much progress towards my goal.

The goal is not to hire the first "not worst", but rather the reasonably best, where reasonable is a function of time and money, among others.


This of course assumes the candidate knows the answer to the question they asked, which is something the interviewer can't verify because they also don't know.


What if the interviewer refuses to do it. You walk away? And remember, you're the one looking for a job and applied there (unless you're jeff dean, of course :)


When enough candidates walk away, it prevents the company from doing productive stuff. Not only did they not hire someone who could do something, they also wasted so much time interviewing instead of doing productive stuff.

They'll feel the heat and hire a reasonable candidate.


If you're asking questions to determine whether the interviewer is suitable for the job of interviewer, then you're pretending to be the HR boss. I can see how that turns people off.

But if you're asking questions to determine if this is a company you might want to work for; you ask them how they work, how they're organized, how they handle specific things, what tools they use, etc, then you're simply doing your job as an interviewee, and I've found it doesn't turn anyone off; they just think I'm well prepared and honestly interested in the job.


You can do this, but it's easier just to end the interview there. Vanishingly close to nobody knows how to interview any more - and I've done more than my share as an interviewer.


Some really great advice within that forms a foundation for the narrative. I can really appreciate the diligence and apparent 'no hard feelings' kind of pragmatism. I especially liked the closing part:

>If you fail 10 interviews in a row, go for the 11th interview. But take a look at all the variables, and see if there’s anything you can do differently to improve. Take the pressure off, and work through problems routinely to keep your muscle memory in shape.

That reminds me of being in 'game shape' as I call it for playing and soloing - standing around thinking about notes to play doesn't come off nearly as fluid as being so practiced as to get into the groove and run with it. Good parallel. Nicely framed conversation, glad to read it.


Yeah. When I was job hunting ~3 years ago I knew I was going to have to do a lot of whiteboarding problems. I only had two 2 years of coding experience, and for the last six months I had been freelancing, which doesn't often encourage algorithms. I was working through "Cracking the Coding interview" and "programming interview exposed" but I was worried.

So I sent an email to everyone in my coworking space that I'd put a six pack in the community fridge for every person who did a mock whiteboard interview with me. Some of them came with their own problems, some of them picked problems from websites or the books that I hadn't done yet. Some of them were doing it as a favor, and some of them wanted to practice interviewing people. I got five mock interviews over a week, many of them with strangers. Best 40 bucks I ever spent. (I nailed the next real interview I had and got a job offer.)


That's a damn good idea. I completely agree, a job interview is something that you need to practice to be good at. Just doing code exercises isn't enough. Having someone do a real interview is the best way.


This is a brilliant idea


Any time a company asks me to do a HackerRank test, I immediately reject them. It's just not possible to have a quality engineering team and to also believe the results of HackerRank tests correspond to on-the-job success.

HackerRank is an attempt to commoditize software labor (literally reducing evaluation of your labor fitness to standardized examples). It communicates immediately that creativity is valued less than standardization, and that your uniformity and compliance are more valuable than your experiences.

It's also a way to position developers as lower-status employees -- you essentially have to capitulate to the judgement of higher-status employees. Even if you ace the code test, it puts you in a defensive position to justify yourself, which inherently reduces your negotiation power. If you submit something that is even slightly unconventional (even if it's provably just as or more accurate than conventional submissions), then your negotiation power is extremely damaged.

For example, think of the difference between actors who must audition and actors who are "offer only" -- they won't respond to your inquiry about hiring them unless you're prepared, based on their previous work, to make an offer already. If you ask Robert De Niro to audition, you'll get laughed out of the room. HackerRank is often like asking Robert De Niro not only to audition, but to do some kind of two-bit community improv class warm up exercise for his audition, then grilling him because he didn't enunciate clearly. Ridiculous.

Employers often say they want to "see how you think" -- when they say this, it's a good idea to run the other way. No one can grok some whiteboard code or some timed code test on standardized examples and draw any meaningful conclusions about "how you think" or how it will relate to job success. Someone who believes they can "see how you think" from narrow, time-constrained examples is going to be a terrible colleague or, worse, a very dysfunctional boss.

I think the trend of cultivating "full-stack" developers (instead of benefiting from specialization and separation of concerns) is the number one problem facing the software industry right now (and folks are largely in denial about it).

This nonsense with commodity interviews via HackerRank is the number two problem, followed closely by the prevalence of open-plan offices and the prevalence of Agile-like workflow management processes.


Ugh.

Using a coding test shouldn't be a red flag. They are an incredibly useful tool for weeding out the applicants who, quite frankly, don't know their ass from their keyboard.

I've done hiring at several companies over the years, and I can honestly say that the signal-to-noise ratio for programmers tends to be very low. Even eliminating the obviously unqualified resumes leaves us with dozens of supposedly 'qualified' developers. Further followup however in most cases (probably 60 to 80% of the time, depending on the seniority of the position) reveals that the applicant is all talk, and can't solve even the simplest of problems.

Eliminating that 60-80% of applicants is an issue. We could have, say, a brief phone interview with each applicant, trying to figure out which ones are garbage and which are good. But that would tie up actual employees for hours and hours, doing something that most of them would much rather not be doing. Instead, using a coding test to weed out the morons can work wonders. We set them all up with a simple problem set, and a day later it becomes very obvious which of the applicants are worth bringing in for a real interview.

Now don't get me wrong - if an employer rejects you because of a spelling mistake or judges you because they say you solved a problem 'wrong', then yeah, that employer likely sucks and you should be happy to have been passed over. But rejecting an employer simply because they asked you to do a test? The only one you're hurting is yourself.


The flip side of this is that most companies are "garbage" as you put it, and a lot of them simply do cargo cult imitations of the more popular companies. If a startup is saying they're going to disrupt the online vegan running shoes market and then tells me they have to weed out the "80% garbage applicants" with some parochial trivia about binary search trees that let's be honest none of us has given a shit about since we passed the exam on it in undergrad, then the code test absolutely is a big red flag to nope on out of there.

Since so many jobs are just shitty talent wasters, and you are just treated horribly, given poor equity terms, not paid what you're worth, etc., it unfortunately means that unless you have special knowledge that some particular job is non-shitty (like a trusted recommendation) then you're just better off erring on the side of nope.


If the company looks like garbage though, why are you applying?


If the candidates look like garbage, why are you screening them?

You can't always tell. You begin part of the process, then the company says how great their Agile teams are, or how "collaborative" their open-plan surveillance workspace is, or they invite you to do a HackerRank test, and only now do you know the company is shit and you pass.

It's the same problem you face with the 60-80% unqualified applicants. I get messages from head hunters, direct recruiter emails on Stack Overflow, traditional recruiting firm phone calls, as well as occasional job listings that I locate through a job search.

80% of these jobs are shitty and need to be weeded out, even when they have plausible-seeming job descriptions and acceptable GlassDoor reviews.


I'm screening them to eliminate the garbage? I'm not sure I understand your point here. We don't choose the applicants we want to apply, the applicants choose which companies to apply for.

The problems with companies that you mention above have nothing to do with the coding test, it's the company itself. Those are perfectly valid reasons not to continue the application process. But eliminating a company because they apply a coding test as a basic level of applicant screening still strikes me as an arbitrary move that does nothing but rule out perfectly valid job opportunities.


Most people don't get to choose who to interview. Your manager or your recruiter does not have enough data to eliminate the 60% unfit. But the first 40% are already eliminated because those candidates did not pass even the first phone interview with a recruiter (think Google hiring process).


My point is that candidates face that exact same problem when trying to weed out bad employers. That's why good developers reject the employers who try to use commodity tests like HackerRank. We do it for the same reason that the employer wants to use the commodity tests to weed out bad candidates. But somehow the employers don't understand they are just signalling how bad they are (apart from a very rare few companies).


Don't be so quick to speak for all developers. Most good developers I've encountered are willing to put some effort in to find the right job.


HackerRank-like lazy, commodity evaluation is not remotely close to "put[ting] some effort in to find the right job." It's very critical that we don't allow people to make the false comparison between actual interview effort and daft HackerRank time-wasting.

In fact, doing the emotionally difficult task of rejecting an employer who tries the HackerRank commodity nonsense represents putting in more legitimate effort to find the right job and to judiciously choose to complete code evaluations for companies that aren't being lazy and wasting your time.


Ha ha! Wow, that does sound difficult. You're a real trooper.


There's no need to be insincere or intentionally hurtful. Trust me, when you need a job and you've got a lot of life and family pressures building up, but you can clearly see how dysfunctional an employer is and how bad your life will be if you agree to work for them, it can be extremely hard to make the choice to do the right thing and reject them. It's even worse when you get to the stage of an actual job offer and an employer starts revealing how dysfunctional they are when they won't negotiate on basic features that are necessary for minimally acceptable worker health and quality of life.

It seems you really desire to deride me simply because you disagree with me. I don't take it personally, but I will say that the attitude you've displayed throughout these comments defending HackerRank-like evaluations is exactly the kind of attitude that would be indicative of a badly dysfunctional employer, and it's often exactly the kind of dysfunction that HackerRank requests are indicative of. Especially the parts where you try to turn it around and assert that a candidate standing up for minimally acceptable, reasonable treatment is equivalent (for you) to having a "bad attitude." It's quite alarming that you feel entitled to declare candidates as having "bad attitudes" for doing something that simply makes common sense from the point of view of avoiding employers who will waste their time. Contrary to suggesting that the candidate has a bad attitude, it highly suggests that the employer has a bad attitude, bordering on feeling like they are entitled to candidate labor, instead of privileged to have that labor, and somewhat whiny about it too. Definitely a bad signal when coming from someone involved in the hiring process.


Was the sarcasm a bit much? Yeah, probably. But really, everyone makes hard decisions when it comes to jobs. I just find it somewhat amusing that someone would reject a company entirely because they disagree with one single facet of a multi-step interview process.

While we're at it, I don't particularly appreciate many of the insinuations people have made about my team and my employers based simply on the fact that I see a role for automated coding tests in the interview process. But like you said, I don't take it personally either.

Coding tests are just one tool in an interviewing toolbox. Like any tool, they can be - and are - abused. You feel that any use of that tool is indicative of some unredeemable flaw in the company as a whole. I feel that the tool has a genuine role in the initial candidate screening process. We obviously disagree, and are spinning our tires trying to convince each other, so there's really no point in continuing the discussion.


> You feel that any use of that tool is indicative of some unredeemable flaw in the company as a whole.

This is a good summary of my position, except that it's not unredeemable. They could just stop using short, standardized, timed tests as a candidate evaluation, and instead they could acknowledge that there is no effective substitute for actually speaking with candidates, probing them about their experiences, and developing more nuanced understanding. Doing so would be time consuming and expensive ... that's life. Papering over the reality of the situation by pretending like automated, timed, standardized tests can measure the thing you need to measure won't make reality go away.

If a company is verifiably an excellent place to work and has excellent technology culture, and this can be verified ahead of time, then they do have the negotiation power to respectfully require completing code trivia (although most of the firms that actually are excellent don't do it this way even though they could).

Firms that are question marks to a candidate prior to some kind of phone interview to assess the fit, experience, and the nature of the role have no business trying to cheaply avoid the required costs of candidate evaluation. By trying to be cheap about it, they send a bad signal (and also generally don't succeed in getting the candidate pool they want to get).

Short, standardized, timed tests have no place in professional software hiring. Literally none. A company that uses such tests definitely raises red flags. It may be a sign of unredeemable dysfunction in the company, it may be some misguided HR initiative, it may be a totally fine place to work. The candidate can't tell and it's seriously not in their interest to waste effort on whatever the test is going to be.

There are just too many bad jobs ... the better decision rule is to always reject and if you end up rejecting an otherwise good job that somehow ended up using short, timed, standardized testing, oh well. The loss function is not symnmetric. Ending up in a dysfunctional job just because you felt good about acing their code test is a far worse outcome than rejecting an otherwise good job and being overly selective about where to work.


Yup, I still genuinely disagree with most of your points. Just not seeing the connection between using an interviewing tool and being a dysfunctional company. But like I said, spinning tires, etc. All the best to you going forward!


I think the problem is that you continue referring to it as an interview tool just because it is a thing that can be used for interviewing.

Making candidates stand on one leg and recite the alphabet backwards would also be an "interviewing tool" but it's not legitimate, just as short, timed, standardized coding tests are also not legitimate. Playing semantic games about whether it's an "interview tool" is not worthwhile. The question has nothing to do with whether it's logically possible to be used as part of an interview. The point is that it cannot provide the kinds of evidence that people claim it provides, and so continued usage of it for interviews can only be explained by other reasons, which is when it begins to be evidence of dysfunction.


That's not 'the problem'. That's the disagreement. You claim it's not a legitimate tool. I say that it is. We obviously disagree and this is going absolutely nowhere.


You say

> Just not seeing the connection between using an interviewing tool and being a dysfunctional company.

This is problematic because you're not representing my position. It's somewhat of a straw-man. You're saying that I'm saying that the use of some legit interview tool spells dysfunction.

But I'm not saying that. I'm saying that the use of an illegitimate interview tool (timed, standardized tests) is a sign of dysfunction.

Whether or not you see a connection between using an interview tool and dysfunction is irrelevant, because we would both agree that there's a connection between using an illegitimate tool and dysfunction.

So the disagreement happens at least one layer back, at the point where I claim that timed, standardized tests are not actually useful for determining who will be good at a job. The disagreement, and the whole discussion, has nothing whatsoever to do with "just using an interview tool."

I think it's very important to be pedantic about this, because in a lot of cases you keep referring to the timed tests as an interview tool, and speaking about them that way fails to acknowledge that the tests are not capable of producing the kinds of evaluation output necessary for actually determining who would be good at a job.

For example, a great engineer with loads of experience and glowing letters of recommendation about how effective they have been in previous roles might just be a very anxious timed test taker and tend to do badly on timed tests for reasons mostly of anxiety. Since the test is artificial and has no relationship to the actual work they would do if hired, rejecting them based on a failure on the test is a poor business decision.

It doesn't even have to be as extreme as an anxiety issue with test taking. A person could just simply disprefer working in a constrained, timed environment like a browser-based IDE with a literal clock ticking down. They might be a great developer, yet cannot even write FizzBuzz in that situation because it is so utterly and unreasonably alien compared to the manner in which they would do work in a real job.

The tests just simply are not legitimate ways of measuring programming ability. They do not control for all of the bespoke ways a person can appear bad via a timed test, yet still be good, nor do they account for all of the ways a person can appear good on a timed test, yet perform badly on higher-level thinking tasks, open-ended time management, or creative tasks like system design.

Very truly, the tests, and organizations like HackerRank, exist because it's a convenient fiction for HR and management, especially in companies that doesn't have very much of a technology staff to vet candidates. These places are happy to drink the HackerRank Kool-Aid because it gives them all kinds of plausible deniability about hiring the wrong people. It's very similar to the way that management consultants, far from actually functioning in any analytical capacity that benefits their client, really just exist to sort out internal power struggles through means of credential and prestige. It's very much a status-signaling sort of behavior. And it's even worse in the cases when a company adopts something like HackerRank just because some other, supposedly fancy, company adopted it.

Because of all of this and much more, it's just very critical to continue pedantically ensuring that no claim of the tests being valid, legitimate evaluation tools goes unchallenged.


And yet you are misrepresenting what I have claimed about coding tests. I have never once claimed it as useful for determining who would be GOOD at a job. I have claimed they are useful for filtering out applicants who are completely unable to do a job. This is an incredibly useful thing to do when swamped with dozens of similar applications for, say, a junior developer role. But again, this is just a first step. By no means should this test determine who gets hired, it merely helps narrow down the interview pool to something more manageable.

Is there a risk of falsely filtering good applicants? Yes. But that is the exception, not the rule.

Sigh. Why do I keep letting myself get sucked back into this? You see it as an illegitimate tool. I see it as legitimate. We disagree. I'm not going to agree with you, and you're not going to agree with me. So I'm done here. If you'd like to keep arguing by yourself, you go right ahead.


So, if someone fresh out of college who has time to spend lot of time on the sample interview questions he/she is better than someone with experience/expertise in a particular area?

Sure if the experienced person spends enough time practicing, can ace the interview as well. But he/she would rather spend time on interesting stuff than say, how to print a tree spirally and hundreds of other silly questions out there :)


Who said anything about grading results or comparing applicants? This should be a screening test, nothing more. Pass/fail. Any decent developer should be able to knock out decent responses to simple problems in very little time with no prep. The goal is simply to eliminate the ones who can't even do that.


Do you think printing a matrix in spiral order is a simple problem. If an experienced person who spent 10 yrs on file systems didn't get that in a 30mts period, would you eliminate him/her? And oh btw, you are supposed to talk through your thinking process as well in that 30 mts... while youre at it, don't forget that semicolons :)


Are you thinking of white board problems? Because that is not at all what I'm talking about here.


Yes.. white board problems and some go even a step wilder and share google docs (coding in google docs is really an art that needs separate mastery)


Using a coding test as the initial barrier to even a phone screen is what I have a severe problem with.

I think coding tests absolutely have their place - after a 30m high-level skillcheck over the phone, let's ask for a brief 30-45m timed code challenge to rule out the applicants who were effective enough bullshitters to clear the phone screen.

But I too have seen this trend that GP calls out re: "auditions" to even make it into the actual audition process, and FWIW it has not hurt me one whit to spend the last few years refusing to complete a code challenge as a prerequisite to anything but an in-person technical interview.

The only way it would hurt you is if the company in question is one you know you want to work for - and I'd consider an up-front code challenge for a few big names out there - but in most cases I simply write back and let the recruiter know my policy.

It's not like they're going to stop sending you leads, if you're a good candidate.

edit: grammar


But look at it from the company's point of view - why would they invest time in a 30-minute skill check interview for every applicant if they can just as easily run the code challenge up front and eliminate a large proportion of the unsuitable applicants?


The problem is that you can't "just as easily" run the code test. The code test is unreliable -- bad developers who overfit their knowledge to trivia make it through. The code test also causes the really good developers to simply reject you, so you don't even get a chance to hire them, or even find out who they are.

You're basically saying you want to lop off the bottom 60% of an imagined Normal distribution. Except you're really only lopping off some of the bottom 60%, and some fraction of that bottom 60% gets through, and you're paying the cost of also lopping off the top 5% who think you're a joke of an employer for being way too worried about the costs for you to more substantively evaluate those bottom 60% folks -- especially since you, as an employer, are probably in the bottom 60% of employers anyway, yet are cargo culting to try to act like you only hire the top 0.000001% or something.

You get what you pay for. If you go cheap on candidate evaluation (e.g. lazy commodity HackerRank), you get the McDonald's version of a developer, all while acting like you're being extremely selective.


Gonna have to disagree on that one. If some fraction of that bottom 60% gets through, that's perfectly fine - this is only the first step after all, and there are real interviews still to come.

And if this mystical top 5% can't spare the ten minutes to run through what is essentially an interviewing captcha - for a job they were obviously interested in enough to apply for in the first place - then how do I know they won't consider themselves too good to do their actual work if I do end up hiring then? I'm happy to hire the next 5% down the list of it means they have a good attitude and a willingness to do their job.

And what's the alternative? I waste my team's time setting up screening phone interviews for every halfway decent resume that comes down the pipe? With the number of applications that we get, we'd be losing days of time every time we look to hire, before we even got to the actual interviewing.


> And if this mystical top 5% can't spare the ten minutes to run through what is essentially an interviewing captcha

Every coding test I've been asked to take is a 2-5 hour job. I'll do it for a company I really want to work for... But not for a "maybe".

E.g. If I know you are paying 25% over market then 5 hours becomes worth it.

Now 10 minutes? I can spend 10 minutes on a maybe.


If I knew what your test was going in it wouldn't be an issue. Unfortunately, I don't know if I'm getting your 15-minute competency screen or, say, Virtu's 3-hour borderline impossible beating until I actually log in to take it. Since the latter seems to be more common than the former, it pushes me to reject you up-front unless I am desperate.


You said this so much better than I did. Thank you!


I understand the reasons why the company would choose to do it. My argument is that they are fixing the wrong problem - and to be honest, could likely be making it worse.

If so many unqualified candidates are making it to the phone screen (which should happen after they've been resume-sorted and google searched), it's an indicator that something at the leading edge of the candidate pipeline is broken.

Asking their potential candidates to make up for their failure is not only asinine but probably locks them into a cycle of mediocrity - highly-skilled engineers are getting more leads than they care to deal with already, they're not likely to take the time to do that upfront work unless there's a very compelling draw. You know who will? Untrained devs looking for a first job.

tl;dr - the candidates that would do unpaid work for the chance of an interview, and the highly-skilled, well-sought-after engineers I'd like to hire for my team, are likely two circles without any overlap unless I have some major draw working in my favor - like signing bonus, or being a Google.

edit: accidentally a word


Why would a company do anything that benefits its employees?


Full-stack developers should be generalist in nature to make sure the issues that cross domains (front/backend, etc) are taken care of. Also, they can plug any gaps in the development that crop up from time to time (eg: someone on vacation, or next feature needs more back-end people). The downside is that they will not be spectacular or as quick at any one domain.

Basically, a full-stack developers specialization is to be flexible and have knowledge and experience in working the entire application stack. Another way of thinking about it is that they are like a general practitioner doctor/dentist, while they generally don't do surgery, they can refer you to the correct specialists who can and take care of any minor/common ailments. This is also why you don't want an entire team of them is that they don't go into depth in any domain.

I don't doubt that the current full-stack education path does a poor job of education on issues that specifically cross domains or when a task is better suited to a specialist.


The desire for this sort of flexibility is a mistake. It sounds good, but it's naive. It's sort of like saying you want a single class in your OO design to be "flexible" so you make the class into an undifferentiated mess. Having a monolith class that "does it all" is a red flag of bad design. It's truly no different when the layer of abstraction is human software developers being organized for complex business problems. Having "flexible" people whose job is a little bit of everything is a major red flag of a bad design (bad management) that took the lazy way out instead of the harder but unequivocally more successful route of actually meaningfully dividing the workload between clean interfaces and having employees mostly specialize. "Sometimes you just need somebody to work across every system" is just flat out wrong. If you find you need that, it means you've been doing things in a very wrong way and patching over it by commanding positions to be full-stack is only going to perpetuate the problem.


This analogy is correct, except ... you're not Robert De Niro, and neither is almost any programmer in the valley. Just like almost no actor is Robert De Niro, and most actors are lucky to even be able to audition for commercials.


Your company is not Robert De Niro either! And, to boot, you don't have to be way up at the level of a Robert De Niro to be an offer-only actor. Basically, anyone with a decent and verifiable acting record is offer only. It's actually pretty common. And some actors are offer-only for some kinds of work, such as voice-over work if that's what they're known for, but not for feature films.

Anyway, I think your reply totally misses the point. The companies who are so obsessed with needing to weed out the bottom 60% are themselves well in the bottom 60% of employers. What gives them the audacity to claim that certain developers are too low skilled, if the company itself is not any good?

A good developer is going to see that and immediately walk away. Unless the company is already verifiably a great place to work with great technical prowess, then their obsession with getting rid of "garbage" programmers makes them seem extremely dysfunctional.

(Just look at how people here on HN are speaking about other developers -- so now you're "garbage" if you're in the bottom 60%, even though that still places you well into the top 5% of humanity in terms of technological skills and quantitative thinking. It's absurd!)


A piece of advice from someone who wanted to work at startups.Having realized that its unlikely that my skills will translate to doing well at startup interviews, its only pragmatic to not pursue that path. But my end goal is not to work at a startup, its to keep learning and to stay relevant/employable and those can be done outside of a startup.

Any interview that is structured like a test is a bad interview. Starting your relationship with an abusive process will set the tone of the relationship and I applaud all those who have walked away from interviews that make one jump through hoops. From personal experience, The last interview I took lasted 40 minutes and the person we hired is the best developer I know.

I was never confident at giving interviews until my mindset changed from it being a test to an exchange where someone who needs help is trying to get together with me, someone who can help them. They should able to explain to me how they see me helping them. Questions like: 'what is your biggest challenge right now' or 'if I were hired, what would be the first task' help start that conversation. They obviously will do their due diligence and I need to do mine (collaborative environment, sane hours, reasonable pay, competent management etc.)

All of the above is opinion.


> "Job interviews are difficult by design."

In the tech-sector at least they're not "difficult by design." They're obtuse and absurd due to laziness and lack of rigor applied to the problem space by individual firms as well as the aggregate marketplace.

Almost nobody applies anything remotely resembling a scientific method or includes the massive body of research available in sociology, psychology, and/or neurology for understanding even their own needs as a company trying to accomplish something, let alone building an effective social group (i.e. team) capable of cooperating together to get there given whatever that organization's constraints are.


Would you, kindly, start us off with whichever pieces are best for a company to implement/utilize in interviews?


Well, a good first place to start is to survey the various profile models that exist and figure out which one you can get most comfortable using/assessing.

http://www.businessballs.com/personalitystylesmodels.htm

I personally use OCEAN because I'm most comfortable with its scaffolding and applying it via field testing.

Then move on to how those models can be tracked/verified through neurological study. Dario Nardi @ UCLA is probably the most "renowned" researcher in this field, though there are many more.


Luckily in my current job search I've only been told there would be a whiteboard once (this Friday!). This article made me nervous though—as a busy student I don't have time to sit down and review/learn all those tree and linked list operations as well as their complexities.

Best interview I've had was pair programming with a team member and fixing a bug.


Yep! I have been interviewing for fun for the last few years (averaging maybe one or two interviews every few months), and I've seen all kinds of stuff. Way too many whiteboards. In fact, even after all these years, whiteboards still make me nervous, and basically makes it impossible to get into flow, or have a reasonably nice mindset for solving problems. And if I do this for fun, you can bet that people who depend on those interviews for their livelihood aren't feeling much better. I think it's a really stupid way to interview. Anyways, I agree with you: The best and funnest interviews -- and therefore the interviews I feel most comfortable (and therefore able to really show what I know) -- are the pair programming interviews. You build a special rapport with a single developer on the team, who gets a really good idea of the kind of coder you are. It's like a nice, calm conversation about technology.


While I appreciate that this process has been great for you, I would think that it probably sucks for all the engineers and managers whose time you took up interviewing "for fun". Have you ever tried to hire engineers? It is a pain in the ass, and giving serious consideration to every candidate takes up a huge amount of time even before the interview, much less taking a significant chunk of a day for a significant chunk of the team to actually do the interview.

If I found out someone had interviewed with me "for fun" I would be very tempted to send them a bill for "employment search consulting services" at my team's market rate per man hour!


You go into this process knowing that it consumes time and that not everything is going to pan out. If you had the data and processes to identify the perfect candidate, you wouldn't need to bring people in to interview.

It's not waste, it's data collection. If you're not building usable data out of your interview process, your hiring process sucks.

My team was interviewing candidates recently and we brought in a guy that was great on paper and in the interview but we had other candidates scheduled and two of them ended up blowing the first guy away. I'm glad we delayed that hiring decision until we had an appropriate amount of data.

Also, think of it like dating (or any other matching market). Being outcome-dependent says nothing about your candidates but a lot (that's unattractive) about you.

The best way to do things is to build good relationships. Your company and your developers should have a network of people you can bring in at any time to interview for a position. As a developer you should also have a network of contacts to know who needs developers. Instead you're waiting till you're desperate and coming off as needy. If I see that, I'm going to ask for a lot more money or as an employer offer less.

Thankfully for my wallet, almost everyone else is in the same boat as you.

...and if I'm out interviewing for fun and find a better fit, I'm probably going to take it.


Here's really the meat of it (and well said!): I interview "for fun" because 1) I've always got my ear to the rail for a better opportunity, and 2) I love meeting cool, smart people working on awesome projects! I'm not a VC so this is my way of touring the technology industry and networking. The thought that I'm "wasting" someone's time I think is really strange.


I've had people bring me in to chat telling me ahead of time that they weren't interviewing me but they wanted to get to know me so that when I had the years of experience they were looking for they'd call me up.


Do you pay the people you interview their hourly rate?


OK, but what's much more common is companies interviewing candidates 'for fun' It's unbelievable how many companies will spend their time talking to every available developer in town, and end up never hiring anyone.


Tbh, I sometimes say I interview "for fun" even when I'm serious about leaving because I want a better fit than I have and the process might take me a year (or longer) casually interviewing.

I don't want to spook my current employer due to long term job prospects being poor.


A lot of people do this though—my finance friends have been interviewing for internships and jobs there's no way they could get for fun and practice. Essentially they've wasted people's times for 2-3 years so by now that they're seniors any interview is a piece of cake.

I guess that's more useful than just for fun though.


Hilarius response.


I love the idea of interviewing for practice, and would do it myself, but I only have 10 vacation days a year to blow. How do you manage it? Pretend to be sick? (naughty, naughty)


Most companies are pretty flexible about interviewing you if you ask, and also my work hours are flexible where I'm at, in addition to my already being able to work from anywhere at least some of the time (in fact this is near the top of the list of non-negotiable things I look for in a job). I can work around an interview pretty easily, especially because I'm already nearby. I have only had to take vacation to interview one or two times. All the other times I just make it work. But to address your question, I do in fact sometimes "pretend to be sick", because someone very wise once taught me as a young programmer to take "blue flu" days away from the office to help maintain a good work-life balance. I think this alone has been instrumental in preventing burn-out, because I am also at times the kind of person to work hard without any kind of break, which I think can be detrimental. When I mentor, I try to pass this along. You should take blue flu days, too!


That's great if you live in an area with a bunch of companies you want to work at. If, like me, you don't you end up having to use vacation days and make up excuses for short-notice one and two day absences.


nice hobby you got there ;) What do you if the company wants to hire you?


Obviously, if the offer is better that what you already have, you seriously consider accepting it.

Otherwise, you tell them that their offer is not competitive, and maybe the next monkey to come along chasing their peanut can benefit from your feedback.


That's an excellent approach. It's quick enough to get meaningful results, it's interactive, and it's not artificial in the wtf-coding-without-an-ide way that whiteboard coding is like.


Yep, it's good because:

* Tests your knowledge of the language/framework

* Tests your problem solving and bug fixing abilities and workflow

* Tests your debugging skills

* Tests your ability to work with other people

Not all of these are crucial (except the last one), but this format tests what is most relevant.


I applied to around 100 jobs over the course of 9 months when starting to learn how to program. For the startups I would get to a phone screen and potentially a technical challenge then be turned away. At the job I am at now, was contacted by CTO online, and had phoned/on-site/started within 5 days of initial contact.

I've seen a bunch of blog posts recently about some companies priding themselves on who they turn down versus who they accept and I feel that is one of the bigger problems we have as an industry in hiring.


I realized something a while back... My entire career, if I've made it to an on-site interview, I've only had one company NOT make me a job offer.

That interview, I was asked to do something using recursion. (Ug.) The next interviewer asked me to reverse a singularly linked list, and because my brain was still in recursion land, I tried to do it recursively. Blame the jet lag, okay? Immediately after I sucked at that, they walked me out the door. It was emberasing. Two steps out the door, and my brain is filled with POP AND PUSH! AAAH! I knew the answer, I've KNOWN the answer since I was about 14. No joke. So, I've been on that side of the "every now and then people interview poorly" thing. And I can only blame the jet lag, because I KNOW the ridiculously easy answer to that question.

Here's the funny thing - if I would have been offered a job there, I would have accepted. And the company went on to crash and burn in terrible fashion. And two months later, I got a job at a MUCH better company.

TL;DR: I've only failed at one interview, and it was arguably the best thing that ever happened to me. (Life is weird!)


Except ... reversing a singularly-linked list recursively is trivial.

If you can't do this, you are not qualified at basic manipulation of data structures and you should fail the interview if they want someone with basic competence in data structure manipulation. Sorry but that is how it is.


Because so often we are faced with having to implement singularly linked-list reversal.

I wouldn't even bother implementing this myself in the real world and I have a degree in computer science and 10 years experience doing dev work. I would type the problem into google, survey a couple of solutions and pick one I liked. Done. Next problem please.

This is pedantic crap that is a waste of anyone's time. I can't believe people actually get asked shit like this at interviews? Well, at least none that I've ever been to. They look at my resume "Oh, CS degree at well respected University." and you can deduce that this person can probably work out trivial crap like this or look it up in a book or the internet. At most ask them for their academic records. What a complete waste of time in an interview..


The point is that if you can't do this, there is no way you can do stuff more complicated than this, which will actually be necessary during regular work. (And which you won't be able to type into Google).

I run a software company and I'll say straight up I would not hire someone with your attitude.


Yeah, you're not getting the point of my story.

I know it's trivial. It is trivial. I can do it in my sleep. I used to write Pascal code, back before all these Generics and Templates, and I had to write data structures the old fashioned way.

What I'm telling you is that the jet lag got to me. This is like when you can't remember the name of the actor who played Batman in Batman Begins. Or when you can't remember what year your mother was born in. Or you can't remember the capital of the state you're travelling to. Or you're multiplying 7*8 and write down 42 in a momentary lapse. It was a completely "DUH" moment.


This is just an ad for hackerrank.

And yes; it is hard to find a job in Silicon Valley if you are sitting in Kazhakstan and need a visa too. Duh.


And honestly; don't spend you time practicing silly brain teasers and programming quiz questions. Write meaningful software that you into production.


I've been struggling with this issue for months. I really want to be hired by Microsoft, Amazon or Google, but I feel like the time required to prepare for the inevitable "hazing" would be better served exploring new technologies and creating new software.


> You don’t get to use to your own IDE, you have an absurdly limited amount of time and you’re in an incredibly high-pressure environment.

Here's a good interview tip that's helped me out with my last two job moves: Whiteboard code almost always comes out looking like crap because once you've fleshed out the idea, you can't easily insert lines. The solution is to bring a laptop with the IDE of your choice ready and say "Hey, I'm not really good at whiteboard coding. Do you mind if I write the code on my laptop here?"


If your interviewer really dings you for the appearance of your scrawled code on the wall, they're being self-defeatingly stupid and you'd probably be happier working with other people.

I do lots of tech interviews, and I always make it clear that I don't care how pretty the ink looks. I stick with the whiteboard because it's the best way for candidates to explain their analyses and algorithms before they write the code.


My Google interview in 2008, one guy asked me to write a binary tree structure and implementations of depth and breadth-first search (maybe also balanced insert?) on the whiteboard in C, which I blew through in no time. He then immediately said it was wrong and let me wither for a few minutes trying to figure out what the problem was before pointing out I forgot a semicolon.


I hated seeing that kind of crap when I was on the hiring committee, and I think that it's less likely that you'd run into it today.


Thanks, it does sound like things have changed. I probably would have been a better hire back then than today though. I was younger, cheaper, and had an almost OCD drive to learn everything CS since I had a complex about getting into the game a little late. Today I feel like I wouldn't be able to maintain my current lifestyle with a wife, two kids, two dogs in the bay area. Occasionally I think about it though...


I was given a brain teaser puzzle during my D.E. Shaw interview process in 2006. One of my interviewers told me that my answer was completely wrong just to see how I would take the criticism.

I guess calmly evaluating my conclusions and approaching the problem with a third algorithm (I had already devised two and compared the answers) and then calmly asserting that my answer was in fact correct was the right move.


> One of my interviewers told me that my answer was completely wrong just to see how I would take the criticism.

I do this sometimes. A strong developer would have a good mix of defending the design decisions made and the acceptance of the errors made. This test should bring this characteristic to the forefront.


I think that lying to a candidate is unethical and unfair.

You can get similar results without crossing that line by asking questions like "can this be made faster?" and "is this correct?", soliciting proofs of lower bounds on asymptotic complexity and loop invariants (respectively). But you shouldn't tell a candidate that their code is broken when it isn't. Interviewing is stressful and scary -- don't make it worse just because you can.


> soliciting proofs of lower bounds on asymptotic complexity

A mathematical proof on the lower bound? is that a common request and something I should prepare for in an interview?


If I ask you whether your sort can be made faster, and you can make a credible case that it's O(n log n), so no, I'm happy.


Wow, you are just an asshole then. There's plenty of ways of having someone defend their design decision without resorting to such unethical behavior. What are you a 4 year old? What a bunch of crap. I hope that comes back to you.


You could've played their game to make a point.

"Ah, no wonder it didn't work!"

Then draw out an IDE around the code with a big [Compile] button.

Maybe even Clippy in the corner of the whiteboard. "It looks like you're trying to get a job..."


First of all, the interviewer might not be doing it consciously. Code just looks better in an IDE, the same way a guy in a suit makes a better first impression than a guy with sneakers and ripped jeans who smells like pee.

But that said, if you were interviewing someone and they did all of their algorithmic boxes and lines on the whiteboard but switched to the laptop to write the code, would you ding them for that?


Beats me. I've never worked at a company that would allow a candidate to fire up a laptop during an interview.


I was once asked to set up the interviewers laptop.


When I used to interview contractors (more leeway in the interview process) I would put them in front of a computer with Visual Studio and a web browser, because that's how people actually work. I didn't get enough samples to tell if success at that correlates to success on the job, though.


Actually, I prefer whiteboard because I prefer drawing a lot. As far as code quality is concerned, I'd have the interviewee to work on a small challenge and submit the challenge in two days. Nothing majorly difficult, just some hackathon-kind of app challenge. If the candidate has a public code profile I'd check those out.


During the last 10 years i always go for a solution, just a coded solution (and if you do it quickly, or even while doing it, you can frequently improve upon it significantly). Doesn't work for Google/FB - they probably want the elegant super-performant solution that i usually come up with in the next few minutes after the interview is finished :) - yet it works just fine with the rest of the companies.

Hint: almost always start with putting the input into a tree, and if tree is completely out of question - into hashmap :)


There's too much missing information in this article. In today's environment, a qualified programmer with the background this guy appears to have should get offers at a much higher percentage of companies.. IF everything is on the level: decent communications skills, applying for jobs whose requirements match skills, realistic compensation expectations, and (my guess in this case) already authorized to work in the US.

I would expect this low hit rate from a qualified individual looking for a job AND an H1B sponsor.


The H1B factor certainly has weight - I can imagine it leading to a 2x factor in his rejection rate. But not the 5x rate he's apparently had to suffer through.


I would also have to imagine most of the H1B fallout is at the initial screen, not after multiple interview rounds.


"I got into the final interview for an extremely high-growth human resources startup. That was exciting, and I really thought I was going to get an offer. But, eventually, the last round of the interview was super hard. I just failed."

Been through this too many times.


When I was first applying for internships (as a college junior with sort-of-interesting projects on my resume but no real experience) I think I applied to 75 positions, heard back from maybe 20 and got to the first round at 5 or 6 (including code challenges).

The 6% return rate (application to interview) wasn't exactly encouraging. I made a habit of working hard on each application, sending it out and then immediately assuming that I'd been rejected, putting me right back in that stressful place I'd been before.

Being able to leverage that stress into something productive was huge, I'd wake up early and spend my mornings working on cover letters (useless) and researching companies, and eventually took myself across the city to crash another University's career fair to try and meet a recruiter from my then-dream-company (one I'd applied to online months before and never heard back from). That turned out to be one of two offers I got and where I spent my summer.

Keeping up a grind on applications and not getting discouraged is huge, getting into the mindset of "constantly apply until I'm employed, don't assume anything will work out" was probably the real reason I got the job I did.


Lol, 38. Only 38. In today's job market one should expect rejections from dozens, potentially hundreds of companies. With hundreds of qualified people apply for each job (thank you electronic CVs) 99+% of applications, of interviews, result in a rejection. It's the new normal. The days of interviewing only a handful of people are long over. Nobody should take it personally.


Excelling in an online programming competitions sounds like a fun, exciting way to showcase myself to multiple companies all at once. Way better than white boards, for sure!


That might sound "cool" if you are straight out of a college with plenty of time to spare, no full-time job and family to support. Otherwise, it's not so compelling.


Recently came across an example where someone entirely different person went for the interview answered, cleared but the another person reported for the job.

I must say I am extremely disappointed at bay area job scene.


> You don’t get to use to your own IDE, you have an absurdly limited amount of time and you’re in an incredibly high-pressure environment.

Ironically, HackerRank itself is a part of this problem. All of those are true for HackerRank coding challenges.

As another commenter has pointed out here, HackerRank (and other coding test platforms) want to commoditize the hiring process, but in a way that ensures that candidates are the ones who are doing the all the work. The companies just don't want to spend any time in the interviewing process. It's no wonder that so many companies are struggling to hire good engineers.

If you as a company throw me an online coding challenge as the first interaction, you can be rest assured that you won't be hiring from me again (and many others).


My favorite interviews have been ones that started with the company giving me a choice between a few small programming projects. They usually let you do it in your own time, over a week or so. When you turn it in, they can see how cleanly you write code, how careful you are about edge cases, whether or not you write unit tests, etc. etc.

Of course, then they call you in to their office and...... give you a whiteboard interview that lasts 5 hours.


I have bootstrapped startup and I was rejected by at least 380 companies. Ok I'm not talking about hiring but about sales pitches (with demos and what not).

So again if you are looking for a job, think as salesman. And in sales rejections are part of life.


I've seen articles about technical interviews too many times to count, and while I personally don't believe whiteboarding is a good tool for interviewing and don't use it when I perform interviews, I do believe that any good engineer should be able to whiteboard answers with relative ease. The gripe really is dependent on the specific questions, however if you've worked with a technology stack you should be able to recall the function names, parameter order, and basic pseudo code syntax to write answers to questions. If a developer is dependent on their IDE or Google to do absolutely anything, I wouldn't hire that person. Even developers directly out of college have done enough programming to do the basics, and if a developer can't they should be honest about their abilities and rather than stumble through a wrong or incomplete answer. Often the interviewer will still ask you to try your best, but it's important to be honest about your capabilities.

I've interviewed at dozens of technology companies, many that do whiteboarding, and I've always done well. I've gotten offers significantly more times than I've ever been rejected, this isn't because I interview well, but because the things I claim to know and be an expert at, I know better than the back of my hand. If a software developer has been writing code and working with a set of technologies on a daily basis for years, I'd expect the same of any of them.

From what I've seen of the modern software engineers isn't that they interview poorly, or that whiteboarding is the blocking issue. It's that they're actually poor engineers. Lots of people are taking 8 to 10 week crash courses on programming and think they are near the same level as someone who went to college for four years, even tend to expect the same pay. I actually don't think college is generally useful for software engineers either, but it's about the time spent. The best programmers by far are those who started young and even program personal projects as a hobby, who actually love to write software. I love writing software, getting wrapped up and losing track of time, creating amazing software that solves difficult problems and is a delight to use. I hire developers who are the same.


"if you've worked with a technology stack you should be able to recall the function names, parameter order, and basic pseudo code syntax to write answers to questions."

That's not true unless you work with very narrow technology or single framework. For example, good luck trying to remember all these POSIX API functions. I don't even try to remember mundane things by heart, because it takes a precious and very limited resource (brain memory) for a very small gain (few seconds saved that would cost to look it up).


"Never memorize something you can look up" -- Albert Einstein

"I wrote it down so I wouldn't have to remember!" -- Professor Henry Jones

Two of the pearls of wisdom I live my life by. Actually, most engineers do. That's why huge books of nothing but formulas, lookup tables, and reference data exist.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: