
If companies interviewed translators the way they interview coders - kissgyorgy
https://medium.freecodecamp.com/welcome-to-the-software-interview-ee673bc5ef6
======
odammit
I was once asked a very very specific question about a conflicting setting in
an nginx config and the dude actually wrote the config on the whiteboard and
asked me how I would make it work.

I stared at it for what felt like minutes and then said, if I looked in your
search history would I see you looking this up on stackoverflow?

The guy said "yes" and I said I would make it work by asking you to send me
the link to the stackoverflow answer.

He laughed and said "you got me".

Same company different interviewer asked me to explain the "pros and cons of
Java vs Rails."

I turned the job down.

~~~
EduardoBautista
I don't understand how Stack Overflow is so popular for these types of
questions. Usually the documentation is a much better source. So yes, using
Stack Overflow instead of the documentation is a red flag for me.

~~~
13of40
I think it's because Google somehow manages to index stack overflow better
than the documentation. That, and stack overflow only answers real-world
questions while the documentation tends to give equal weight to rarely and
commonly used features.

~~~
fragsworth
The reason is the text of the questions, which is what people type into the
Google search bar. Documentation never has questions worded in the way people
would commonly ask it.

For this reason, I wish they would allow redundant questions to be asked, if
the phrasing is even slightly different. But the rule-mongering mods always
remove it if they can.

~~~
stable-point
Perhaps SO could include the titles of questions marked as duplicate somewhere
in the markup so that Google indexes it?

~~~
icebraining
Which is exactly what they do:

 _Should duplicates be deleted?_

 _In general, no: most duplicates stay around. Having multiple copies of the
same question with different wording is useful as search fodder, because
people looking for an answer may use different wording too._

[https://meta.stackexchange.com/questions/10841/how-should-
du...](https://meta.stackexchange.com/questions/10841/how-should-duplicate-
questions-be-handled)

~~~
fragsworth
That's good to see that they actually have the right rules, but I've used it
many times where my questions were closed simply for appearing similar to
others (when I did not even find the others in my search results). I suppose
the mods can be overzealous.

~~~
icebraining
Being closed is not the same as being deleted.

------
theprotocol
For better or for worse, I've now become abrasive when asked interview
questions in such a scripted, artificial manner. Because I no longer want the
job at that point, I can respond more boldly, e.g.:

 _" Where do you see yourself in 5 years?" "I don't know. Are you reading
these questions from a textbook? FYI they're not very effective if you want to
find someone who will do the job."

"What's your greatest weakness?" "Trick questions in job interviews."_

This is obviously not good advice; I have just reached a point in my life
where I will not be made to dance to the whims of the interviewer, despite
which the job would likely go to one of the employee's friends rather than it
being given to me anyway.

One of the few merits of this approach is it tests if you can be frank with
them or not. If they get offended at your lack of sucking up, then you
probably wouldn't want that job anyway, because I find that if you suck up
during the interview, you will find yourself struggling to maintain that ideal
forever if you do get the job. It's better to be upfront about what things you
actually care about.

~~~
daxfohl
Don't judge a company by the interviewer though. Most would rather be coding
or whatever their _real_ job is, so yes they read canned questions from a
textbook. In a way, bad interviewers may be a sign that the work itself is far
more interesting!

Still, the approach has its advantages. _" Listen, I know you'd rather get
back to doing whatever you were doing before this. Let me tell you why I'm a
good candidate .... "_. And then go on having "developer-to-developer"
conversation, ask them about their work, talk about your own. Obviously only
do this on the canned questions, not the actual technical questions, unless
you've already aced a few tech questions and are getting bored. Unless it's a
hugely bureaucratic organization, this will probably receive a good review.

Another thing I've noticed is that it allows the interviewer to lower their
guard as well, so you can usually get some more real "what's great, what sucks
about the job", and I've even scored on "what's the pay cap of this position"
multiple times.

