How to Interview Entry Level Software Engineers

https://technology.cloverhealth.com/how-to-interview-entry-level-software-engineers-daaecf9db97

by dsil • 9 years ago

150 127 9 years ago

technology.cloverhealth.com

gopalv• 9 years ago

Also, we chose to completely scrap whiteboard coding and assigned homework instead.

For an entry level engineer, this removes a bunch of variance and also because it gets you another scenario which happens way often in actual work.

You show up with the code and it gets reviewed & discussed on how/why of the implementation.

The most talented entry level people I've worked with have struggled with criticism instead of grading (i.e "grade the code" through a bunch of test-cases is different from "why did you do this and explain").

hcoura• 9 years ago

This also opens space for people from different backgrounds (degrees).

In most cases you are not looking for the people with the most level of CS knowledge, but rather someone that can think logically, that learns/ramps fast and have at least some explanation, even if wrong, for his choices and is able to take the observations/review as a learning opportunity.

taurath6• 9 years ago

I’m a senior engineer with an anxiety disorder that has trouble with white boarding. It’s honestly probably the most cruel environment possible for me because when I work I’m on the same team.

socanxdev-thrwy3• 9 years ago

My social anxiety makes interviewing very difficult. I freeze up to a single-track-mind. Every spare bit of processing available is used up on guessing social situation around me.

I recently had an old boss try to bring me on to a new job with him, but wasn't able to get me through the interview phase, despite knowing I'm capable, because my interviews with the rest of the team went so bad.

I've been a software engineer over ten years. All of the positions that I have been offered have come from especially kind/empathetic teams, and the interviews usually focused more on conversation than quizzing.

It requires an unfortunate amount of rejection before coming across my more selective criteria, but I guess that is what it is.

andrewflnr• 9 years ago

So here's a crazy idea. What if the "interviewer" doesn't know the answer, and the problem is designed to be big enough to require both of you to solve it? That puts you and them on an equal basis in a more realistic scenario. Plus it helps calibrate the results by generating data on how existing employees perform.

Problems: the existing employee ends with even more latitude to wreck the interview. You need to ensure that the interviewee is taking the lead. You probably also need to record the whole thing for objective review by someone else, which you'll have to disclose, which could make it awkward again.

Ed: I've also heard of processes where you put multiple interviewees on a task together. That has some similar potential benefits.

13of40• 9 years ago

Sloppy handwriting and a not-100%-progressive coding style is my bane when it comes to whiteboard coding. For the last two senior level dev jobs I've gotten, I just brought a laptop with Visual Studio set up and told the interviewer I sucked at whiteboard coding and could I please do it in an IDE.

pjc50• 9 years ago

How do you check whether they've done it themselves? Rely on the discussion?

smoe• 9 years ago

Not OP, but we do home work assignment instead of white board coding as well.

While I can't be absolutely sure that they've done it themselves, a big part of the in person interview is based on the homework, asking them how they would extend it, add specific features, potential performance problems they see, etc.

Those answers are hard to fake if you didn't do it yourself

We had one case where a candidate used some open source code snippets in his solution, not declaring and removing the comments and license headers. Still it was very obvious in the difference of coding style.

cabaalis• 9 years ago

We hire mostly junior developers. I give a simple whiteboard interview with 3 questions, and encourage them to solve it with mostly pseudo-code but have a few "extra points" things that I'm looking for. Absolutely avoided any kind of "trick" questions.

I like the homework idea. I don't know about "coming back" but maybe send it to them a couple days prior to the tech interview.

jamestimmins2• 9 years ago

The one downside I've found with homework problems is that oftentimes the set of requirements (or "suggested features") doesn't line up with the amount of time you're expected to spend on it.

I've personally been in the situation of receiving a list of 10-12 required features, with a stack that the recruiters know I am unfamiliar with, and then been told to only spend four hours on it.

While this was an extreme case, I find that the unreasonable time expectation is not uncommon. That is quite frustrating as an applicant.

NetOpWibby• 9 years ago

I love the "this shouldn't take more than an hour or two" assurances.

walshemj8• 9 years ago

They might be looking for how good you are at time boxing

pfarnsworth• 9 years ago

