How to Get Hired at CircleCI
circleci.com
circleci.com
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 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.
- 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?
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.
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.
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 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.
> 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'.
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.
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.
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
> 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?
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?
it puts a lot more pressure on the interviewer to spot my bugs
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.
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.