~~~
virgilp
Oh, by all means, DO judge the company by the interviewer(s)! Those are likely
to be your colleagues. Your managers. If you have no respect for them after
the interview, chances that you'll like them on the job are slim.

[edit] Also, the interview process should tell you a little bit about what
kinds of candidates make it past the interview, to become employees.

------
beagle3
One of the interview questions I've used in the past is "reverse a linked
list".

Indeed, you (almost) never need to reverse linked lists in practice - but you
often need to chase references of one kind or another (database, pointers,
etc.) and do some manipulations on them that would result in a different list.
If you have 20 data points, it doesn't matter what you do, but if you have
100M or 10B points, it makes a great deal of difference whether you do O(n),
O(n log n) or O(n^2) or O(n!).

I think this is a good question, because it is an abstract version of the kind
of problems that any non trivial code has to address. It is easy to describe,
and easy to solve if you know what you are doing. I don't use it anymore
because it's too common to be useful.

And yet, through the years I've gotten the feedback[0] that it is "far
detached from real work", "tests how good I did in school rather than how good
I am" and various other comments -- and almost always from candidates who did
poorly; I've never gotten this feedback from anyone I would consider
competent.

[0] I try to get feedback through whoever referred the candidate, whether it's
the friend-of-acquaintance, or the recruiter. I don't, in general, trust
direct feedback from someone I turned down (or hired, for that matter).

~~~
kstenerud
> I think this is a good question, because it is an abstract version of the
> kind of problems that any non trivial code has to address. It is easy to
> describe, and easy to solve if you know what you are doing. I don't use it
> anymore because it's too common to be useful.

This is precisely the problem the OP is talking about. When's the last time
you ever did anything as low level as reversing a linked list? It's a solved
problem, and something an employee would NEVER do in your company, let alone
search for the optimal solution in 10 stressful minutes while you breathe down
his neck.

> And yet, through the years I've gotten the feedback[0] that it is "far
> detached from real work", "tests how good I did in school rather than how
> good I am" and various other comments -- and almost always from candidates
> who did poorly; I've never gotten this feedback from anyone I would consider
> competent.

Major red flag. I don't mean to be rude, but this sentence comes off as very
arrogant.

> I don't, in general, trust direct feedback from someone I turned down (or
> hired, for that matter).

Why? Because they're in a lower caste? If you can't handle direct feedback,
you're a terrible manager.

~~~
sago
> When's the last time you ever did anything as low level as reversing a
> linked list? It's a solved problem, and something an employee would NEVER do
> in your company

I think that misses the point. A linked list is a simple data structure that
needs little explanation, and yet uses indirection in a way that can get you
into trouble. As such, it is a great toy problem to asses a person's ability
to work with linked data. Reversing a list, is similarly, very simple to
explain, and a quite rudimentary operation.

So if I'm trying to asses basic ability to manipulate data in code, it seems
much simpler than trying to give them a real-world linked data structure and
have them do a real-world manipulation on it.

The real problem is the assumption that this is a 'solved problem', i.e. that
a) there is an one-true-way algorithm out there, and b) that is what the
interviewer wants you to _know_ (i.e. know in the sense of knowing a fact).
That is true of too many interviewers, and that is the problem.

I can imagine setting that as a question in an interview. And I wouldn't be
interested in 'the algorithm', I'd want to see that someone could figure it
out easily. If someone came in and clearly had just learnt it, it would tell
me nothing. I would immediately ask them something else to take them out of
their rote prep. But if someone came in and couldn't figure it out, why would
I think they'd be any better on 'unsolved problems'? In terms of being able to
manipulate data, it isn't much beyond Fizzbuzz.

The 'it's a solved problem' attitude smacks of leftpad thinking to me.

