Hacker News Reader

Comment by vinhboy | Hacker News Reader

After 10 years of working in web development, I was on the market a few months ago. It was the most humiliating and defeating experience ever. I basically failed all my whiteboard interviews (that includes using things like coderpad). Most of my interviewers didn't even ask me about my experience, just straight to test.

By the end of it, I decided I should just apply for Junior positions. I also got the advice that I have to take a couple months off to study for them. So that's what I did. (Not easy to do when you have mortgage to pay and a family to feed)

But what I hated most about the process is that there is very little feedback on why I didn't do well. Obviously they had a reason why they didn't like --me-- (edit:my code). I wish companies were more open to giving feedback. I gave you an hour of my time, it would be nice to get 5 minutes of debriefing.

View on HN

Many companies won't give that feedback purely for legal reasons. There might be internal policies on proper wordings they must use when they do not select a candidate just to be on the safe side. The HR or whoever is sending you an email must be very careful or getting sued is very easy. Often people are not realizing this. There are several reasons why someone might not hire you. It can be purely on the technical questions you answered, it could be due to the "fit" criteria (you can be the best programmer out there but that doesn't mean you can fit well with the team), communication ability (articulating something clearly is very important) etc..

An interview is a two way channel. They must like you and you should like them. Although when you are interviewing for some company it's mostly your livelihood that's at stake so you may not think if you are going to be happy and fit well there as long as you get good benefits etc. While it is true that someone cannot be judged in 2/3 hours of interview, there is not much of an alternative here so sometimes it is a leap of faith albeit a calculated one.

If it's specifically about feedback on the whiteboard exercise, I find the legal excuse to be a bit weak. It is something organizations will hide behind because it's a lot easier to say, "I'd love to give you feedback, but HR/Legal says we can't because of liability concerns." That makes the company look like the good guy, just blame the system.

Specifically on the whiteboard, the primary reason for not providing feedback is very simple - HR and managers have jobs to do, and they're going to focus on their primary duties on the business side, and active candidates on the HR side. Once you didn't pass the exercise, they're not going to spend time on you because that's inefficient for them - essentially sinking someone's time to write you feedback when you ultimately won't be working for them.

In the US, anyone can be sued for anything, so it is technically true that there's a legal reason not to give feedback there. But I think the risk of that takes a back seat to simply not wanting to spend the time on something that isn't seen as valuable to the company even if it is to the excluded candidate.

Now, as to everything else, particularly "fit" and all of that - yeah, there's a very valid legal risk that would suggest you should not provide that feedback. Fit is subjective, and a lot easier for someone to decide fit meant age/race/sex/etc.

My final opinion is that this type of feedback wouldn't actually be useful. It sounds like it would be, but that suggests that hiring orgs all think the same. They don't, and that's good for all of us.

> If it's specifically about feedback on the whiteboard exercise

That's exactly what I am asking for. I am not looking for feedback on me personally, but I would like to know why I failed the whiteboard.

If I did something wrong, or inefficient, I want to know this. It's such a good learning opportunity, it's a shame for it to be wasted.

And it won't even take that much time. Just send me a quick email.

I always ask for feedback, so one company said something along the lines of "you didn't use OO, and you didn't name functions very well for someone with your experience"

That was like a lightbulb moment for me.

The thing is, if you know you screwed up the whiteboard exercise, you should think about whether you need anyone's feedback. There are lots of materials and guides on working whiteboard exercises, given how pervasive they are in the industry. If you're self-aware enough to know the whiteboard exercise sunk you, you are in a good spot to identify and fix your weaknesses.

This is not intended to be harsh, but comes across that way in writing: It's not a wasted learning opportunity just because someone else isn't willing to read out your evaluation. Critical thinking is as important as any other skill to a developer, so you going back through what you did and then looking at opportunities for improvement is as valuable as anyone else's feedback. I get that it's helpful, all I'm saying is it's not entirely necessary, and not a showstopper to improvement.

I mostly agree with you and I very much do what you suggested. After all my interviews, I spend a lot of time researching the question to see what the correct answer is. For example, in one interview they asked me to make a crossword puzzle solver. After the interview, I spent the rest of the day researching algorithms to do this.

That's great and all, but it doesn't give me insight into specific things I could improve for the next interview. Was I too slow? Was my solution too convoluted? Did I spent too much time thinking and not verbalizing? Is my solution wrong?

I wish to have that kind of feedback because it will highlight my deficiencies.

I get that they don't owe it to me to provide that feedback, and there is no incentive for them to. But it's a nice to have.

As software engineers, we're all familiar with code reviews and why we do them. This is very much similar to that.