It depends on how much effort we want to put into training entry level programmers. Different companies have different requirements. If we intend to train the programmer from the ground up, then we can probably look for programmers who are smart, resourceful and self-sufficient. We can train the rest, like good coding, etc.

If our expectations are higher, then what I look for is code sensibility. Do they cut and paste the code without thinking "hey, this is kind of dumb to do"? Do they see repeated code and think "this can be collapsed into something more succinct"? This is the hardest thing to train for, and the most time consuming from a mentor point of view, so if we have a high bar for entry level programmers, then code sensibility is one of the factors on top of the 3 above that I look for.

I've rejected interns that worked for me from a permanent position because after 4 months, they still had terrible code sensibility. I had to pour through their code with a fine tooth comb because it was riddled with tiny bugs, and it needed constant rewrites because they just didn't improve over the course of the internship. I've had other interns that just "got it" and wrote great code from the start, or only needed a few reviews and then "got it". Those are the ones that will be productive quickly and won't hamper the rest of the team with lengthy reviews.

bg4• 9 years ago

We give homework and it has been a successful approach. Even if it's a trivial assignment one can gain a lot of insight on the candidate based on the overall professionalism of their submission.

kinkrtyavimoodh5• 9 years ago

Every few days an article of this type is written and posted on HN. And all the comments are people either proposing another (same old) approach to hiring or people replying to those comments explaining why they'd hate that approach.

This is then done for every possible combination of approaches (homework questions, whiteboard interview, pair programming, fizzbuzz questions, algorithmic questions, work-history questions, career-progression questions, mini-project, magical incantations, and so on...)

It may sound cynical but at this point it feels like no one has any new ideas about it and the same content keeps getting recycled in the form of yet another article and yet another comments section.

Half of these articles are from company blogs which exist largely as just a marketing tool.

Since there is no actual new thought, everyone just cargo-cults the Google approach.

Kluny• 9 years ago

I've never done hiring, but I've chosen roommates, and I feel like it's the same. You make a checklist of stuff you're looking for and red flags, do a reference check or whatever, but ultimately, the decision always comes down to some gut impulse. My gut has always been right so far, but I guess the day it burns me is the day I start trying to find some optimal solution to protect myself from letting an asshole move in.

johnrob• 9 years ago

Anecdotally, most if not all of the times I’ve been burned has been when I ignored my gut feeling.

tempay• 9 years ago

The problem with using gut instincts for these kinds of decisions is that it introduces bias and discrimination. For a roommate that might be positive as it will bias towards people that are similar to you, but for companies it's too easy to end up making rooms full of middle class white dudes.

kurtisc• 9 years ago

Maybe if they hate the approach, the interview is a successful filter.

nxsynonym• 9 years ago

I think the bigger issue is that the interview-to-hire process is not fool-proof, and never will be.

It's a gamble, no matter how in depth or complicated your hiring process is (from personality interviews to whiteboarding to take homes). Being interviewed and doing well is a skill set and it's very different from a full time work-place skill set.

All of these interviewing processes that get refined and more lengthy just create a new class of people who are good at being interviewed.

I don't know what the solution is, but making candidates jump through 3-4 interview rounds, memorize algorithms just for the sake of it, and go through 4 to 8 hour on sites probably isn't it. Even if it happens to give you a better-than-average employee, what are you sacrificing (as a business) in terms of man-hours, productivity, and focus?

Personally I'd like to see more companies institute a temp-to-hire process. Bring in new candidates for a two or three week contract, see how they fit in, pay for the their time (at a discount), and then go from there. If it doesn't work out, you get some work done for your company, and they get some relevant experience for their resume.

Writing the perfect resume and re-reading CTCI for the 10th time won't tell you how well the candidate will perform, but seeing them actually work might.

As to your point about marketing - I agree. Not one of these approaches are really novel or helpful to anyone but the company themselves, and is just a glorified "look at how we took a chance" tactic.

mrisoli• 9 years ago

It is impossible because it is always possible to game the system.