~~~
crdoconnor
I almost exclusively give candidates realistic tasks (slightly modified real
world tasks) and give them under realistic conditions (free access to google,
candidate's own laptop preferably).

It perplexes me. What do you gain by _not_ doing that?

~~~
sago
Time and (therefore, because interview time is limited) thoroughness.

A simple task on a linked list takes two minutes to explain and five minutes
to solve. The kind of task someone might do for me day-to-day have a whole
bunch of context, and require knowledge or explanation of architecture and
data configuration. I don't want to spend more than a couple of minutes
explaining the problem, just to test whether they can program their way out of
a paper bag.

~~~
crdoconnor
>A simple task on a linked list takes two minutes to explain and five minutes
to solve. The kind of task someone might do for me day-to-day have a whole
bunch of context

>The kind of task someone might do for me day-to-day have a whole bunch of
context, and require knowledge or explanation of architecture and data
configuration.

Did you think I wouldn't have to face this problem too?

If you can't decouple _one_ relevant chunk of code from your software
sufficiently to be able to give it with a minimum of context to an interviewee
then I'd have serious questions about the level of coupling in your codebase
and, by extension, _your_ programming ability.

~~~
sago
Thank you :D it always comes down to a pissing contest.

It's okay, we're very unlikely to work together. Feel free to keep doing it
your way, and I'm not going to worry about a random HNer impugning my coding
ability based on a comment about interviewing style.

~~~
crdoconnor
No hard feelings. Honestly, I'd have a much harder time hiring if half the
rest of the industry wasn't irrationally cargo culting Google's hiring
practices.

~~~
sago
Ah, I see, then I don't think you read the GP post, or I wasn't clear enough,
since that is exactly a point I made.

Also, if you're only giving real-world work tasks, do you screen at all for
basic competence first? I ask because I suspect we're talking about different
things.

Also 2 (edit), does your work only involve one kind of task? How do you assess
the breadth of their basic understanding without using simple problems? Are
your programmers doing very repetitive stuff?

~~~
crdoconnor
>Also, if you're only giving real-world work tasks, do you screen at all for
basic competence first?

I've done both with and without. I honestly found it hard to make judgments
about what effect what I was doing was having on the hiring funnel though.

If you're talking about that rather than later stage hiring then yes, I agree
it's a different kettle of fish.

------
adekok
Only from the experience of good people interviewing at bad companies.

Interviewing bad people at good companies goes more like this:

Q: Can you explain the difference between a noun and an adverb?

A: I've worked at the UN for 20 years! I'm an accredited translator! I
translated for Putin and Obama!

<sigh>

~~~
kevan
As an interviewer, sometimes I feel a little silly having to ask a candidate
super basic things like what the runtime complexity is for inserting an item
into a list or array. But then a third of candidates that I interview fail
pretty badly. At his last fortune 500 job one of my coworkers started every
interview with fizzbuzz and had about a 50% pass rate on it. Maybe that's a
problem with candidate sourcing, but there's a lot of people out there that
can't code.

~~~
brookside
What is the runtime complexity for inserting an item into a list or array?

~~~
xxs
O(n) - regardless linked structure or array backed.

~~~
arethuza
How is inserting an item at the head of a linked list O(n)?

~~~
Joe-Z
It's an average. Sometimes you insert at 0, sometimes at 1, sometimes at 2,
... sometimes at n. On average it's O(n).

~~~
poikniok
Who said you insert at different locations?

~~~
abalashov
Nobody. But who said you insert at the head? And who said the whole thing is
list-backed? Insert is just insert--not a lot to work with there.

Performance complexity is spoken to general cases and averages unless
indicated otherwise.

------
doktrin
> Everything is in a flat structure, except when it comes to salary and
> responsibilities.

This part got a laugh out of me.

Otherwise, the analogy feels really stretched and at times feels straight up
incorrect. For instance, I've never sat through a technical interview
administered by non-technical staff. I've likewise never been quizzed on the
history of computation.

I agree that the programming interview in the US can be overly algo-and-
whiteboard happy, but I think this critique is unfair and possibly even
outdated (my most recent round of interviews involved more live coding, and
less whiteboarding, than when I last interviewed 4 years ago)

~~~
pandaman
I had a technical phone screen done by an HR several times, or at least it
felt like it was a completely clueless person. Once I could tell exactly why,
when after he asked me what is complexity of binary search and I replied
"O(log)" he asked what base? (for non-technical people reading: logarithms of
every real base produce exactly the same O() result being different only by a
constant factor).

~~~
hiram112
It's been a while since I took a math class, but it seems like the logarithmic
base is key to understanding what kind of problem you have and the type of
solution needed. Comp Sci naturally uses 2, biology and finance tend towards
e, etc.

Base 2 problems tend to require clever recursion and dynamic programming to
solve, while the natural logarithm often requires calculus.

But then again, I'm not a mathematician - just what I took away from a broad
undergrad.

~~~
pandaman
Sure, if you are actually evaluating logarithm the base is very important.
However, as I said, an entity designated as "O(log)" is exactly the same for
every base so selecting a specific base here makes zero sense. Likewise,
O(n^c) is as same as O() of any polynomial of power c, if somebody is writing
O(3n^2 + 5n + 366) instead of O(n^2) - you know they don't quite understand
what are they doing.

------
minimaxir
Gayle Laakmann McDowell, author of Cracking the Coding Interview, commented on
Facebook about this article (all text below is her words):
[https://www.facebook.com/groups/hackathonhackers/permalink/1...](https://www.facebook.com/groups/hackathonhackers/permalink/1642919005763578/)

> Weird analogy. Companies don't ask candidates the history of binary search
> trees, computer architecture, or anything like that.

A better analogy would be if they gave this translator a particularly
challenging piece of text to translate -- for example, one that didn't have a
clear right answer and the candidate had to discuss different tradeoffs.

But... then that doesn't seem like quite so silly of an interview process.

There are absolutely valid criticisms of whiteboard interviews, but most
criticisms made are either based on terrible implementations of whiteboard
interviews or based on stuff that's just incorrect. (Yes, it's totally fair to
criticize a company who conducted a flawed whiteboard interview. But that
criticism doesn't apply to the system as a whole. That same company could mess
up whatever your favorite interview style is, too.)

> By the way: I don't actually know how translators are interviewed. But one
> of my best friends interviewed to be a journalist with some major New York
> newspapers (WSJ, etc).

She was already a journalist before this, so they had lots of public writing
samples for her (analogy: GitHub code samples).

Did they just hire her based on this? Nope!

She had to do a live writing test (analogy: whiteboard coding interviews). She
also had to do a pitch session to talk about different potential stories she
could theoretically write about (analogy: design/architecture interviews).
Plus some behavioral interviews.

Why not just look at her writing samples? Unlike for coders (which might not
have public portfolios representing a significant portion of their work),
basically all of her work product was actually public. So why not just hire
from that?

Well, because all they see is the final output. They don't know what direction
she was given, how long it took her, how much editing/collaboration was
involved, etc. A crappy writer in a particular environment can churn out good
work -- because someone else is doing a lot of the work. Looking at the final
result is actually not a great measure of someone's skills.

Coding interviews aren't that special.

~~~
sidlls
> A better analogy would be if they gave this translator a particularly
> challenging piece of text to translate -- for example, one that didn't have
> a clear right answer and the candidate had to discuss different tradeoffs.

What you describe is what interviewers _think_ they're engaged in when they
ask CS trivia in interview settings. They are not, and in fact are much closer
to what the article describes than the picture you paint.

~~~
ricw
Entirely! Example: When has anyone ever actually needed to know the exact
details of a red-black search tree?! In my decade of professional software
development has this not appeared once. Not even remotely. Yet this is
apparently "standard required knowledge" for interviewing at google, amazon
and co.

The point the author is making is that interviews often question knowledge
that is so far removed from actual work (aka the Arab influence on modern day
Spanish), that it is kind of a joke.

I call this mind wanking. Interesting and may be fun. But not actually
relevant.

Instead of asking far removed questions, I interview with actual current hard
engineering problems that I or my team is faced with. That way you learn
something, they know what actual work would look like. No time wasted. Win
win.

~~~
nolemurs
> Yet this is apparently "standard required knowledge" for interviewing at
> google, amazon and co.

What makes you think that? My experience is that Google at least would never
ask a question about red-black trees. I doubt Amazon would either. These big
companies stick to questions that don't require a lot of specific knowledge
because they know that a question about red-black trees mostly tests how
recently you've studied red-black trees. I've done a bunch of whiteboard
interviewing, and I would be shocked to be asked a question about red-black
trees at a competently run company.

"Cracking the Coding Interview" explicitly mentions red-black trees as a topic
that you're unlikely to see in an interview (for obvious reasons).

I think the places you see these sorts of questions asked are smaller
companies that are imitating the big players without really understanding how
to do it right.

~~~
ricw
First hand experience. I applied for a job at google and this was given as an
example of knowledge that I should revise for the interview.

~~~
nolemurs
Was that a long time ago? I've heard stories about things like that a bunch of
years ago, but my impression was that things have changed.

~~~
NTDF9
>> Was that a long time ago? I've heard stories about things like that a bunch
of years ago, but my impression was that things have changed.

By then you have wasted a good candidate's time, who doesn't want to interview
at your company anymore. Go hire the folks who memorized RB tree.

------
spullara
At Twitter I did a few hundred technical interviews and in general I don’t
like asking CS student questions but you do need to figure out if the person
can code. To this end I devised a whiteboard problem that actually mimiced a
real problem. After I left I posted it on GitHub:

[https://github.com/spullara/interviewcode](https://github.com/spullara/interviewcode)

It is important when doing lots of interviews to have a question that you know
well and can be used to benchmark across your interviews. Something relevant
to the job is an added benefit.

~~~
xtracto
When I was working at Ooyala I used to do the typical data-structure
interviews (trees, graphs, etc), until one time an interviewee asked me: "Do
you guys use all this in your day to day?" I felt ashamed to have to answer
"not really", which I did.

After that, I started asking for answers to problems that I really had in the
day to day. Some of them actually had real complexity (like doing binary
search to overcome a buggy HTTP request items pagination library).

I think the main problem with data-structures and algorithms questions is
that, the person that originally envisions a question, understands the "soul"
of the question and how to vouch the candidate as she solves the question.
However, when someone else takes that question to apply it, he only sees
whether the answer is right or wrong, without looking at the resolution
process.

~~~
NTDF9
>> I think the main problem with data-structures and algorithms questions is
that, the person that originally envisions a question, understands the "soul"
of the question and how to vouch the candidate as she solves the question.
However, when someone else takes that question to apply it, he only sees
whether the answer is right or wrong, without looking at the resolution
process

In addition, I think that when someone asks a binary tree traversal problem to
a candidate, the interviewer starts fretting over trivial edge cases, function
signatures and coding style etc.

Whereas, if you would have asked a distilled version of that pagination
problem, I would be so excited to have a chance to solve that problem and we
could focus on my ability to solve that problem instead of my coding style on
a whiteboard.

------
jobigoud
Forgot the part when you must have a public portfolio of work you did for free
in the recent years even though the job in question will keep intellectual
property under a lock.

~~~
nicole_express
Indeed-- require people who have a large public portfolio of translations
they've done for free, and then have them sign a contract stating the company
owns the rights to all translations they do while employed and for a year
after they leave, regardless of whether they were on company time or not.

------
lmilcin
I find this article one-sided and too exaggerated.

In reality, the sad state is, in my opinion, confluence of the following
forces:

1) HR people more often than not have barely any clue about the topic. They
must, unfortunately, play this charade because if they knew the topic they
wouldn't be working in HR.

2) The technical people who prepare the questions typically believe they are
too busy to spend time thinking about the problem and instead decide to settle
on any test. The assumption is that a good candidate will be able to navigate
any kind of test better that a bad candidate. In view of the technical person,
this is just a screening, the real purpose being to elliminate as many phonies
as possible.