> That's great and all, but it doesn't give me insight into specific things I could improve for the next interview.

This is where I have an issue - it presumes that the interviewer knows more than you! They might, but the next interview might care about a completely different set of issues. That's why I suggest limiting the importance on feedback there. It's as good as the person giving you feedback, and you don't have much to go by on that. You also don't know if it's the whole story or the whole truth.

> I get that they don't owe it to me to provide that feedback, and there is no incentive for them to. But it's a nice to have.

I agree it's nice to have. I'd probably provide it if I did whiteboard interviews.

That's why I suggest limiting the importance on feedback there.

Nothing they said suggests this feedback is the most important thing to them, they were only asking for a quick email.

I understand your point but strongly feel that the value of being self critical as a developer to be limited, specifically in this context.

Without proper feedback, I'd say it's akin to editing your own novel. Sure, you might get to the point where you have no typos and you've rephrased some pointless sentiment a thousand times until it's just right, but your editor is the one who's going to tell you to throw the entire first chapter out because you're assuming prior knowledge about the story you're trying to tell.

I'm drawing a fine line and doing a bad job of it. I think feedback is good, but I don't want to overvalue the feedback from the interviewer. That message is going to be specific to that hiring manager and organization, and some stuff might be made up because it's safer to say you did poorly on the whiteboard coding than it is to say you weren't a cultural fit. So even if you get feedback there, it may be to backfill the reason for not hiring you that they might not actually want to share.

Objective eyes are good. Do the exercise with someone disinterested and see what they say. It's not that feedback isn't valuable, it's that the value from the interviewer is limited for the reasons above.

I tend to agree with that. Very much like soliciting design or product feedback from users. You don't want to be implementing every button or specific feature that a user says they need. Find what to gain from it if anything and hopefully find some growth from it. Thanks for the clarification.

Many companies won't give that feedback purely for legal reasons.

That's not the real reason. They like to think it's the reason. But it's not the real reason.

The main reason they don't like to give feedback is that it's awkward and embarrassing. And because the most hiring managers (and especially most HR staff) don't have the communication skills (or plain and simple personal maturity) to convey the information tactfully. And because (in a large part due to the second factor mentioned), it can take up a an awful lot of time (in a process that generally ends up taking much longer than anyone would like or expect it to, in the first place).

(Yes, I know there are anecdotal stories of candidates occasionally getting all huffy, or in fact doing much worse, when you give them honest feedback; and I wouldn't doubt that there's been a frivolous, costly lawsuit here or there, once upon a time. But still, my observation of the industry and of general human nature suggests that's not the real reason).

Even so: I'm OK with not getting feedback. And I can (sort of) forgive them when they're late in coming back with a simple "no". But not getting any kind of a status (not even a boilerplate rejection email), ever? That's the part I don't get.

This is just cargo-cult lawyering. Telling a candidate the reason why they failed is standard practice for Facebook, Google, and many startups.

I think that it's a good sign of how confident a company is in it's outlook by how they approach interview feedback.

Unless that feedback belies discrimination toward a protected class, it poses no legal risk. Conversely, it sours the candidate's impression of the company when a recruiter refuses to give meaningful feedback. People talk. A future customer might be friends with that candidate who failed.

What did you eventually get? And why did you feel you got that job?

edit: o_O, I'm really confused, but it seems someone down voted me for this question. To be clear, I'm trying to understand how OP overcame his/her difficult circumstance. As well as what their opinion is on them overcoming the difficulty.

I eventually got hired by a good company that really needed a Ruby developer for a short term contract. From what I can tell, so far they seem very happy with my depth of experience and ability to take charge. I am very full-stack, so all they have to do is tell me what they want, and I'll make it happen. I enjoy it, because I like building things.

But because it's short term, I have to find time to continue studying so that when I get back on the market, I can pass those whiteboard interviews. It's very challenging to do this when I have a full-time job and a family.

I never thought I'd be here at this point in my life/career. It's depressing. But as they say, you gotta do what you gotta do.

I definitely know what you feel like. I'm in a very similar position. ~4 years at my previous company where I worked my way into a Developer position, and then recently left to work with a friend in another company.

I like the company I'm at now and although it's full-time with no end of employment in sight, I know eventually I'll have to go through the normal process. I've worked at 2 companies now as a developer at varying positions of development, and I don't feel qualified to pass a single interview.

Luckily I have time to prepare, but I really need to get that established. Probably take the time to do a proper CS course to boot. Keep your head up, and thanks your reply :)

Have you thought about moving into architecture?

Your posts could be my friend; 40s, 20+ years in tech from junior positions up to CIO. He failed a few whiteboard interviews for dev positions and called me asked for help getting him a gig.

