> Whiteboarding interviews are for companies who don’t know what they want. They’ll have you write until your hands are cramped, but all they’ll learn is how well you pseudocode on a wall.
Best interviews I've had that involved practical tests is where someone gave me a laptop, didn't bother me for 40 minutes, and had me make a thing (like a todo list app). We then talked about the decisions involved.
__Edit__: excellent point from Etheryte re: letting applicants use their own hardware.
Personally I strongly prefer knowing beforehand and taking my own hardware, unless I need a very specific setup beforehand. It takes off some edge as you feel better adjusted to the setting and it guarantees you don't have to worry about knowing how to change configs etc.
Careful what you test for though. If your interview requires people to throw a complete app together in 40 minutes, you'll be hiring people who can throw things together in 40 minutes. Maybe that's what you currently need, maybe not. There are programmers out there who can spew an entire app together in 40 minutes, but the result is buggy, memory-leaking, O(N-squared) pile of crap unsuitable for anything other than discussing in an interview. There are other programmers who would spend those 40 minutes on a single subroutine, but the result is code that is robust, bug-free, unit-tested and will likely never have to be revisited. Test for the type of behavior you need.
Presumably the exercise is predicated on the notion that you give someone a task that they should be able to complete properly within the allotted time.
Personally I think it's pretty reasonable to think if you're hiring for a Sr. frontend developer who claims React experience, that they could spin up a basic SPA with a few React components for ToDo items in under an hour. I know I could do it and I don't even particularly like writing frontends.
I worked at a place where the test was always to toss a single web page together in 2 hours (candidates were free to spend more time but by 2 hours they had written enough code for us to weigh ability).
The candidate we ended up hiring did _not_ finish, because he spent his time documenting both his frontend and backend work. The thoughtfulness that went into each of his functions was apparent, and I knew right off the bat this was someone I could learn from.
So I think there's a middle ground that both sides could be happy with, but maybe it needs to be more apparent that interviews are more about the journey than the results (in fact, all 3 candidates we ever hired via this method did not have a complete solution, but had followed enough instructions to be close enough)
"but the result is code that is robust, bug-free, unit-tested and will likely never have to be revisited. "
That was me. I did less work upfront but they did less rework later. The rework costs several times more with potential to disrupt customers. My compromise to speed it up was prototyping in something dynamic to get an idea of the solution with basic tests. Then, convert it to static, efficient, and clean code w/ more thorough tests or analysis.
I'll fail a whiteboard since it will be some bullshit. If I get asked, I'll probably do it in Prolog or Brainfuck just to mess with their heads. The, type same thing into computer interpreter to show it works. If they gripe about readability, refactor the Brainfuck piece by piece into something that looks like, but isn't, C# or Java. "Just one more thing..." (writes use atomics in top) "...and now it's immune to concurrency errors since it relies on atomic operations."
I'll fail most of the tests but might also get an offer for C# or Java job by confused, impressed, and/or skeptical interviewers. It would at least be funny outcome to show up telling the company, "No I don't know C# or Java. Here's the Brainfuck I wrote for the interviewers. You didn't ask them to hire for that? Well, here's my resume. You want me to build something real for you?" ;)
I wouldn't say that about all companies - I had some pretty hard whiteboarding questions when interviewing recently from companies of all sorts of sizes, but aside from Google and one other company, all of them have made it quite obvious how the problems I was solving on a whiteboard relates to the actual problems the companies were solving. The whiteboard questions were also interspersed with architecture design questions, and I wasn't necessarily expected to code everything either, especially if it was obvious how to accomplish a task from how I described tge approach.
I interviewed with CircleCI years ago, and did an onsite with them, and it was a much preferable way to interview. I got to work with the actual team on actual production code and actual problems, which both gave me a very realistic expectation of what working there would be like, and gave the company a view of what my performance would be like.
My current company did the same for me, flew me in from another country and I got an assignment for three days, while I wasn't directly pairing with anyone part of the task was to interact with the team on a real feature(albeit code from these tasks are not used as stated on the NDA).
I got to see not just the team I ended up in but the company infrastructure and day to day, it was what convinced me to come.
And they got to see me working and communicating with the team, they gave me a task and I delivered and so they were not hiring me blindly, I refused offers before from companies which I believe didn't interview or test me properly.
I did the same, it was paid (at a very fair rate, IIRC). They flew me in, paid for travel and accommodation, and the daily rate for three days.
The guys there even took me to dinner at a very nice fancy restaurant on the last day (even though I just wanted burritos!). Overall, it was a very good experience.
There is nothing remarkable about them paying for your travel and accommodation.
Also there are many people with children and babies at home who can't afford to be away for 3 days. I don't think it would be a very good experience for them. I would say it seems to select for the young or those with no family obligations.
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.
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.
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.
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 :)
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'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.
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"
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.
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.
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.
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.
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.
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.
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.
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.
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)
.. 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
> This is why you’ll pair with us on a real feature or bug.
I always wonder when I see these kinds of statements how they mesh with NDAs at your existing job. It's not as much of an issue here since you aren't getting paid, but it's still work for someone other than your current employer.
What does a non-disclosure agreement have to do with working for someone other than your current employer? It should go without saying that you shouldn't discuss confidential information in an interview.
In California, it is unlawful for an employer to take action against you for lawful conduct occurring away from the employer's premises during non-work hours. [0] This seems to apply to moonlighting activities.
California is not the only place people interview.
There are lots of jurisdictions where moonlighting clauses are enforceable. In all of the places I know of they do require you get paid for it to count as moonlighting.
From my personal (start-up) experience, any interview that revolves around a whiteboard is a pretty reliable indicator of general incompetence.
It should also raise all sorts of flags if you are looking for diversity and innovation. If the hiring manager failed to evolve past the college days, he is most likely hiring identical 'text-book' engineers.
Whenever I interview, I pair with the candidate to built an arbitrary thing with a time limit. Often something from r/dailyprogrammer. This helps me understand how the grasp problems, parse the intent in the mind, and put that to something which solves the problem. We can talk about design choices together because if they get hired, we're going to collaborate in very much the same way.
I also allow the candidate to take the project home and finish/refactor if they want. I may have a follow up call to review as well. This elevates the pressure of the interview a bit as there is no requirement to deliver in time X.
I don't tend to have candidates work on "real" problems because I feel like it comes across as scummy to ask for free work. If I did, I'd make sure to compensate them for their time.
Edit: I only use r/dailyprogrammer as a source of challenges, I use the same challenge for all candidates.
I do something similar; building an arbitrary thing gives you a good window into how they actually approach solving a problem.
One key difference - I use the same task for each interview, which while boring for me, makes it easier to transfer my score between candidates. I initially had some colleagues that I've worked with for years do the interview to calibrate what a ninja would look like on that test, which I've found very useful.
I've also considered doing real-world problems, but my concern is that 1) they tend to have too much back-story and context, and 2) it would be hard to calibrate the difficulty. Perhaps that's unfounded.
Yes, I use the same task for each interview as well. I just use r/dailyprogrammer as a resource for challenges. They're well illustrated and usually provide sufficient context.
You're right about real-world problems. They often require a ton of context to grasp.
If you build an arbitrary thing everyday that's completely different how do you calibrate of cross the different candidates so that you give an equal hiring experienced and make sure you're not biasing on other factors that can get you in legal deep-water, or just you know biasing accidentally because of the problem being harder today
I liked when I was tasked with "real" problems, one company paid for my services as a freelancer as part of the interview, another one "hired me" for one month as a contractor and would then make me an offer by the end of this trial period.
My current company made me part of the team for three days and gave me a real task but on the NDA it states they are not allowed to use the code produced during the interview process, it was a great experience and is what made me decide to join the company.
How would you, or would you at all, work with me, as a candidate, if I had a particular distaste for solving puzzley type problems? Note that I'm not saying I wouldn't try during an interview, but my distaste for puzzles may inhibit my successfully completing the assignment regardless of my programming abilities.
I have a distaste for puzzles too -- my hiring method doesn't use puzzles, but arbitrary real-world like tasks that need solutions. It tries to mirror real-world scenarios of what you, the candidate, would be doing if employed by me.
If this isn't an acceptable form of evaluation, I would be open to others -- which I would potentially reject.
I'm sorry... if you can't reverse a linked list, you should be ashamed to call yourself a hacker. Don't get pissed at me, go learn it right now. Know how? Force someone who doesn't to learn.
Edit: I know it's just a recruiting tool masquerading as a position piece.
You've obviously never been in an interview where you were asked to reverse a linked-list on a whiteboard and the interviewer complained about syntax mistakes on the whiteboard.
I actually have no problems with interviewing using a whiteboard, but asking someone to code on a whiteboard (as I have been asked to do in all but 1 interview that used a whiteboard) seems monumentally stupid.
It's not great but OK for short things. If the interviewer is asking you to write something lengthy and/or getting annoyed about semicolons, brackets and capitalisation though then that's stupid.
I'm sorry, if you think the ability to reverse a linked list has anything but the most shallow and superficial relationship to engineering a product (using software as the tool and medium), you shouldn't call yourself an 'engineer.'
Sure, it's easy to understand what "reverse a linked list" means and entails. That doesn't mean it's a high quality question for a software engineering interview.
> I'm sorry... if you can't reverse a linked list, you should be ashamed to call yourself a hacker. Don't get pissed at me, go learn it right now.
Yeah...I don't understand those kind of complaints. Spend a day or two practicing interview questions and brushing up on algorithms and data structures. The same topics come up in most interviews I've been in. You might not use the information every single day but you'll be better for it.
I wouldn't fail someone in a coding interview for getting that exercise wrong but if they had no idea how a linked list worked and they've never had the curiosity to find out that's really bad. I've interviewed coders who have never even heard of a linked list and you can't tell me that's not some indication of their breadth of knowledge.
There is a big difference between being able to solve a problem during a normal work session, and being able to solve the same problem, on a whiteboard, with no internet access, under time pressure, all while trying to explain your thoughts to an audience.
Whiteboard interviewing is a skill that needs to be practiced, and it is mostly orthogonal to the skill known as "being an engineer".
I'm not pissed at you, because this isn't important enough to be as salty as you are, but I've been writing code for about 25 years (about 10 professionally) across a wide array of low- and high-level fields. I'm very good at writing code and building systems and I can't reverse a linked list offhand. I understand linked lists and I understand their storage and runtime characteristics, and I could figure reversing the list out given a minute to think, but I'd have to go figure out how to do it on-the-spot because I have never needed to write one from memory in my life at any level. Google exists.
Whiteboard is a medium to showcase your skill. People who can think in terms of pictures and demonstrate their thinking on white board are pretty good problem solvers. Not all companies and job roles need whiteboard coding. Companies have whiteboards and engineers use it to communicate with each other. It is a very effective tool. Interviewing is an art and bad interviewers make the process dehumanizing and boring. Do not hate the whiteboard. Some of the ideas programmers have are pretty complex, conversation and writing those are low bandwidth medium not adequate for interviews.
I agree whiteboards are great for all those things. But they are terrible as a way to write actual code. The problem is that many whiteboard interviews have you write actual code on the board, and all of the inefficiencies involved in that.
If the company/interviewer cannot tolerant small typos, wrong standard library function signatures, or similar small "bugs" on whiteboard coding, that's their problem.
If they are OK with things like "I cannot remember if the second parameter of Java's String.substring is end index or length, let's just assume it's length here", I don't see how inefficient whiteboard coding is (besides typing on the keyboard is usually faster than writing on the whiteboard).
Sorry, are you trolling, or do you not even code? You don't indent/dedent, cut-paste, or refactor? You know exactly how you will write an entire file before you begin? This is before we even get into ergonomics such as running out of vertical/horizontal space, or having bad handwriting.
indent/dedent: how is it less efficient using handwriting than using keyboard? If you mean the case like you realized that you need to add an if to add another level of indention, any interviewer/company requires you to wipe the whole thing and reindent properly on the whiteboard is not worthing working for anyway.
cut-paste: if you are doing this a lot, you are doing it wrong.
refactor: sure. but for whiteboard interviews, it's rarely needed, or it's small enough that you can just wipe and rewrite it again on another part of the whiteboard.
Of course, all these points are assuming that the interview question is "suitable" for whiteboard interview. If you find yourself need to write more than 100 lines of code on a whiteboard during for an interview question, at least one of the interviewer and interviewee is doing it wrong.
I've never had a whiteboard interview where they cared about the syntax. I used pseudo code every time and they've always accepted it without problem. I can imagine places where this isn't the case, but they are just bad interviewers. The point is to talk through a problem, not write working code.
As long as I know that coding/algorithmic interviews are part of the process, I prefer whiteboarding. That's because it puts a lot more pressure on the interviewer to spot my bugs, if I have any. At this point, I'm a pretty good whiteboard programmer, and I know how to code to minimize bugs, but it does make things a bit more forgiving.
it puts a lot more pressure on the interviewer to spot my bugs
Perhaps you have a point. In addition, maybe it helps with focusing on the substance of the solution rather than the peculiarities of the chosen language.
In our technical interviews, we asked the following questions to our candidates:
- Find the most frequent integer in an array
- Find the common elements of two int arrays
- The buying/selling stock question from https://www.interviewcake.com/question/java/stock-price (slightly modified, I removed the word efficient as I only care about a correct solution, not the most efficient one, and we provided a data-set with a correct answer).
They were asked to bring their own laptop, and use their favourite editor, with the language of their own choosing, and setup a test environment.
It was an eye-opening experience to see how different the responses were, also how few that could actually solve the first two ones, I subscribe most of this to pressure to perform, but I think we at dodged two that was really good at talking, but had never opened their editor for at least a couple of years, despite their resume stating otherwise, and when asked about it they did programming every day.
I am all for finding better ways of interviewing for new engineers, and I really like their points about communication, but I am not sure giving them access to master and start hacking around is a fair challenge either, of course that is where the pairing aspect comes in, maybe it is worth a shot for our next round.
What percentage of candidates should you filter out before bringing them on site EG what percentage of these people into that we had about just wondering because it makes a difference in where in the funnel they were
We placed the technical interview as the second interview. So if we thought they were a good match they would go to the technical interview, and if they completed that we would offer them the job.
I am not sure how many we rejected before the technical interview, because I wasn't involved as much in that part.
What I've seen done at my last jobs have been the following:
- A pretty simple take-home problem (something that just implements two or three classes)
- An exercise to refactor really terrible code (this is offered in alternative to the take-home)
- Questions about architecture that they've worked on in the past, the problems they've had to deal with, etc.
Just asking those questions and seeing how they do with the simple challenge is enough to see if they have at least good code instincts. In person, they can justify their decisions (and it's good here to see if they can take feedback, run with it, and come out with a better solution).
Ultimately the interview process should smell out if 1) they're an asshole to work with 2) if they're able to have good code/architecture instincts.
Sure, but in some of the popular languages where that is the case, .reverse() is no more (and no less) a “library feature” than creating or indexing an Array.
In which case, the question isn't really relevant to the job. Same goes for stuff like sorting algos. Why not pose problems more representative of the job and business domain?
> Because reversing an array is super easy and using a library is one function call
It's not super easy without using library functions when all the operations that work on arrays (including the constructor that makes them) are as much “library functions” as the one that reverses an array. (Conversely, if the mechanism that reverses an array is part of the language core and not a library, the restriction fails to have the expected effect from the other side.)
The restrictions seem to assume that every language has the same division of distinct core “language” features as distinct from what is provided by libraries.
That's just how arrays work. If your elements are 32 bit integers then you are establishing a pointer to the first element. Accessing an element is multiplying the index by the element size and jumping from the first element pointer to a memory address offset.
> The restrictions seem to assume that every language has the same division of distinct core “language”
Fine, if your language has a library for arrays, then reimplement it on the whiteboard. Everyone is able to do that if they know what arrays are. They are just contiguous memory
At some point, you need to decide what you're going to ask something to build in an interview. It's probably been implemented before.
Yes, reversing an array is arguably lower level than an application engineer needs to go - but not by much (in some languages you will be doing this yourself). And if they can do that, they can do something comparably difficult.
> My go to question is reverse an array (without using any library functions).
If you mean “functions provided by a library outside of the core” there are languages where this restriction doesn't prevent the kind of trivial solution you are trying to prevent.
If you mean “any predefined functions/methods” there are languages where this is impossible (e.g., since even literal array syntax is just syntactic sugar for the Array constructor method.)
Note that there are several languages that fall into both categories (e.g., Ruby.)
There are probably a very narrow slice of languages where this restriction, however you define it, really does what you intend.
I do think these are reasonable questions, and allowing the candidate to use their own laptop sounds very fair.
One thought though, not necessarily for the poster but for anyone who asks these questions: for the second question, finding common elements of two int arrays, the idiomatic Ruby answer is: x & y
Would you be satisfied with that answer? As a candidate, would I be expected to create a set of tests to ensure that it works, even though this is a standard feature of the language?
If you would not be satisfied with that answer, would you be surprised that a candidate might struggle with an alternative, knowing that they would never use an alternative in their normal coding experience?
I actually disagree with most of the other posters about bringing your own laptop. I only own a desktop and chromebook. I use a macbook that my employer provides, but I wouldn't feel comfortable bringing that to an interview. I think by asking someone to bring their own laptop its creating an unnecessary requirement, but I realize I may be in the minority as far as laptop ownership goes...
If you didn't have a machine, we would of course provide you with one. The feedback we have received is that people felt more at home with their own tools and hardware.
I think people often try to emulate policies from large successful companies without necessarily understanding the context for why this policy would make sense for those particular companies, but not for others.
In a company like Google or Facebook, it may not matter whether or not you have any experience with technology X, because they have a large training organization that will teach you proprietary technology Y anyway. Their interview process might therefore come across as overly academic, because there's a good chance you might have to "study" and quickly learn something arbitrary as part of the job.
In a much smaller organization, it's unlikely that you will encounter any technology or basic problems that haven't been seen before and it's much more important that you have a baseline level of competence in your expected job. It's also less likely that they have an organization dedicated to training software engineers.
Logically, these very different types of companies should have very different interview processes, but that isn't always the case.
I've got 30+ years of programming experience and nearly 20 years of web app development experience, and I can't do these whiteboard interviews. They just don't work with the way my brain does. It doesn't matter how many projects I've worked on, how many clients made how much money from things I built for them, or how many people use my open source apps, all that matters is these humiliating stressful interview setups. I'm thinking about giving up on tech and switching to another line of work. It's genuinely breaking me, because I love coding. And I'm good at it.
Funny thing is, 18 years after my first programming job, I've yet to do a single whiteboard interview. (the bulk of my career has been contracting or CTO-level work for smaller companies; I've never taken a "startup lottery" job)
We want to hear what you think about when you write code. The actual amount of writing is pretty minimal, setting up the problems on the board is actually more writing than the solutions. There are certainly other ways to do it, but one of the most important thing we evaluate is whether you are willing to give it a go. If you are standoffish and unwilling to participate that is quite telling of how you will be when you are given tasks that aren't fun. Not all tasks are fun.
The issue with whiteboard interviews isn't that it proves people will do something not fun, all parts of the interview are that.
The issue with whiteboard interviews is that they bias heavily towards talkers not doers. There are some talkers who are good doers, but as both a positive or negative signal it's fairly worthless.
You could test this pretty easily by comparing a whiteboard interview opinion with post hire opinion on your employees or by having someone else reinterview your staff and comparing their score to your own internal performance evaluations.
We white board issues all the time, it's not a lecture, it's a discussion. You need to be able to discuss things with people. We understand people get nervous, and we try to ease them. We are very easygoing and get most people to relax.
What they left out of this pithy marketing pitch is that a recruiter will send you an email with 20 questions in it. Many of them are in depth multiple part questions. Essentially they were asking you to submit an essay before even speaking with a human being. When I responded that I would be happy to answer these questions in a conversational setting I was told that was not an option and I was also told "many people have told us they really enjoy answering these questions." No thanks CircleCI your process seemed DOA to me.
Something just feels inherently broken when the act of just doing the job isn't the same practice (training) necessary to interview for that same job. Why should I have to learn to "crack the coding interview"? I'm not trying to trick teams into thinking than I better than I am or know more than i actually know because I spend the last few days memorizing a few algorithms I never use.
I'm certainly not saying that teams don't take into account a candidates experience, OS code or his/her ability to discuss complex, role relevant, topics in great detail -- i'm just saying that no matter how high you rank in all these other areas, at most companies (including mines), it really doesn't matter if you can't reverse a linked list on the spot ¯\_(ツ)_/¯.
I just tend to believe that solving algorithms (especially under pressure) is a specific skill just like everything else, not a general test of programing "ability" -- so unless the job requires that you write algorithms every day then we should broaden the traits that we test for. That said, having interviewed a lot of candidates myself, it is truly difficult to consistently identify good well rounded candidates.
150 comments
[ 4.5 ms ] story [ 178 ms ] thread> Whiteboarding interviews are for companies who don’t know what they want. They’ll have you write until your hands are cramped, but all they’ll learn is how well you pseudocode on a wall.
Best interviews I've had that involved practical tests is where someone gave me a laptop, didn't bother me for 40 minutes, and had me make a thing (like a todo list app). We then talked about the decisions involved.
__Edit__: excellent point from Etheryte re: letting applicants use their own hardware.
If you don't care how the thing is built, you probably don't care how your production products are built either.
Personally I think it's pretty reasonable to think if you're hiring for a Sr. frontend developer who claims React experience, that they could spin up a basic SPA with a few React components for ToDo items in under an hour. I know I could do it and I don't even particularly like writing frontends.
The candidate we ended up hiring did _not_ finish, because he spent his time documenting both his frontend and backend work. The thoughtfulness that went into each of his functions was apparent, and I knew right off the bat this was someone I could learn from.
So I think there's a middle ground that both sides could be happy with, but maybe it needs to be more apparent that interviews are more about the journey than the results (in fact, all 3 candidates we ever hired via this method did not have a complete solution, but had followed enough instructions to be close enough)
That was me. I did less work upfront but they did less rework later. The rework costs several times more with potential to disrupt customers. My compromise to speed it up was prototyping in something dynamic to get an idea of the solution with basic tests. Then, convert it to static, efficient, and clean code w/ more thorough tests or analysis.
I'll fail a whiteboard since it will be some bullshit. If I get asked, I'll probably do it in Prolog or Brainfuck just to mess with their heads. The, type same thing into computer interpreter to show it works. If they gripe about readability, refactor the Brainfuck piece by piece into something that looks like, but isn't, C# or Java. "Just one more thing..." (writes use atomics in top) "...and now it's immune to concurrency errors since it relies on atomic operations."
I'll fail most of the tests but might also get an offer for C# or Java job by confused, impressed, and/or skeptical interviewers. It would at least be funny outcome to show up telling the company, "No I don't know C# or Java. Here's the Brainfuck I wrote for the interviewers. You didn't ask them to hire for that? Well, here's my resume. You want me to build something real for you?" ;)
It's a TODO list. If performance is an issue you've done something terribly, terribly wrong. Like write your own algorithm.
> There are other programmers who would spend those 40 minutes on a single subroutine
Something which has not shipped has no value. This is an excellent indication for a 'no hire'.
I got to see not just the team I ended up in but the company infrastructure and day to day, it was what convinced me to come.
And they got to see me working and communicating with the team, they gave me a task and I delivered and so they were not hiring me blindly, I refused offers before from companies which I believe didn't interview or test me properly.
Wait, so you had a three day on-site interview? Nothing about that sounds awesome or even acceptable.
The guys there even took me to dinner at a very nice fancy restaurant on the last day (even though I just wanted burritos!). Overall, it was a very good experience.
Also there are many people with children and babies at home who can't afford to be away for 3 days. I don't think it would be a very good experience for them. I would say it seems to select for the young or those with no family obligations.
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.
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.
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.
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.
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.
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 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 :)
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)
https://github.com/poteto/hiring-without-whiteboards
CircleCI is in there too.
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.
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.
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.
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.
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.
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.
Nothing they said suggests this feedback is the most important thing to them, they were only asking for a quick email.
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.
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 did something that seemed sensible enough I guess. maybe. I have no freaking idea if I was even close to what he wanted.
Another one was design a pipeline for real time metrics. Okay, that one at least is less ambiguous.
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.
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.
It sucks for candidates and it sucks for companies - but it won't change with current laws on the books.
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.
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...
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.
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.
How do they know what to improve if you won't tell them what needs improvement (in your eyes)?
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.
.. 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.
Some companies don't want a decade of writing crud apps.
(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...
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.
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.
Edit: I remember now. He taught me how to use Pry. Now I use it daily.
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.
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.
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.
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.
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.
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.
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.
I always wonder when I see these kinds of statements how they mesh with NDAs at your existing job. It's not as much of an issue here since you aren't getting paid, but it's still work for someone other than your current employer.
In California, it is unlawful for an employer to take action against you for lawful conduct occurring away from the employer's premises during non-work hours. [0] This seems to apply to moonlighting activities.
[0] http://leginfo.legislature.ca.gov/faces/codes_displaySection...
There are lots of jurisdictions where moonlighting clauses are enforceable. In all of the places I know of they do require you get paid for it to count as moonlighting.
> you’ll pair with us on a real feature or bug
Are you paying people who are interviewing with you? Or are you getting them to do real work on your code for free?
It should also raise all sorts of flags if you are looking for diversity and innovation. If the hiring manager failed to evolve past the college days, he is most likely hiring identical 'text-book' engineers.
I have zero interest in innovating fizz-buzz.
I also allow the candidate to take the project home and finish/refactor if they want. I may have a follow up call to review as well. This elevates the pressure of the interview a bit as there is no requirement to deliver in time X.
I don't tend to have candidates work on "real" problems because I feel like it comes across as scummy to ask for free work. If I did, I'd make sure to compensate them for their time.
Edit: I only use r/dailyprogrammer as a source of challenges, I use the same challenge for all candidates.
One key difference - I use the same task for each interview, which while boring for me, makes it easier to transfer my score between candidates. I initially had some colleagues that I've worked with for years do the interview to calibrate what a ninja would look like on that test, which I've found very useful.
I've also considered doing real-world problems, but my concern is that 1) they tend to have too much back-story and context, and 2) it would be hard to calibrate the difficulty. Perhaps that's unfounded.
You're right about real-world problems. They often require a ton of context to grasp.
I just use r/dailyprogrammer as a resource for arbitrary problems.
My current company made me part of the team for three days and gave me a real task but on the NDA it states they are not allowed to use the code produced during the interview process, it was a great experience and is what made me decide to join the company.
If this isn't an acceptable form of evaluation, I would be open to others -- which I would potentially reject.
Edit: I know it's just a recruiting tool masquerading as a position piece.
Sure, it's easy to understand what "reverse a linked list" means and entails. That doesn't mean it's a high quality question for a software engineering interview.
Yeah...I don't understand those kind of complaints. Spend a day or two practicing interview questions and brushing up on algorithms and data structures. The same topics come up in most interviews I've been in. You might not use the information every single day but you'll be better for it.
I wouldn't fail someone in a coding interview for getting that exercise wrong but if they had no idea how a linked list worked and they've never had the curiosity to find out that's really bad. I've interviewed coders who have never even heard of a linked list and you can't tell me that's not some indication of their breadth of knowledge.
Whiteboard interviewing is a skill that needs to be practiced, and it is mostly orthogonal to the skill known as "being an engineer".
Your post is uncharitable and kind of mean.
If they are OK with things like "I cannot remember if the second parameter of Java's String.substring is end index or length, let's just assume it's length here", I don't see how inefficient whiteboard coding is (besides typing on the keyboard is usually faster than writing on the whiteboard).
cut-paste: if you are doing this a lot, you are doing it wrong.
refactor: sure. but for whiteboard interviews, it's rarely needed, or it's small enough that you can just wipe and rewrite it again on another part of the whiteboard.
Of course, all these points are assuming that the interview question is "suitable" for whiteboard interview. If you find yourself need to write more than 100 lines of code on a whiteboard during for an interview question, at least one of the interviewer and interviewee is doing it wrong.
it's just code on a whiteboard. none of that stuff matters.
- Find the most frequent integer in an array
- Find the common elements of two int arrays
- The buying/selling stock question from https://www.interviewcake.com/question/java/stock-price (slightly modified, I removed the word efficient as I only care about a correct solution, not the most efficient one, and we provided a data-set with a correct answer).
They were asked to bring their own laptop, and use their favourite editor, with the language of their own choosing, and setup a test environment.
It was an eye-opening experience to see how different the responses were, also how few that could actually solve the first two ones, I subscribe most of this to pressure to perform, but I think we at dodged two that was really good at talking, but had never opened their editor for at least a couple of years, despite their resume stating otherwise, and when asked about it they did programming every day.
I am all for finding better ways of interviewing for new engineers, and I really like their points about communication, but I am not sure giving them access to master and start hacking around is a fair challenge either, of course that is where the pairing aspect comes in, maybe it is worth a shot for our next round.
I am not sure how many we rejected before the technical interview, because I wasn't involved as much in that part.
- A pretty simple take-home problem (something that just implements two or three classes) - An exercise to refactor really terrible code (this is offered in alternative to the take-home) - Questions about architecture that they've worked on in the past, the problems they've had to deal with, etc.
Just asking those questions and seeing how they do with the simple challenge is enough to see if they have at least good code instincts. In person, they can justify their decisions (and it's good here to see if they can take feedback, run with it, and come out with a better solution).
Ultimately the interview process should smell out if 1) they're an asshole to work with 2) if they're able to have good code/architecture instincts.
Instead of asking a quirky question, it is better to have them solve a simple problem and judge on logic and structure.
It's not super easy without using library functions when all the operations that work on arrays (including the constructor that makes them) are as much “library functions” as the one that reverses an array. (Conversely, if the mechanism that reverses an array is part of the language core and not a library, the restriction fails to have the expected effect from the other side.)
The restrictions seem to assume that every language has the same division of distinct core “language” features as distinct from what is provided by libraries.
a = [0, 1, 2]
print a[1]
That's just how arrays work. If your elements are 32 bit integers then you are establishing a pointer to the first element. Accessing an element is multiplying the index by the element size and jumping from the first element pointer to a memory address offset.
> The restrictions seem to assume that every language has the same division of distinct core “language”
Fine, if your language has a library for arrays, then reimplement it on the whiteboard. Everyone is able to do that if they know what arrays are. They are just contiguous memory
Yes, reversing an array is arguably lower level than an application engineer needs to go - but not by much (in some languages you will be doing this yourself). And if they can do that, they can do something comparably difficult.
One that demonstrates their ability to write clean, testable, readable OO code, with appropriate abstractions, and not overengineered.
I find most candidates, struggle to do this, including algo wizards. Most software engineers aren't good at this either.
If you mean “functions provided by a library outside of the core” there are languages where this restriction doesn't prevent the kind of trivial solution you are trying to prevent.
If you mean “any predefined functions/methods” there are languages where this is impossible (e.g., since even literal array syntax is just syntactic sugar for the Array constructor method.)
Note that there are several languages that fall into both categories (e.g., Ruby.)
There are probably a very narrow slice of languages where this restriction, however you define it, really does what you intend.
That's a really nice way to make someone a lot more comfortable. I do have to ask, was any part of your judgement affected by those choices?
One thought though, not necessarily for the poster but for anyone who asks these questions: for the second question, finding common elements of two int arrays, the idiomatic Ruby answer is: x & y
Would you be satisfied with that answer? As a candidate, would I be expected to create a set of tests to ensure that it works, even though this is a standard feature of the language?
If you would not be satisfied with that answer, would you be surprised that a candidate might struggle with an alternative, knowing that they would never use an alternative in their normal coding experience?
In a company like Google or Facebook, it may not matter whether or not you have any experience with technology X, because they have a large training organization that will teach you proprietary technology Y anyway. Their interview process might therefore come across as overly academic, because there's a good chance you might have to "study" and quickly learn something arbitrary as part of the job.
In a much smaller organization, it's unlikely that you will encounter any technology or basic problems that haven't been seen before and it's much more important that you have a baseline level of competence in your expected job. It's also less likely that they have an organization dedicated to training software engineers.
Logically, these very different types of companies should have very different interview processes, but that isn't always the case.
We want to hear what you think about when you write code. The actual amount of writing is pretty minimal, setting up the problems on the board is actually more writing than the solutions. There are certainly other ways to do it, but one of the most important thing we evaluate is whether you are willing to give it a go. If you are standoffish and unwilling to participate that is quite telling of how you will be when you are given tasks that aren't fun. Not all tasks are fun.
The issue with whiteboard interviews isn't that it proves people will do something not fun, all parts of the interview are that.
The issue with whiteboard interviews is that they bias heavily towards talkers not doers. There are some talkers who are good doers, but as both a positive or negative signal it's fairly worthless.
You could test this pretty easily by comparing a whiteboard interview opinion with post hire opinion on your employees or by having someone else reinterview your staff and comparing their score to your own internal performance evaluations.
By getting me to multitask between:
- solving a problem
- allocating space on a whiteboard to inject code later
- legibility of my handwriting
- speechwriting
- public speaking
you've gauged exactly how I would react when asked to do my job and be heckled with other tasks that add no business value while doing so.
No, what you're doing is filtering out people who are bad at public speaking or have performance anxiety.
If you want someone who can deliver a lecture, put that in the job description.
Is it really, though? And do I read this correctly that one of your interviewing intents is to make the candidate uncomfortable?
I judge candidates on:
- choice of abstractions
- quality of the tests
- readability (very important, reading code is x10 harder than writing it)
- knowledge of the language and it's libraries
- correctness of the solution
I penalize candidates for:
- reinventing the wheel (I.e. Roll their own sorting algo)
- overengineering
- unnecessarily convoluted, 'clever' solutions
- premature optimisation
I'm certainly not saying that teams don't take into account a candidates experience, OS code or his/her ability to discuss complex, role relevant, topics in great detail -- i'm just saying that no matter how high you rank in all these other areas, at most companies (including mines), it really doesn't matter if you can't reverse a linked list on the spot ¯\_(ツ)_/¯.
I just tend to believe that solving algorithms (especially under pressure) is a specific skill just like everything else, not a general test of programing "ability" -- so unless the job requires that you write algorithms every day then we should broaden the traits that we test for. That said, having interviewed a lot of candidates myself, it is truly difficult to consistently identify good well rounded candidates.