3) The candidates more often than not have highly exaggerated view of their
abilities. Unfortunately, high demand means that the market reaches for lower
and lower quality of "resource" leading to comical situations where a large
portion of the workforce (especially in countries like India) is developing
software by shuffling around keywords until the code compiles which entitles
them to call themselves Senior Engineers. Real senior people have no problem
finding a job to the frustration of others who find the situation "unfair" and
the entire process "rigged".

One more note on the process: while the cost of failed interview for candidate
is quite low, the cost of making a mistake is very substantial for the
company.

------
ToJans
> It means we do Agile. Everything is in a flat structure, except when it
> comes to salary and responsibilities.

Pure gold!

------
EliRivers
_In the end we went with a different candidate. He doesn 't speak the specific
language we need, but he has experience with similar words in a different
language and he's a lot cheaper._

And also,
[http://www.jasonbock.net/jb/News/Item/7c334037d1a9437d9fa650...](http://www.jasonbock.net/jb/News/Item/7c334037d1a9437d9fa6506e2f35eaac)

~~~
diggernet
> Interviewer: But how many years of walnut do you have?

> Carpenter: Gosh, I really don't know -- was I supposed to be counting the
> walnut?

> Interviewer: Would you say you're an entry level walnut guy or a walnut
> guru?

Oh, hey, I just had that interview. It's called the California State Systems
Software Specialist examination. Almost 60 questions like:

"Create processes (e.g., install, configure, maintain, secure, backup/recover,
etc.) to ensure that technical staff are consistent with vendor documentation,
application requirements, and departmental standards."