I took his resume, tailored it to highlight his high level work, stripped out dev grunt work references, and started targeted applying as him to several companies. It worked.

Thought about this extensively. But I feel the imposter syndrome creep up every time I go this route.

My mistake is that I spent too much of my career working for tiny startups with 1 or 2 engineers, doing grunt work. I never got the chance to lead big projects and prepare myself to be competitive in that bracket.

I have friends who are in that space, or higher (CTO, etc...). Although I hold my own with them in terms of technical knowledge, they all have backgrounds leading teams and working for big companies.

I made a mistake in trying to chase the startup dream.

> But I feel the imposter syndrome creep up every time I go this route.

Fake it until you make it.

> I made a mistake in trying to chase the startup dream.

Its only a mistake if you didn't learn from it.

Do not feel defeated. You seem to have the necessary skills and knowledge. You can do this. Sell yourself.

Source of experience: 15 years of tech experience

i know that feeling, and it's a constant struggle to try and decide whether to waste time studying how to pass an interview that uses skills you'll probably never use at work again until the next interview, or use that time to actually learn a new language / framework or read some reference books

I'm interested in hearing the answer too.

I've never had an "formal" interview and I wish to apply for jobs soon, but I find the interview stage intimidating enough that it's pushing me to just work on my own stuff and try to make a liveable wage off them. I also have no formal CS background (i.e. no degree), and I'm based somewhere in Asia where formal educational certificates matter a lot more than people would admit. These two factors are seriously making me reconsider ever applying for a dev/engineering role, even though I'm sure I have the skills and necessary experience to excel.

(edit: removed my specific location)

Kind of interesting feedback I received recently. I worked with a recruiter on a couple of interesting opportunities. One opportunity led to a final interview that was horrid. Afterward, the recruiter said that over the past few years she had a higher success rate placing recent college graduates into senior software engineer positions than experienced software engineers. She believes that interviews are now biased toward instant recall of facts around the current slate of development technologies, which recent college grads would have an advantage in.

In my experience and the experience of other senior engineers I'm friends with, we've taken on more operations and support for systems we built. So, our technology knowledge became "frozen in time". Lost is the fact that we had to adapt to changing paradigms throughout our careers. For instance, I can't recall the state diagram for a request in Spring MVC. (That was an actual question on my interview.) But, a few years ago, I had to put together an app using Spring, never having used it before. As per usual in my IT shop, I never had to use it again.

The interview process in our field is indeed humiliating, and it infuriates me when people refer to this mythical "shortage" of developers. The interview process centered around competitive coding and academic trivia questions is proof that there is no shortage.

The problem isn't merely lack of feedback, a lot of the time they won't even contact you to inform you that they're not interested even after multiple rounds of interviews. We need to start outing companies who refuse to give feedback.

On some career advice to keep interviewing even when you aren't looking for a job, I started trying to freshen up my experience. As part of that I did 3 practice interviews with https://interviewing.io/ and they were helpful – the feedback is honest, both about my presentation (e.g., I jumped into coding too quickly), and just stuff to know (e.g., A*). The practice sessions only cover the "whiteboard" part of the interview (not the "tell me about yourself" part). I feel a little bad I haven't followed up and done a practice interview for someone else, but I appreciate the people who helped me out.

hey, founder of interviewing.io here. no need to feel bad =) though you're always welcome, in any capacity!

I didn't know these kind of places existed until I had to interview. I honestly thought it was too niche and must be some kind of scam.

But after like two months into my job search and feeling hopeless, I signed up for one of the sites to do practice interviews because I was running out of options.

I never went through with it because I got an offer, but I will definitely put this in my tool bag and will start practicing in the near future.

I now understand why there is a need for these types of services.

If whiteboarding is not for you, this list was on HN few weeks back.

https://github.com/poteto/hiring-without-whiteboards

CircleCI is in there too.

.. or spend time with. What's grating about the interviews you describe, where it's comp sci 101 versus experience, is that it punishes people who have years of experience in the field and established lives outside of work. Meanwhile, the 25 year olds comp-sci grads have it fresh in their minds, so appear more qualified.

25 yr old fresh Comp-Sci grads are way cheaper to employ than a 40yr old with 15 yrs experience. I see these types of interviews and hirings as straight up Ageism and cost cutting measures, without actually having to say 'Only college grads apply'.

I've seen well qualified candidates turned down by ageism. At a prior company, I was in a group interviewing a guy, and a manager said, after his second interview, "I just didnt see the passion." It's sad but true in tech.