If you devise an interview framework or a hiring profile, no matter how many traits you want to evaluate(as the article points out), they will lump those together and measure in some scale of how likely they are to hire the candidate(sometimes that is even just binary), if a candidate can emulate their desired profile he gets a high "score" and gets an offer, the bigger the financial incentives to do this, more people will game the system(prepare for specific interviews), think, if you can play the part for a couple of 1-hour interviews, you can get a 6-figure salary at a tech startup, that is a high ROI.

Most companies can't stop that, there isn't limitless budget for interviewing so the interview process has limited resources to evaluate people, which leads to false positives. There are also a lot of talented people that don't practice their interviewing skills enough and end up as false negatives.

It's human nature, people need to evaluate things on a single criterion and you can game that. The same thing happens with school, you can work your way through school material to maximize your grades without learning much.

_e3• 9 years ago

An interview is like dating and sometimes you think you found the one but maybe it doesn't work out in the end. Do you stop interviewing (or dating) people? No, you try again and hopefully take lessons from the last failed hire. A "failed hire" could actually be a failed process in your organization.

Also, every person you are interviewing has the option to interview with other companies. With that in mind, you should always be interviewing even if you aren't actually looking to hire at that moment. Sometimes you might find a really good candidate but, most importantly, you will have options yourself.

Last, I really like your idea of a paid temp position to assess fit. This will benefit everyone tremendously.

pqh• 9 years ago

Contrary to the analogies being drawn by sibling and child comments, work is different from dating or interviewing potential roommates, in that you typically have to give up a previous job when accepting a new one and if you don't make it through the trial run, you're unemployed.

It would be great if the only reason people could be let go were legitimate, but that's hardly the case.

radlad• 9 years ago

This idea of temp-to-hire places a disproportionate amount of risk on the employee to be hired -- they will need to leave their current job (where they likely have decent job security) in order to attempt being hired at the new company.

In the real world, people generally don't put in their notice until they've accepted an offer at another company.

taurath6• 9 years ago

Hilarious example to me, because while I’ve been a consultant or contractor seen as an exellent and valued member of a team (being the only contractor) they still insist (perhaps even on the hr level now) that I pass the interview process which is all of the first part that you describe. I’d say it’s their loss but I like it where I am. There is no recourse and everyone around me acknowledges that it’s broken, but nobody wants to change it.

CobrastanJorji• 9 years ago

I don't think the problem is about lack of innovative thought. The problem is a lack of a verification mechanism. Say I come to you with an amazing new black box. A candidate puts their hand in the box, and if a light on top of the box turns green, that will be a good employee and you should hire them. How do you verify whether my box works?

fjsolwmv4• 9 years ago

That's biased against the unhanded

auxym4• 9 years ago

Why though? Why is programming seemingly the only field where companies feel the need to put up these super interview processes with mutiple interview rounds, technical tests, white boarding, etc?

Is it the high salaries? In that case, do you see such testing in law, or finance?

Is it the technical difficulty? In a previous life (read: up to a few months ago) I worked as a mechanical engineer, in a pretty technical field (numerical simulation of structures). Additionally to demanding reasonably deep knowledge in a few areas, the job came with the responsibility of making sure that your designs do not kill or injure people.

I had never had a technical test in an interview before I interviewed for my current IT position. Nor have I heard of colleagues having such a test. Is it because most engineers in Canada are licensed (myself included), and most jobs require you be licensed? If that's the case, it's pretty funny, because at least in my province, the test you have to pass for the license is entirely about ethics and professionalism, nothing technical.

Part of the code of ethics though, is that it's on you as a professional to ensure you have the necessary competence to do the work.

meri_dian• 9 years ago

You're kidding, right? That other industries don't have high entry barriers? Just some I can name off the top of my head...

Medicine, law, pharmacy, actuarial science, accounting...

For most upper class jobs it's the norm.

jamestimmins2• 9 years ago

A big part of it, which you allude to, is that many people are either self taught entirely, or having studied CS during undergrad, are self taught in practical software development.

In a field like mechanical engineering, I assume an employer can take for granted that a new grad has a certain set of skills (general physics, structures, fluids, etc.). That can't be assumed in quite the same way in software engineering.

kinkrtyavimoodh5• 9 years ago

I think it's a multitude of factors. These jobs

1. Pay a lot. Barring trading, you'd be hard pressed to find a job that routinely pays 200K+ to 25-year olds