or

"Consult with internal/external entities regarding services provided by
systems software teams and answer questions/inquiries in technical areas such
as connectivity with departmental systems, data exchange, security, etc."

For each of which, you must answer:

Recency

a. Performed the task within the last 2 years

b. Performed the task within the last 4 years

c. Performed the tasks more than 5 years ago

d. Not performed

Years of experience

a. More than three years experience performing this task

b. More than one year to three years experience performing this task

c. Less than one year performing this task

d. Not performed

Level at which the task was performed

a. Supervised or served as an expert on task

b. Performed task as a lead

c. Worked independently on task

d. Worked under close direction/supervision on task

e. Assisted another person on task

f. Not performed

If you don't happen to have been assigned the proper tasks in recent years to
score highly enough on the test (by whatever algorithm they use), then you are
not eligible to even apply for any Software Engineer role in the state, and
can't retake the test for 6 months.

------
mcguire
I thought it would be something along the lines of,

"Could you translate ' _¿Donde es el baño?_ '"

"I'm sorry, I don't do well on tests. I thought we were going to talk about my
past projects on my résumé. In fact, I'm quite offended by your question. Good
day, sir!"

~~~
mcbits
"That should probably be '¿Dónde está el baño?', but the question is clearly
asking 'Where's the restroom?'"