Counterpoint: if you've spent years programming without somehow using the fundamentals often enough to have them deeply ingrained into your psyche, maybe your experience isn't a fit?

Some companies don't want a decade of writing crud apps.

Which is totally fine. But when that company's main product _is_ a CRUD app.... I don't want think these inverting a binary tree questions are very useful. If your company actually _does_ do that, then I totally agree, a web-designer with some Rails experience, is probably not the right fit.

"The fundamentals" can cover an immense amount of ground, especially if you're old enough to have worked in a lot of different sub-fields.

Counterpoint: If you find you're having to implement "the fundamentals" that often, maybe you aren't a good fit for an engineering position.

Not every company wants someone who views every problem as a nail to hit with a CS[1-4]01 hammer.

There are positions where novel applications of known algorithms are required for which no existing implementation exists and there are research positions for generating new algorithms. These positions together comprise a tiny fraction of intellectually challenging software development (and an even smaller fraction when your pejorative "CRUD" applications are considered). I'd guess outside of these two contexts and school the need to understand "the fundamentals" well enough to have them "deeply ingrained" is smaller still.

Counter-counterpoint: here's a bucket of sand, some ore, and a furnace. Make a processor. Be sure to explain your thought process as you go!

(after all, this is "fundamentals", right?)

The choice of which "fundamentals" to test on is entirely in the hands of the interviewer, and for sake of ease seems to have converged on pop-quiz-style problems which do not test knowledge of "fundamentals" but instead test ability to snap-recall things that -- let's be honest -- don't get directly used a lot in day-to-day programming. How many working programmers honestly write graph or tree structures from scratch on a daily basis? I don't. If I need something basic I use a library -- its implementation is likely to be more correct and more robust than anything I'm likely to produce quickly from scratch.

Which means this approach biases against people with experience of day-to-day programming, and in favor of inexperienced recent college graduates who've been regurgitating this information in exams. Which in turn means it's achieving the opposite of what you claim it's meant to achieve. I don't see how that's defensible, but for some reason people chant FUNDAMENTALS! FUNDAMENTALS! FUNDAMENTALS! Ballmer-style whenever the topic comes up.

See also this lovely piece published recently: https://medium.freecodecamp.com/welcome-to-the-software-inte...

You know that basically LinkedIn, Instagram, Facebook, Reddit or Github are "crud apps" right ?

Good luck to you my friend, I hope you're able to see some growth from here on out.

Found myself in a similar position over the last year, though with different circumstances. Fired and burnt out from a corporate stooge job I took a chance on, age 25 now, but still finding myself in the depths of the job hunt process. Roughly the same experience. It's grating. After a year or so of no success, little feedback if any, I moved to manual labour instead of the junior pos. I don't think it would have been possible to be unemployed for a year with dependants. I imagine that would be incredibly stressful.

If there's one thing I've learned so far in my experience (at 25) it's that momentum is important. It's difficult and depressing to maintain momentum in interviewing if you get no feedback, can't improve, don't see success, and waste vast amounts of time. It's very difficult to maintain momentum in software in general if you've spent so long outside of it interviewing that you haven't worked on anything of value in months. The junior pos will allow to keep some level of momentum and at the very least that will keep.you paid and moving forward.

Apologize ahead of time for the atrocious grammar. Typed on my phone on the go.

I'm sorry to hear anout your experience. Whiteboarding is tough, from both ends I think.

How do you decide in 1 hour if you want to invest 1 month of a team's time to see if the candidate was a good hire? It's a tough problem.

When I do interviews I try to make them worth the candidate's time. My approach is to ask just one key question: "Pick an algorithm you like, one you've invented or one you've read about, and teach me how it works"

This I think balances the power dynamic since it puts the candidate in control. And it gives them a chance to show off, should they choose to do so. Plus I might learn something.

Afterwards I start throwing additional information at them and try to twist the algorithm they presented into unfamiliar situations. This gives the candidate a chance to learn something new, I hope. I taught one candidate about impractical theoretically awesome O(n) sorts this way.

But people whom we've hired after such an interview told me that at the time they felt like they failed the interview even when they did smashingly well.

Anyway, I'm happy that you eventually got the job! I wish people spent more time trying to make it fair to the candidate.

I appreciate this stuff immensely. In one of my interviews, the interviewer was teaching me stuff. He asked me if I knew about this and I said no I haven't used it. Then he showed me how. It was a good experience.

Edit: I remember now. He taught me how to use Pry. Now I use it daily.

Out of curiosity, why the focus on algorithms? Does your work genuinely involve understanding the implementation details of various algorithms? If so, could you provide an example? I'm genuinely curious.