2. Are, at least most of them, not fundamentally difficult for a generally smart person, despite whatever people convince themselves of. I am not talking of the so-called 10x engineers here, who you are unlikely to find through standard interview techniques.

3. Pride themselves on NOT being credentialist (at least on the surface). You can't wake up tomorrow wanting to be a lawyer, read some books, and get a good job offer in a couple months. It's possible for CS jobs.

travisjungroth2• 9 years ago

I've been both a professional pilot and software engineer. The process to become a pilot was more intense in time and cost than to become a software engineer. The interview process for a job as a pilot is much easier than the interview process for a job as a software engineer.

The barrier to entry for software engineer jobs is all at the interview. That's why it's so hard, tedious, and complicated.

jasode• 9 years ago

, or finance?

Tricky brainteaser questions are popular in quant finance interviewing. Example[1]. There are also discussion forums dedicated to it. Example[2].

Some electrical engineering firms will ask you to analyze complicated circuits in the interview. Some even have "take home tests" where the candidates design a circuit according to the interviewer's specification.

[1] http://www.streetofwalls.com/finance-training-courses/quanti...

[2] https://www.quantnet.com/forum/quant-interviews.41/

0xffff23• 9 years ago

Are your sure it's just software? I work in the aerospace field, where we hire pretty much ever kind of engineer there is. The hiring process looks pretty similar to me for all engineering disciplines.

DoreenMichele• 9 years ago

It might be because writing code is as close to magic as you can get. It does real world things, like banking and long distance communication, but it is invisible and in an arcane tongue.

If I see a bridge, I don't need to be an engineer to gauge if it is likely to support my weight. But if the bridge is invisible, I probably want significant assurance that no one is pulling a fast one here, so to speak.

AlexCoventry2• 9 years ago

You would probably enjoy http://n-gate.com .

Clubber• 9 years ago

The approach I prefer is have one of your tops talk to them about technology for an hour or less. Talk about their favorite projects, least favorite projects, favorite code, etc. The top will be able to tell if they have the interest and ability. The interest is what makes a entry level developer improve.

imiric• 9 years ago

Wholeheartedly agree.

Make the process a conversation rather than an interview. Get to meet the person, have lunch with them, talk about what motivates them and what they're passionate about, discuss tech stuff, and at some point during that hour or two both you and them will have an idea whether you want to turn it into a steady relationship. :)

I like to add a code review stage to the mix, where we show them a small chunk of intentionally badly written code that might come up during a code review, which has both obvious and more obscure issues related to syntax, clarity, efficiency, etc., and you judge how they approach it and what issues they bring up. I've found this to be quite a useful metric that mostly replicates a real world scenario, but in a more comfortable setting than asking them to write code on a whiteboard.

And you try your hardest to block any biases for/against them you might have when making your decision.

ubernostrum2• 9 years ago

For what it's worth, I'm one of the people who consistently shows up to rant about interviewing processes and what's wrong with them in HN threads that come anywhere near the topic.

I also work at the company this article is about, and the article was written by one of my colleagues. While no process is perfect (including ours -- both the one detailed in this article, and the one we use for general engineers), one of the things that I like about working where I do is the emphasis on putting thought into the interview process and questioning a lot of things that get assumed without a second glance by interview processes elsewhere.

drewmol• 9 years ago

Here's an anecdote for a different approach that wasn't intential, but wound up giving the company a good sampling of my skills and personality, and me a good sampling of what it was like working for them. I volunteer some consulting and IT services for a local non-profit. They were having another company build some business specific software for them, which had been recommended to them by their board(client is part of a franchise structure of sorts). It was far past schedule, and from my perspective the client had misunderstanding of the scope and timeframe for this type project, which let to the client questioning me "should we just scrap it?".

By volunteering along side the company doing the software build(which was also volunteering, mostly) we were able to get the project on track, and update the client's expectations to a more realistic view of the timeframe and outcome.

By volunteering alongside them, for another org that we both were happy to support, I didn't feel like I was doing free work for them, and they weren't struggling to pay full salary and onboarding cost to find out the same.

Just a thought for an approach to get a sample of each other without one party doing free work for the other.

Apocryphon• 9 years ago