"Wrong, sorry. My sheet here says 'Where is the bath?'"

------
dkarapetyan
I keep saying this but no one seems to be listening. Use triplebyte,
interviewing.io, or recurse.com for all recruitment. You are not going to beat
those folks in terms of quality of candidates. They have data and stats. You
have anecdotes.

~~~
daxfohl
Because it seems like a misc plug? Recruitment is ridiculously ridiculous.
Data and stats, so what?

~~~
dkarapetyan
I'm not affiliated with any of them. The plug is genuine. I've been on both
sides of interview table to know it's a crapshoot. You really are better off
with one of those three than on your own.

Those companies go out of their way to reduce as much bias as possible. In the
long run we are all better off if we rely on data instead of anecdotes and
fancy resumes.

------
c8g
related discussion

Google: 90% of our engineers use the software you wrote (Homebrew), but...

[https://news.ycombinator.com/item?id=9695102](https://news.ycombinator.com/item?id=9695102)

~~~
base698
Maybe he was an asshole? You only got one side to that story.

------
Floegipoky
> Note to self: when we send a rejection letter to this candidate, be sure to
> include feedback that is too vague to be of any use to them, but will avoid
> any lawsuits.

Haha, what feedback?

~~~
theprotocol
What rejection letter? :)

------
funkaster
> Yeah, you know, trans-comps, Translation Competitions. Those were you put a
> bunch of documents in Sanskrit, throw some beverages and pizza, and invite
> translators everywhere to lock themselves down for 48 hours to see who can
> translate those the fastest. Sometimes they add free prizes to spice things
> up. Have you ever won any of those?

