12 ms·

How to Get Hired at CircleCI

143 points by ssemmaprise 9y ago

nailer 9y ago
A little short on content, here's the main bit: > 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.
- Etheryte 9y ago
  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.
- ryandrake 9y ago
  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.
  - mi100hael 9y ago
    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.
  - deedubaya 9y ago
    It defeats the purpose of saying "build a thing" if you disregard how it's built. That's what you're actually testing. If you don't care how the thing is built, you probably don't care how your production products are built either.
  - arenaninja 9y ago
    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)
  - nickpsecurity 9y ago
    "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?" ;)
  - nailer 9y ago
    > O(N-squared) pile of crap 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'.
- Bahamut 9y ago
  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.
StavrosK 9y ago
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.
- mrisoli 9y ago
  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.
  - bogomipz 9y ago
    >"My current company did the same for me, flew me in from another country and I got an assignment for three days..." Wait, so you had a three day on-site interview? Nothing about that sounds awesome or even acceptable.
    - StavrosK 9y ago
      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.
      - bogomipz 9y ago
        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.
vinhboy 9y ago
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.
- notheguyouthink 9y ago
  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.
  - vinhboy 9y ago
    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.
    - toomuchtodo 9y ago
      Have you thought about moving into architecture? Your posts could be my friend; 40s, 20+ years in tech from junior positions up to CIO. He failed a few whiteboard interviews for dev positions and called me asked for help getting him a gig. I took his resume, tailored it to highlight his high level work, stripped out dev grunt work references, and started targeted applying as him to several companies. It worked.
etimberg 9y ago
> 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.
- seangrogg 9y ago
  Do you work for a company that has - as part of it's employment contract - that you cannot do work for anyone other than them?
- uiri 9y ago
  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. [0] http://leginfo.legislature.ca.gov/faces/codes_displaySection.xhtml?lawCode=LAB&sectionNum=98.6 http://leginfo.legislature.ca.gov/faces/codes_displaySection...
  - kasey_junk 9y ago
    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.
    - ThrustVectoring 9y ago
      Just decline payment then, if you're under one of those clauses?
      - kasey_junk 9y ago
        Yep. Or if you are running interviews in one of those places consult an attorney about offering a charitable donation instead of pay.
scrabble 9y ago
> We’ll have you work on actual bugs in our actual code > 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?
- korzun 9y ago
  I think that just a 'cool' filler for the blog that doesn't translate to the real world.
korzun 9y ago
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. I have zero interest in innovating fizz-buzz.
deedubaya 9y ago
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.
- theptip 9y ago
  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.
  - deedubaya 9y ago
    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.
    - theptip 9y ago
      Got it, yeah that's a good approach. I'll look at that reddit when it comes time to refresh my task.
hashkb 9y ago
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.
- aidenn0 9y ago
  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.
  - seanwilson 9y ago
    Bad interviewers are always going to give bad interviews, whiteboard or not.
    - aidenn0 9y ago
      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.
      - seanwilson 9y ago
        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.
- sidlls 9y ago
  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.
yanilkr 9y ago
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.
- timbuckley 9y ago
  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.
  - fishywang 9y ago
    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).
    - urethrafranklin 9y ago
      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.
      - fishywang 9y ago
        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.
pfarnsworth 9y ago
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.
- cema 9y ago
  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.
kawsper 9y ago
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 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.
- grogenaut 9y ago
  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
  - kawsper 9y ago
    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.
    - grogenaut 9y ago
      Kk. I've seen widely varied screen out procedures and that can heavily hit on how many "can't even write a for loop" candidates you get.
amclennon 9y ago
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.
throwaway293874 9y ago
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.
- tutufan 9y ago
  Just nope out of the whiteboard interviews. There are lots of places that need you that don't do them.
- andrew_wc_brown 9y ago
  retro video gaming thats where its at. Play games, make videos about games. Talk about the technical behind games.
bdcravens 9y ago
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)
- walrus1066 9y ago
  Same here, I think it's a cultural thing. In the UK it's pretty rare.
dumbfounder 9y ago
We do whiteboard problems. 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.
- kasey_junk 9y ago
  How do you know that is telling? 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.
- nailer 9y ago
  > 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 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.
- razakel 9y ago
  >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. 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.
  - 9y ago
lackbeard 9y ago
This essay, which touches on the subject of whiteboard coding, has some good food for thought on the subject: http://lacker.io/tech/2017/04/05/why-you-cant-say.html http://lacker.io/tech/2017/04/05/why-you-cant-say.html.
deleted 9y ago
[deleted]
bogomipz 9y ago
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.
walrus1066 9y ago
Our test is a shortish take home exercise: implement a simplified version our core business solution (a matching engine). 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
- bad_login 9y ago
  What is your company?