How about employment by sortition: let the RNG decide.

punchclockhero• 9 years ago

Probably the only fair method.

ramzyo• 9 years ago

Well written, thanks for posting. This is my sentiment exactly.

Kequc• 9 years ago

I cannot count how many interviews I've done where I've shown up with 10+ years of industry experience and been given an interview catered toward juniors. If anything there is too much emphasis on interviewing entry level software engineers. There are others out there with a proven track record.

I'm just underselling myself, shooting too low. At this point do I need to be applying for management?

zip12343• 9 years ago

What do you mean catered towards juniors? I interview people a lot and part of the interview, junior or not, involves a short coding test. The reason it is done is because some people can skate along and make an impressive resume but there is nothing to validate that resume. How do I know someone did the work that they are claiming? Not everyone has a github, and even then it can take time to validate someone's work.

walshemj8• 9 years ago

can't you call there previous employers for a reference?

mikeokner• 9 years ago

It's tricky for interviewers because a lot of candidates claim to be "senior" yet can't even solve fizzbuzz on a whiteboard. Look for jobs with "Lead" or "Architect" in the title, but beyond that, expect that you'll have to go through some sort of stupid process as a bullshit screen.

monocasa3• 9 years ago

Can confirm, have interviewed people for a senior position with a wonderful resume with 20+ years of experience, who seem to have never seen a computer before. Flip the bit endianess of a word was one of the problems, and I saw a guy who literally (supposedly) did embedded software for the space shuttle just grind for 45 minutes and somehow not make any progress. Like it was impressive. I would have expected a random walk to make more progress.

B-Con• 9 years ago

Notably, “potential” is nowhere on the scale. Many posts talk about hiring entry level engineers on their “potential,” but the term is seldom defined. Most people use “potential” to describe a sense that, even though a candidate currently cannot be an autonomous engineer, someday in the future they could be. We did not attempt to predict the future for any of our candidates but rather evaluated them on what they presented through the interviews.

Well...

Some of the qualities we looked for in our associates in particular were:
Resilience: Learning on the job is hard and we assumed that the associates would make mistakes and struggle through difficult concepts. We needed people who could endure these struggles and bounce back ready for the next challenge.
Willingness to learn and the initiative to do so: Clover would assist the Associates in their growth, and provide teachers and mentors to help along the way, but any incoming Associate would need to be responsible for their own growth.
Humility: This is an important trait for all Clover engineers, but we paid special attention to it in our Associates. They would have to learn from those around them, be respectful of others, and be able to take difficult feedback with grace.
...
Deciding the technical skills to evaluate was a long process. We expected to teach our Associates most of the technical skills they would need to do their job, but we couldn’t accept candidates that were completely blank slates.

It really sounds like this is measuring the candidate's "potential".

I would argue they defined "potential" as "resilience, willingness to learn, and humility", which they feel is an atypical definition.