lol... I actually won a trans-comp when I was in (middle?) school: I was
attending a catholic school and we were taught latin and went to some
translation competitions: you had to translate a chunk of text as fast and
accurate as you can. It was fun :)

------
jmull
Heh, heh. My favorite bit is toward the end:

    
    
        ...we do Agile. Everything is
        in a flat structure, except
        when it comes to salary and
        responsibilities.
    

If only this were an exaggeration.

------
bitL
The issue is that most companies jumped aboard this insanity - it was
originally meant for the top companies to get the best people, now every
crappy company offering $40k salary is doing this...

------
pmontra
Reminds me of those companies that throw online algorithmic puzzles to
candidates. They do some good only to the companies running the puzzle
services.

------
gregoriol
One time, I got one of those questions: two columns, on the left names of some
people, on the right names of some frameworks, please associate who created
which framework

I really should have left at that point: >1 hour lost there...

------
EGreg
Do interviews really go like this at many companies?

Here in NYC I have never had unreasonable interviews even close to that. And I
interviewed for a lot of senior developer positions and consultant positions.

In our own startup we have a completely different approach. Our motto is
"People live lives. Companies build products."

We like to hire and work remotely because that eliminates geographic
restrictions and lets people work asynchronously. We've found that the better
the system for asynchronous communication, the better the long-term
productivity and maintainability.

We use a common folder structure, code conventions, for each project.
Developers build fully documented reusable components that are re-used across
projects. Every developer is very replaceable (meaning our losses are limited
if they leave or scale back their time). This is actually a great thing for
developers given our compensation model (see below).

If a developer does something wrong (like checking in syntax error), we first
check if this is something we should fix in the system (add a linter to the
pre-commut hook). There are so many amazing open-source tools today. It's a
compoundibg snowball to design a good system. Sometimes the COO job feels like
an architect/developer, just like DevOps, but for people and configuring
processes and systems instead of programs or servers.

The best talent is the one who already knows or can learn your platform (in
our case [https://qbix.com/platform](https://qbix.com/platform)) and become
productive. Who is eager to grasp new SKILLS (like debugging javascript with
asynchronous call stacks) and get familiar with useful TOOLS (like Google
Chrome).

We hire from anywhere and prefer to work over the internet. Even our
compensation model is different than what most companies do - it aims to
attract independent people and entire teams, and compensate them based on the
contributions they actually do. We want to grow a snowball in a transparent
way, and motivate people by giving them ownership of a product or feature
instead of focusing on making them sell their time as full-time employees who
commute to an office.

I'd love to get feedback on the compensation model btw:
[https://qbix.com/blog](https://qbix.com/blog)

------
codedokode
The article was fun to read but the job of an engineer cannot be compared to a
job of a translator.

And regarding "full-package" translators I think that web developers should be
able to write both frontend and backend part of an application. It is not that
difficult to learn. Programming is not something you can learn once and then
repeat the same actions for the rest of your life.

------
Fej
I see folks around here constantly complaining about this issue (not
incorrectly) but is anyone actually _doing_ anything about it?

I mean, we can whine all day and remind each other that it really does suck,
but that does little to address the problem.

------
luord
> Please stop saying trans-comps.

Oh, I can only hope...