An algorithm is a series of steps to do a thing. In that sense everything I do is understanding and implementing algorithms.

From wikipedia: An algorithm (Listeni/ˈælɡərɪðəm/ AL-gə-ri-dhəm) is a self-contained sequence of actions to be performed. Starting from an initial state and initial input (perhaps empty),[4] the instructions describe a computation that, when executed, proceeds through a finite[5] number of well-defined successive states, eventually producing "output"[6] and terminating at a final ending state.

I mean, if you're not writing code that takes inputs and produces outputs, then what the hell are you doing?

The point is to test candidate's ability to impart knowledge and to learn and to quickly adapt new information into the way they solve a problem. You can be the best coder in the world, but if I can't understand your code enough to be able to maintain it, you are going to be a pretty useless team member. Similarly, if you can't adapt your technical solutions to new information quickly, you're going to have a hard time keeping up with our product team.

Hell, I'd be perfectly happy if you explain to me the algorithm (recipe) to make the perfect barbeque ribs. That shit's complicated too.

I had the same experience however not with whiteboards but with take-home assignments, I was looking for a job while still working crazy hours at my previous company.

I often had to code in the late hours of the night or pull all-nighters for days straight to deliver these tests, and most of the time I got rejected with barely any explanation, one time the company just ghosted me and didn't even give me a proper rejection.

It wasn't just a defeating experience, it was affecting my sleep and my health.

While I agree about lack of feedback, any feedback at all opens a can of legal worms. Companies don't avoid it to be malicious or disrespectful of your time - they avoid it so that they don't have to worry about law suits over interpretation of that feedback.

It sucks for candidates and it sucks for companies - but it won't change with current laws on the books.

What laws?

Facebook and Google aren't afraid to give candidates detailed feedback. I think they have credible lawyers.

Unless the feedback admits that the candidate was discriminated against because they were a member of a protected class, it is benign.

> Unless the feedback admits that the candidate was discriminated against because they were a member of a protected class, it is benign.

I think it's more about if the candidate can interpret it that way than anything else.

> Facebook and Google aren't afraid to give candidates detailed feedback. I think they have credible lawyers.

They also have very deep pockets...

I completely agree. I think in after any interview, technical or not, it's a great practice to actually tell someone why they did not get the position.

I see many comments bringing up legal issues. In my personal opinion if, as a company, you are worried about giving this feedback due to legal reasons, then you have a problem. The act of giving feedback isn't the issue. It's your hiring practice.

People need to stop expecting feedback.

Hiring a candidate is like going on a date. It's a mix of background, personality, appearance, communication skills, confidence etc. And like a date each interviewer's opinion of you will be different.

And so asking feedback (a) is pointless since it may force you to change things that don't need changing, (b) clearly demonstrates you weren't the right candidate which may hurt further chances and (c) may be counterproductive since the interviewer may lie or be uniquely identifying faults that others don't find.

Feedback is extremely valuable. But you should take it with a grain of salt. If you are rejected several times, with feedback, and some of that feedback happens to overlap? Definitely something to consider fixing.

Sorry but this is the real world.

If you want feedback go see a therapist or career coach or talk to friends, family, mentors, previous coworkers etc. Don't expect a hiring manager to do this for you. As someone who has interviewed hundreds it would actually make me resent you because if you can't show the initiative or take the responsibility to improve yourself then I made the right decision not to hire you.

Worst of all I and many others would feel uncomfortable giving personality advice (if that was the issue) and would just lie and give some other reason. It's human nature and would just throw you off course and wouldn't help anyone.

Where do you work? I'd like to place it in my "don't work for these assholes" file.

Isn't asking for feedback in a real-world scenario (not a fake one like having your friends interview you) precisely the kind of thing one would do if he or she is interested in improving him or herself?

> As someone who has interviewed hundreds it would actually make me resent you because if you can't show the initiative or take the responsibility to improve yourself

How do they know what to improve if you won't tell them what needs improvement (in your eyes)?

Giving feedback is the recruiter's job; a hiring manager doesn't have the overhead. It's simple for a credible recruiter to share a couple of sentences to the candidate.

Clearly your strengths lie in organization, communication, and technology, not in carefully interacting with other people (as in Sales, Marketing, Recruiting).

Delegate this to the recruiter so the candidate doesn't get a bad impression of the company they just attempted to join.

Feel free to resent me, you've already said no anyway. I will resent you and your company for that, as well. However as far as I'm concerned you might as well not exist once I walk out of that door. But before I do that, I will try to use you for my own benefit. Luckily, most people I've met turn out to not actually be dicks like yourself and it works out great.

Reply on news.ycombinator.com