digitalmaster 9y ago
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.

143 points by ssemmaprise 9y ago

A little short on content, here's the main bit: > 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.

Etheryte 9y ago
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.
ryandrake 9y ago
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.
- mi100hael 9y ago
  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.
- deedubaya 9y ago
  It defeats the purpose of saying "build a thing" if you disregard how it's built. That's what you're actually testing. If you don't care how the thing is built, you probably don't care how your production products are built either.
- arenaninja 9y ago
  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)
- nickpsecurity 9y ago
  "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?" ;)
- nailer 9y ago
  > O(N-squared) pile of crap 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'.
Bahamut 9y ago
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.

StavrosK 9y ago

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.

mrisoli 9y ago
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.
- bogomipz 9y ago
  >"My current company did the same for me, flew me in from another country and I got an assignment for three days..." Wait, so you had a three day on-site interview? Nothing about that sounds awesome or even acceptable.
  - StavrosK 9y ago
    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.
    - bogomipz 9y ago
      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.

vinhboy 9y ago

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.

notheguyouthink 9y ago
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.
- vinhboy 9y ago
  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.
  - toomuchtodo 9y ago
    Have you thought about moving into architecture? Your posts could be my friend; 40s, 20+ years in tech from junior positions up to CIO. He failed a few whiteboard interviews for dev positions and called me asked for help getting him a gig. I took his resume, tailored it to highlight his high level work, stripped out dev grunt work references, and started targeted applying as him to several companies. It worked.

etimberg 9y ago

> 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.

seangrogg 9y ago
Do you work for a company that has - as part of it's employment contract - that you cannot do work for anyone other than them?
uiri 9y ago
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. [0] http://leginfo.legislature.ca.gov/faces/codes_displaySection.xhtml?lawCode=LAB&sectionNum=98.6 http://leginfo.legislature.ca.gov/faces/codes_displaySection...
- kasey_junk 9y ago
  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.
  - ThrustVectoring 9y ago
    Just decline payment then, if you're under one of those clauses?
    - kasey_junk 9y ago
      Yep. Or if you are running interviews in one of those places consult an attorney about offering a charitable donation instead of pay.

scrabble 9y ago

> We’ll have you work on actual bugs in our actual code > 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?

korzun 9y ago
I think that just a 'cool' filler for the blog that doesn't translate to the real world.

korzun 9y ago

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. I have zero interest in innovating fizz-buzz.

deedubaya 9y ago

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.

theptip 9y ago
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.
- deedubaya 9y ago
  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.
  - theptip 9y ago
    Got it, yeah that's a good approach. I'll look at that reddit when it comes time to refresh my task.

hashkb 9y ago

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.

aidenn0 9y ago
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.
- seanwilson 9y ago
  Bad interviewers are always going to give bad interviews, whiteboard or not.
  - aidenn0 9y ago
    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.
    - seanwilson 9y ago
      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.
sidlls 9y ago
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.

yanilkr 9y ago

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.

timbuckley 9y ago
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.
- fishywang 9y ago
  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).
  - urethrafranklin 9y ago
    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.
    - fishywang 9y ago
      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.

pfarnsworth 9y ago

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.

cema 9y ago
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.

kawsper 9y ago

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 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.

grogenaut 9y ago
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
- kawsper 9y ago
  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.
  - grogenaut 9y ago
    Kk. I've seen widely varied screen out procedures and that can heavily hit on how many "can't even write a for loop" candidates you get.

amclennon 9y ago

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.

throwaway293874 9y ago

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.

tutufan 9y ago
Just nope out of the whiteboard interviews. There are lots of places that need you that don't do them.
andrew_wc_brown 9y ago
retro video gaming thats where its at. Play games, make videos about games. Talk about the technical behind games.

bdcravens 9y ago

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)

walrus1066 9y ago
Same here, I think it's a cultural thing. In the UK it's pretty rare.

dumbfounder 9y ago

We do whiteboard problems. 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.

kasey_junk 9y ago
How do you know that is telling? 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.
nailer 9y ago
> 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 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.
razakel 9y ago
>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. 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.
- 9y ago

lackbeard 9y ago

This essay, which touches on the subject of whiteboard coding, has some good food for thought on the subject: http://lacker.io/tech/2017/04/05/why-you-cant-say.html http://lacker.io/tech/2017/04/05/why-you-cant-say.html.

deleted 9y ago

[deleted]

bogomipz 9y ago

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.

walrus1066 9y ago

Our test is a shortish take home exercise: implement a simplified version our core business solution (a matching engine). 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

bad_login 9y ago
What is your company?

digitalmaster 9y ago

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.