
How to Get Hired at CircleCI - ssemmaprise
https://circleci.com/blog/how-to-get-hired-at-circleci/
======
vinhboy
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.

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

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

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

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

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

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

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

That was like a lightbulb moment for me.

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

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

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

~~~
rhizome
_That 's why I suggest limiting the importance on feedback there._

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

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

~~~
amitutk
YES! for the first 2 questions. My go to question is reverse an array (without
using any library functions).

Instead of asking a quirky question, it is better to have them solve a simple
problem and judge on logic and structure.

~~~
walrus1066
Why can't you use libraries? You're rewarding people for reinventing the
wheel.

~~~
bragh
Because in many languages, this is trivial to the level of calling .reverse()
on the array.

~~~
walrus1066
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?

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

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

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

------
amclennon
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
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
Just nope out of the whiteboard interviews. There are lots of places that need
you that don't do them.

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

~~~
uiri
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...](http://leginfo.legislature.ca.gov/faces/codes_displaySection.xhtml?lawCode=LAB&sectionNum=98.6)

~~~
kasey_junk
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
Just decline payment then, if you're under one of those clauses?

~~~
kasey_junk
Yep. Or if you are running interviews in one of those places consult an
attorney about offering a charitable donation instead of pay.

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

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

~~~
arenaninja
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)

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

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

------
walrus1066
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
What is your company?

------
bdcravens
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
Same here, I think it's a cultural thing. In the UK it's pretty rare.

------
scrabble
> 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
I think that just a 'cool' filler for the blog that doesn't translate to the
real world.

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

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

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

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

      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.

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

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

~~~
stale2002
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".

~~~
nobleach
Yes, pressure will most likely exist on the job... maybe even without internet
access... but not on a whiteboard.

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