(Personally, I think that's a decent set of criteria to look for in entry-level engineers.)

zip12343• 9 years ago

Resilience, willingness to learn, and humility can be the potential, but I would also say that they are the candidates attitude. Yes, I would say that attitude makes a big difference.

drakonka• 9 years ago

I was pretty nervous at my interview; no test was mentioned until the day, at which time (after the rest of the interview) I was presented with two sheets of xml-style configuration code for the company's proprietary build system.

The task was super simple - basically just duplicating some of the configuration and renaming some values to create another job, but at the time I just froze and couldn't see it. I managed to get some sort of answer out, but wasn't happy with my response. They claimed that they were meant to give this to me in advance as a homework question and somewhere the ball got dropped, but I had a feeling they wanted it to be a more on the spot thing considering the problem was so simple.

Thankfully I had the wherewithal to ask if I could take the problem home with me after the interview. When I got home and looked at the problem with fresh eyes I facepalmed so hard. I wrote up the correct answer and emailed it over to the company recruiter, hoping she would pass it along to my interviewers, but didn't get my hopes up.

I guess she did, since I ended up getting the job. I still cringe a bit about how I just blanked on that stupid question. Thankfully I got ramped up really quickly once I actually started the job and had no problem figuring things out after that.

AlexCoventry2• 9 years ago

It'll be interesting to see how it works out. Without some kind of real-time test of facility with abstract symbolic reasoning, I would expect them to get burned. It's way too easy for people to fool themselves and others about that kind of capability.

If they asked the subjects to modify the homework slightly during the debriefing, that might be enough.

makecheck2• 9 years ago

This is generally fine but “homework” is a terrible idea (trend?) because it isn’t looking from the perspective of the new hire:

1. Unemployment can be extremely stressful and there is a very good chance the person needs a job NOW. Every little thing you do to dilly-dally instead of making an offer is another hurdle that may send the applicant elsewhere. Act as soon as possible when you see a résumé you like (get on the phone, find out what you want to know, make a decision; if you bring them to interview and they’re struggling, give feedback immediately; don’t have a system where you wait 3 weeks to tell them yes/no).

2. Any effort you expect an applicant to spend will be greatly multiplied. That person is not talking only to you, they’re looking at LOTS of job postings!! If every potential employer starts assigning “homework”, it becomes a major hurdle and you can bet they’ll look a lot closer at an employer that might provide a paycheck in a couple weeks instead of “homework”.

3. You don’t need complex problems to understand if somebody can code. Let them use whatever language their résumé claims they know, give them something to do for a few minutes and see what happens. If they get stuck, give them a solid hint and again, see what happens. You’re trying to assess things like (a) if they appear to know what their résumé claims, (b) if they are the kind of person you can interact with to get somewhere on a problem.

tptacek2• 9 years ago

I don't think you've thought this through carefully.

What do we think the median interval from "established intent to interview" to "offer" is at medium-to-large software companies in SFBA? If I had to guess, it's on the order of a month. Nobody's hiring homework process puts a dent in that timeline. On the other hand, when done well, "homework" makes it easier for engineering teams to make confident decisions, which expedites offers.

How much effort do you think it takes a typical candidate to get through an interview gauntlet at a tech company with more than (say) 50 employees? It's at least multiple full days worth of aggregate effort, almost always including one actual, on-site full day. To the extent that homework offsets on-site interviews, it reduces the amount of effort candidates need to put in.

walshemj8• 9 years ago

Is it your ignoring the fact that some good candidates will just look at the job add see the home work coding tests and think "fuck you pay me" and ignore the opportunity.

Who needs a full 1 day of interviews plus time for phone interviews for an entry level job.

makecheck2• 9 years ago

Why must a hiring position be so “confident” for an entry-level hire? Take a couple of weeks to decide, maybe even one.

You basically already know what an entry-level hire will know: they’ll remember most of what the last year of their degree taught them, and have a fuzzy memory of anything earlier. They’ll be about as good at problem-solving as you can see on a whiteboard. You’re not paying ultra-senior salaries out of the gate; you’re just getting what you pay for so bring in somebody promising, start them on a project and let them begin a career with you.

Like I said, put yourself in the “new hire” position. They should be treated better given their likely circumstances:

You have to survive, you need rent and food and whatever else. You have debts. You’re probably working some non-ideal job (or 2 jobs) in the meantime for enough cash, enjoying all the no-free-time-left that gives you. If you’re really lucky, only a handful of companies have given you some stupid assignment to do with your spare hours, and since it’s “homework” and you have “more time”, they probably dreamed up a more involved problem than the average whiteboard question would be. Then you feel extra pressure because you really want to get it right but in reality you probably ended up rushing the thing and making some silly mistakes that you won’t see.

Never mind that “homework” is just the latest example of unnecessarily-long-winded hiring practices. Once you add up every little thing that every company wants, you’ve spent a lot of time that you don’t really have. (Some want you to create a new web account and profile that redundantly re-specifies 90% of your résumé. Some require you to specify your résumé as a file, then they scan it and scatter it into the wrong fields and discard the rest, requiring you to fix it all. Some have other forms for you to fill out. Some want multiple phone interview half-hours of your time, multiple on-sites, etc. and still can’t get back to you in under 3 weeks. Now do that 10 or 20 more times and don’t miss your next shift at the coffee shop.)

convolvatron2• 9 years ago

entry level is bar far the easiest to interview for.

with experienced people they always think they are at or near the top of the scale, but dont understand that you have a different scale entirely.

with a junior person, ask them to describe a project they worked on. if they 'i dunno, school stuff', then you're done.

if you can engage with them meaningfully about their school work, or if they've done personal projects, have developed any kind of insight, show a spark of excitement or creativity then you're done - hired.

just keep an eye on them for a while to make sure they're engaged and absorbing culture. invest a good amount of time in their success (mentorship, pair debugging, whiteboard talks). if they dont start contributing more than they are costing in time after a few months, find them another role or fire them.

mynameishere2• 9 years ago

I love your attitude, but when I got out of school, nobody gave a flying eff about personal projects. This was before Google Analytics, so I had to track IPs myself, but I think something like .1 percent of companies looked at my website--and that might have been a false positive.

Even the company that eventually hired me didn't look at my website.

convolvatron2• 9 years ago

if you've spent years programming and dont have anything to say about it, there isn't anything for me to go on. you obviously dont have any real interest in it, and you're below the bar where i'm willing to invest the time to see if you're teachable. what would you suggest instead? gpa? top school? test? those dont seem particularly relevant.

edit: oh, maybe i wasn't clear. school projects are fine grist, you just have to be able to say something interesting about them

grad_ml2• 9 years ago

I would say, try to test the fundamentals. Do they understands how memory is accessed, have sense what kind of algorithm is used (though it would be too much to code in 45 minutes), ambitious, have general idea to solve a problem, can they see issues if things are not performant... Having a conversation, comfortable conversation is the key, imo.

walshemj8• 9 years ago

For a general developer role that seems excessive not sure what you mean by algorithem here?

I would assume you'd be asking about how the address and data busses work which varies by cpu and architecture (von Neumann vs Harvard) presumably you'd be happy if some one explained how PIC memory access works ?

grad_ml2• 9 years ago

With algorithms, I mean if the problem demands some optimization, be it network flow, string compression or some kind of resource allocation (something like register allocation in compilers), one should have the vague idea which direction to pursue or approach. This requires somehow rigorous course-work in school. Assuming everyone takes standard CS machine architecture courses, having the breadth in multiple domain is, essential, imo for a well rounded engineer. Now knowing(or having no idea) how memory access, hierarchy etc works, they won't know when things just get stuck.

kelnos2• 9 years ago

One thing I'd be interested in, but feel like I never see, is a post-post-mortem somewhere down the line, say a year or two later. This gets a little tricky because you don't want to air your company's dirty laundry or say negative things that could be easily traced to point to a specific person, but...

In theory, I like the approach they've taken to hiring associates, but at the end of the day, what really matters is: are the people they end up hiring successful at their jobs? It might take a year or more to really answer that question.

I don't feel like we're very good at this. As 'kinkrtyavimoodh points out in another comment, we see a lot of "how to interview engineer" type posts. But we never find out if, in the end, they were effective. This article claims that everything went really well because they had (or believed they had) such high-quality candidates that it was difficult to choose at the end, but they don't actually know that. They won't find this out after evaluating actual on-the-job performance. It might have been hard to pick from their candidate pool because their process failed to tease out flaws that are only going to become apparent later. We just don't know, and likely will never know.

rdiddly• 9 years ago

You with your sensible guidelines, your calibrated metrics, your well-defined endpoints. Where's all the VOODOO!??! Where's the WITCHCRAFT!??!?!

kelvin0• 9 years ago

I have failed many time at interviewing at technical interviews. I have never failed any 'real' world job project/endeavor. I've built an entire org's codebase and this company is now selling products worldwide successfully. Design,coded,built,tested and deployed code in 4 languages , each element being critical to the company.

I am an experienced dev, but couldn't tell you my birthday in a technical interview. All the rest of the interview is fine, I only 'freeze' up at technical questions.

Sucks.

Overtonwindow• 9 years ago

I have only one modest proposal: No. More. Whiteboard interviews!!

wyclif• 9 years ago

I saw the title to this piece on the HN front page, and thought, "Wow, I'd like to see what a random tech company does with entry level engineers." Too bad this isn't a piece of writing that really discusses that in detail. There is no real actionable content here; it reads more like an HR post or marketing for Clover. A shame.

How to Interview Entry Level Software Engineers

Related Stories